Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

В Google провели сравнение производительности C++, Java, Go ..., opennews (??), 05-Июн-11, (0) [смотреть все] ну все так и думали, правда несомневаюсь что гугловцы еще приукрасили статистику, Аноним (-), 00:16 , 05-Июн-11, (1) –6 // Офигенное приукрашение 94x - Go 1249101 байт Что, всего в ДЕВЯНОСТО ДВА раза , Аноним (-), 00:31 , 05-Июн-11, (5) // Ты смотри на другую колонку real Там результаты вполне сопоставимые Ну и нужн, ZOG (?), 01:04 , 05-Июн-11, (16) Go линкуется стаически по умолчанию Размер рантайма 1 1 метр Для сравнения ес, Аноним (-), 01:11 , 05-Июн-11, (18) // А даже real памяти - какого черта в 4 раза больше сожрано Даже если там метр ра, Аноним (-), 01:39 , 05-Июн-11, (23) Там сколько-то процентов от адресного пространства _резервируется_ заранее, для , Аноним (-), 13:05 , 05-Июн-11, (66) почитай повыше об этом , anonymous (??), 13:46 , 05-Июн-11, (71) тьфу пониже - , anonymous (??), 13:47 , 05-Июн-11, (72) В случае 32-битной машины это 400 адресного пространства Столько не дадут В с, Аноним (-), 19:32 , 05-Июн-11, (98) На 32-битной машине нельзя замапить в одном процессе более 2 32 адресов реально, Аноним (-), 19:50 , 05-Июн-11, (107) А статью то никто и не читал 94х это относительно C Opt кода, который проше, Аноним (-), 17:25 , 05-Июн-11, (92) // Чем же вам так интересен результат кода с дебаговой информацией Это отладочная , Аноним (-), 19:51 , 05-Июн-11, (108) читайте внимательней Dbg - написанный на скорую руку код, Аноним (-), 17:09 , 06-Июн-11, (160) Т е они сами признали, что Go не нужен , Аноним (-), 00:17 , 05-Июн-11, (3) +7   // у Go совсем другая цель, нежели скорость или там размер кода - повышение произво, SCHigi (?), 00:29 , 05-Июн-11, (4) –1   // Не, у них цель - повышение продаж оборудования производителями серверов Судя по, Аноним (-), 00:34 , 05-Июн-11, (7) –3   // Из этих результатов не видно, как оно масштабируется Может у него есть некий ми, Аноним (-), 00:41 , 05-Июн-11, (11) +1   Не, ну почему-же Из этих результатов прекрасно видно что программа на Go вообще, Аноним (-), 01:42 , 05-Июн-11, (24)   Это затраты связанные со сборкой мусора, указать сколько точно потребляет програ, Аноним (17), 01:06 , 05-Июн-11, (17)   Да какая мне разница Меня волнует как оно будет работать в сумме От их сборки , Аноним (-), 01:33 , 05-Июн-11, (20)   Э 8230 смотрите, GO создан для того чтобы писать программы, серверы, которые б, Аноним (17), 02:43 , 05-Июн-11, (30) –1   только мне кажется, что на сервере гораздо важнее скорость работы скомпилиров, anonymous (??), 04:14 , 05-Июн-11, (34) +2   Скорость в прикладных задачах http, обработка изображений у GO на уровне C , чу, Аноним (17), 04:53 , 05-Июн-11, (35)   я, кагбэ, ещё и на ресурсы намекал что-то картинка с памятью меня совершенно не, anonymous (??), 05:06 , 05-Июн-11, (37) +1   Не совсем понял, что не радует Менеджмент памяти, типа выделили 17ГБ Вы наверн, Аноним (17), 05:15 , 05-Июн-11, (39)   это число означает то, что менеджер памяти 8212 хреновый на всякий случай н, anonymous (??), 05:22 , 05-Июн-11, (40)   Для начало надо было бы уточнить, что вообще делает программа Потом надо бы всп, Аноним (17), 05:26 , 05-Июн-11, (41)   я, собственно, не имел опыта конкретно с эрлангом, но то, что столько памяти не , anonymous (??), 05:29 , 05-Июн-11, (43)   Ну вот спорят до сих пор, зачем Erlang у столько памяти нужно, много лет спорят , Аноним (17), 05:35 , 05-Июн-11, (44)   Ну, не знаю, сказал же вам, посмотрите что за тест проходят программы, вам должн, Аноним (17), 05:58 , 05-Июн-11, (46)   вот честное слово лень если этот тест показывает, как не неприспособленой к ре, anonymous (??), 06:08 , 05-Июн-11, (47) –2   Уж я тут помочь не смогу никак вам Ejabberd тоже нишевый, ничего обычного в нем , Аноним (17), 06:15 , 05-Июн-11, (48) +1   в своё время особо и не было а потом я как-то перестал искать, потому что у мен, anonymous (??), 06:25 , 05-Июн-11, (49) –1   Ну раз для вас все так черно-бело, могу вас поздравить 8212 вы достигли состо, Аноним (17), 06:31 , 05-Июн-11, (50)   жутко интересно, где 171 чёрно-белость 187 ну, кроме того, что я уже немоло, anonymous (??), 06:34 , 05-Июн-11, (51) –1   Зачет, зачет Old-school detected D, Аноним (-), 14:38 , 06-Июн-11, (151)   http steve vinoski net pdf IEEE-Reliability_with_Erlang pdf, anonimus (?), 21:37 , 05-Июн-11, (115)   чуть поясню подобное 171 резервирование 187 вредно уже тем, что система не , anonymous (??), 05:27 , 05-Июн-11, (42) +1   Угу Анноит -- пиши комплейн Строго говоря, ядрам современных операционны, Andrew Kolchoogin (?), 10:53 , 05-Июн-11, (58)   8230 вот я на это и намекал, собственно если всей оперативки со всем свопом,, anonymous (??), 13:29 , 05-Июн-11, (67)   Это некоторые особо тупые анонимы не понимают что на 32-битной системе процесс н, Аноним (-), 19:53 , 05-Июн-11, (109)   Действительно, надо Поскольку я не даун, я знаю что в системе с 32-битной адрес, Аноним (-), 19:35 , 05-Июн-11, (99)   нет как раз именно _скорость_ - и не просто так его сделали компилируемым в маш, Аноним123321 (ok), 00:40 , 05-Июн-11, (9)   Эта цель достигается не созданием новых языков, а правильной организацией обучен, анон (?), 03:28 , 05-Июн-11, (31) –1   // Бред какой-то Гуглу нужно бросать свои разработки и идти в министерство образов, Аноним (-), 12:28 , 05-Июн-11, (63)   Гугл не занимается продажей железа, думать головой будешь прежде чем разоблачат, szh (ok), 14:36 , 05-Июн-11, (86) +3   А какя тогда цель Go заохавает мир , anonymous (??), 10:46 , 05-Июн-11, (57) –1   Ява по минимуму слила в 3 7 раза Ну жабисты ж не жадные, им в 4 раза больше сер, Аноним (-), 00:33 , 05-Июн-11, (6) +2 // причём закупить -- все всех тех кто собиратся использовать результаты их труд, Аноним123321 (ok), 00:40 , 05-Июн-11, (10) ну, у них бабки водятся в отличии от цэпэпэшников , chinarulezzz (ok), 14:32 , 05-Июн-11, (84) –4 // Ну да, а LSE видимо бомжи вообще какие-то И зарплатый и цппшиков как у бомжей, з, Аноним (-), 19:37 , 05-Июн-11, (100) +1 // это те которые то на виндовсе, то на линуксе, то на сишарпе то на яве или цэпэпэ, chinarulezzz (ok), 22:55 , 05-Июн-11, (123) Проблема только в том что жабисты получают хуже бомжей - у си бомжей зарплат, Аноним (-), 14:44 , 06-Июн-11, (152) разве что в твоём уютном параллельном мирке Ниже За явой - ынтырпрайз рынок, , chinarulezzz (ok), 21:47 , 06-Июн-11, (163) А где C Почему с Си не сравнивали , Аноним (-), 00:54 , 05-Июн-11, (12) +10 // C обычно показывает себя чуть шустрее плюсов и чуть экономичнее , Аноним (-), 01:22 , 05-Июн-11, (19) // На нем сложно наворотами разбрасываться, что способствует культурному и экономно, Аноним (-), 01:35 , 05-Июн-11, (22) +1 // Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах v, Tiny (?), 10:25 , 05-Июн-11, (56) –5 Ограниченность C способствует удержанию в голове программиста идеи, что программ, Andrew Kolchoogin (?), 10:57 , 05-Июн-11, (59) +4 Касты вас использовать никто не заставляет, ООП и шаблоны позволяют избавиться о, Tiny (?), 11:41 , 05-Июн-11, (61) тем, что у него есть исторически сложившееся значение вообще, лучше бы CLU разви, anonymous (??), 13:43 , 05-Июн-11, (70) А void -- заставляют, что ли О, да Особенно при обращении к совсем не объектн, Andrew Kolchoogin (?), 17:53 , 05-Июн-11, (94) Порой без этого никак Данный оператор и в С будет делать что-то, вполне соотве, анон (?), 21:05 , 05-Июн-11, (114) Если его не перегрузили А перегрузить его можно весьма эзотерическим способом , Andrew Kolchoogin (?), 22:19 , 05-Июн-11, (116) Ок Зачем кому-то заниматься подобным К тому же не стоит забывать и о макросах , анон (?), 22:29 , 05-Июн-11, (119) О Мы подошли к Главному Вопросу Программирования Зачем быдлокодить Ответ, Andrew Kolchoogin (?), 22:41 , 05-Июн-11, (121) +1 Речь о другом на самом деле Никто не вынуждает перегружать операторы А без voi, анон (?), 18:18 , 06-Июн-11, (161) Конкретно вот это получить нельзя Хотелось бы обсуждать вкус помидоров с теми, к, dmi3s (ok), 18:47 , 06-Июн-11, (162) +1 справедливости ради define -, anonymous (??), 15:53 , 06-Июн-11, (156) но не везде прокатывает, да - , anonymous (??), 15:55 , 06-Июн-11, (158) ООП is not a silver bullet also, ООП -- это мимикрия под структуры с усложнённы, anonymous (??), 13:40 , 05-Июн-11, (69) –2 Потрудитесь узначть что такое ООП для начала, Tiny (?), 14:22 , 05-Июн-11, (77) –1 это фетиш некоторых wannabe-программистов которые считают, что симула-подобные , anonymous (??), 14:26 , 05-Июн-11, (79) –2 Вы перегибаете палку Для объектируемых алгоритмов ООП весьма и весьма полезен,, Andrew Kolchoogin (?), 22:24 , 05-Июн-11, (117) +4 немного я, впрочем, не говорил, что ООП не нужно вовсе я просто имел в виду, ч, anonymous (??), 15:59 , 06-Июн-11, (159) Это всего лишь надстройка над структурным программированием , oops_ (?), 06:26 , 06-Июн-11, (138) –1 ru wikipedia org wiki Объектно-ориентированное_программирование посмотрите пункт, анон (?), 22:40 , 06-Июн-11, (164) мало того, что ссылка на русскую педию, так ещё и не в тему , anonymous (??), 22:47 , 06-Июн-11, (165) А что не так с русской вики Очередные придирки с претензией на интеллектуальнос, анон (?), 22:55 , 06-Июн-11, (166) действительно при чём струкруты к структурному программированию советую уйти х, anonymous (??), 23:09 , 06-Июн-11, (170) Считайте что структуры в данном конексте и есть структурное программирование , анон (?), 07:13 , 07-Июн-11, (173) я также могу считать, что 171 простыня 187 означает 171 платье 187 , а , anonymous (??), 07:16 , 07-Июн-11, (174) Дело ваше Только в текущем контексте подмена слов вполне допустима По вашим пос, анон (?), 08:02 , 07-Июн-11, (175) зачем так дрожать за свою 171 личность 187 вот же фетиш у людей 8230 ты в, anonymous (??), 08:11 , 07-Июн-11, (176) +1 Признаю, просто запутало то что изначально речь шла именно о структурах Понимаю , анон (?), 08:35 , 07-Июн-11, (177) и вот почему сразу было не сказать 171 пардон, ошибся, вас много, я один 187, anonymous (??), 08:49 , 07-Июн-11, (179) Почему-то быдлокода на высокоуровневых языках куда больше Если можно просто и б, Аноним (-), 19:38 , 05-Июн-11, (101) Потому, что пишут на них больше Писали бы на языке Ассемблера -- быдлокод был б, Andrew Kolchoogin (?), 22:29 , 05-Июн-11, (118) +1 Увы, быдлокода на любых массовых языках полно Быдлокод чаще всего элементарно р, Бублик (?), 02:02 , 06-Июн-11, (130) Быдлокод чаще всего поддаётся рефакторингу и покрытием Unit-тестами Но Быдло, iZEN (ok), 07:47 , 06-Июн-11, (140) +1 Насчет культуры поспорил бы Слижком уж волно писать позволяет , oops_ (?), 06:20 , 06-Июн-11, (137) Зато респект за честность Интересно было бы регулярно смотреть результаты теста, Loooooker (?), 00:58 , 05-Июн-11, (13) +7 Нормально так джава, нужно всего в 6 раз больше памяти, чем проге на C и до 12, Stax (ok), 01:55 , 05-Июн-11, (25) Java и Scala компилируются в байт-код JVM, причем едва-ли есть существенные возм, Tav (ok), 02:39 , 05-Июн-11, (29) // Так и есть http jeremymanson blogspot com 2011 06 scala-java-shootout html, Tav (ok), 02:18 , 06-Июн-11, (133) Молодцы, полностью подтвердили статус-кво Рулил, рулит и будет рулит в обозримо, Аноним (-), 08:41 , 05-Июн-11, (52) –2 // Вот только сложность кода C по сравнению с JAVA в разы выше И обычно гораздо , kernel Doh (?), 13:00 , 06-Июн-11, (147) –1 // ORLY , anonymous (??), 15:51 , 06-Июн-11, (155) Чем они собирали C код gcc или clang , Аноним (-), 09:05 , 05-Июн-11, (53) В тестах не хватает C , интересно было бы глянуть на его результаты Жалко, что , croster (ok), 11:17 , 05-Июн-11, (60) // Ага, ещё весь Windows-рантайм за ним тянуть и реестр до кучи Весело , iZEN (ok), 14:27 , 05-Июн-11, (81) +2 // И что в этом плохого Java ничуть не менее монструозная платформа , croster (ok), 17:03 , 05-Июн-11, (91) // Так, для общего развития JRE занимает 15МБ , iZEN (ok), 19:05 , 05-Июн-11, (97) +1 Да ну А чушки на 100 мегов в пакетах - это что , Аноним (-), 19:40 , 05-Июн-11, (103) –1 Linux x86 - RPM Installer 20 06 MBWindows x86 Offline 15 77 MB, Аноним (-), 22:45 , 05-Июн-11, (122) Это только рантайм, либы тянутся из JDK за приложением , yz (?), 23:42 , 05-Июн-11, (126) –1 Даже на компе, который физически не имеет доступ в интернет , iZEN (ok), 01:39 , 06-Июн-11, (127) при чем тут доступ в интернет , линуксоит (?), 12:19 , 06-Июн-11, (143) Ответ был на это Это только рантайм, либы тянутся из JDK за приложением Видим, iZEN (ok), 23:06 , 06-Июн-11, (169) нах ява, на си все проще, Аноним (-), 08:45 , 07-Июн-11, (178) Стандартный либы тянутся как раз из рантайма JDK для этого не нужен Если для , dd (??), 15:54 , 06-Июн-11, (157) А если распаковать Хотя, конечно, дотнет 4 его натянет - там примерно 200Мб бар, Аноним (-), 14:46 , 06-Июн-11, (153) Да Тьюринг с вами 47549669 байт у меня ТОЛЬКО rt jar , Andrew Kolchoogin (?), 22:39 , 05-Июн-11, (120) Ага Потому что уровень ZIP-компрессии у rt jar 0 А в инсталляторе JRE испол, iZEN (ok), 01:41 , 06-Июн-11, (128) +2 Кофейный рантайм требует где-то около 10Мб А сколько там шарп Пятую сотню мега, Бублик (?), 02:04 , 06-Июн-11, (131) Ничего подобного, в районе 70 Мб Вот, например http ftp novell com pub mono a, croster (ok), 09:18 , 06-Июн-11, (141) для обеих платформ 41 мерабайт NET 4 Client, 25 мегабайт NET 4 X86 или X64, линуксоит (?), 12:21 , 06-Июн-11, (144) странное сравнение а цель такого смысл кода сравнения это никак не оценивае, none_first (ok), 20:29 , 05-Июн-11, (112) http jeremymanson blogspot com 2011 06 scala-java-shootout html, Александер (?), 11:54 , 05-Июн-11, (62) +1 Итого Программу на С можно запустить и отлаживать на любом компе, на Java и S, Аноним (-), 12:57 , 05-Июн-11, (65) Полнейшая чушь Сравнили тёплое с мягким и наказали кого попало Давайте, до ку, Iridium (?), 14:05 , 05-Июн-11, (73) –1 Здесь обсуждение в группе Go http groups google com group golang-nuts browse_, Аноним (-), 14:05 , 05-Июн-11, (74) // golang-nuts Хахаха, эпичные парни Они сами заранее ответили на вопрос are you, Аноним (-), 19:44 , 05-Июн-11, (104) –1 // Про мышей не забудьте , Аноним (-), 02:05 , 06-Июн-11, (132) Как всегда особо порадовала попытка жаберов сравниться по скорости с нормальными, Аноним (-), 16:20 , 05-Июн-11, (89) // У них это постоянно То орут, что java не тормозит, то упорото доказывают, что j, croster (ok), 18:02 , 05-Июн-11, (95) // Быстрее в 1 4 раза , Аноним (-), 19:46 , 05-Июн-11, (106) Go обосрался куда сильнее, но почему-то это не вызывает таких же сильных эмоций , qwerqwwe (?), 20:26 , 05-Июн-11, (111) // Про Go изначально так и сказали это наш yблюдок, никому нахрен не нужен, но на, Аноним (-), 03:29 , 06-Июн-11, (135) –1 А почему эта статистика должна вызывать эмоции даже если бы ява просрала бы все, bvf (ok), 13:18 , 06-Июн-11, (148) +1 Результаты статистического сравнения зависит от того кто платит Ясень пень что , bvf (ok), 13:25 , 06-Июн-11, (149) О-хо-хонюшки Опять детский сад Ну нельзя сравнивать языки на основании одного-, gegMOPO4 (ok), 20:32 , 05-Июн-11, (113) +1 // JFYIhttp shootout alioth debian org , vle (ok), 23:24 , 05-Июн-11, (125) // И самое разумное там сказано на этой странице http shootout alioth debian org, gegMOPO4 (ok), 14:24 , 06-Июн-11, (150) // Да, я просто к тому, что какие-никакие бенчмарки, включающиеболее одного теста, , vle (ok), 00:33 , 10-Июн-11, (180) Да, каждый читает и понимает их в меру своей распущенности , gegMOPO4 (ok), 00:43 , 10-Июн-11, (181) Давайте сравнивать IBM Lotus Symphony Embedded Java Eclipse RCP и Oracle Op, iZEN (ok), 01:45 , 06-Июн-11, (129) +1 // Если ты не в курсе, OOo даже не C , но с намёками на срaную жаву слили с замено, Аноним (-), 03:31 , 06-Июн-11, (136) –3 // Cделай хотя бы раз cd usr ports editors openoffice org-3 make install clea, iZEN (ok), 07:42 , 06-Июн-11, (139) A KDE2 вам не пропатчить , ХРЕН (?), 12:52 , 06-Июн-11, (146) –1 Вот еще для забавыhttp code google com p go issues detail id 9Кое-где очень ве, vle (ok), 23:22 , 05-Июн-11, (124) Ээээ Знаете, такие тесты напоминают мне один случай В двух соседних деревнях, Аналитик (?), 01:59 , 07-Июн-11, (172) –1 Показатели, относительно оптимизированного варианта на С Признаком Opt отм, Николай (??), 17:10 , 10-Июн-11, (182) // Да, и последняя таблица -- это не производительность, а Время выполнения , Николай (??), 17:12 , 10-Июн-11, (183) 1,3,6,12,13,25,29,52,53,60,62,65,73,74,89,113,124,172,182

Сообщения

[Сортировка по времени | RSS]

3. "В Google провели сравнение производительности C++, Java, Go ..."	+7 +/–
Сообщение от Аноним (-), 05-Июн-11, 00:17
Т. е. они сами признали, что Go не нужен?
Ответить | Правка | Наверх | Cообщить модератору

	4. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от SCHigi (?), 05-Июн-11, 00:29
	у Go совсем другая цель, нежели скорость или там размер кода - повышение производительности труда программистов и легкость сопровождения кода. И он ещё в самом начале своего развития.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "В Google провели сравнение производительности C++, Java, Go ..."	–3 +/–
	Сообщение от Аноним (-), 05-Июн-11, 00:34
	Не, у них цель - повышение продаж оборудования производителями серверов. Судя по столь диким результатам. Просрать в девяносто раз по потреблению памяти - жесть! Даже ява не настолько ужасно себя показала.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от Аноним (-), 05-Июн-11, 00:41
	> Не, у них цель - повышение продаж оборудования производителями серверов. Судя по > столь диким результатам. Просрать в девяносто раз по потреблению памяти - > жесть! Даже ява не настолько ужасно себя показала. Из этих результатов не видно, как оно масштабируется. Может у него есть некий минимум потребления,  а потом рост медленный.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (-), 05-Июн-11, 01:42
	> Из этих результатов не видно, как оно масштабируется. Не, ну почему-же. Из этих результатов прекрасно видно что программа на Go вообще не взлетела бы на 32-битной системе - там 16Гб сожрать просто не судьба вообще. По жрачу памяти масштабируется что надо - 16.2Гб, а хоть и vsz -это сииииильно :)))
	Ответить | Правка | Наверх | Cообщить модератору

	17. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 01:06
	Это затраты связанные со сборкой мусора, указать сколько точно потребляет программа на GO трудно.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	20. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (-), 05-Июн-11, 01:33
	Да какая мне разница? Меня волнует как оно будет работать в сумме. От их сборки мусора нельзя же отказаться, или где?!
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от Аноним (17), 05-Июн-11, 02:43
	Э… смотрите, GO создан для того чтобы писать программы, серверы, которые будут работать продолжительное время без остановки. Писался с расчетом один сервер — один сервис (не считая системных). Это то, как работает гугл и большие компании. В данном случае оптимизации потребления виртуальной памяти вообще очень преждевременны, я даже где-то читал, что они этим и не начинали заниматься, так как гораздо важнее скорость компиляции, чем планки памяти. Насчет того что на 32-битах не взлетит, так это надо быть дауном чтобы так думать и вообще не иметь не малейшего понятия о работе виртуальной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В Google провели сравнение производительности C++, Java,..."	+2 +/–
	Сообщение от anonymous (??), 05-Июн-11, 04:14
	> GO создан для того чтобы писать программы, серверы, которые будут > работать продолжительное время без остановки. ... > так как гораздо важнее скорость компиляции, чем планки памяти. только мне кажется, что на сервере гораздо важнее скорость работы скомпилированного кода и потребляемые ним ресурсы, а не скорость компиляции?
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 04:53
	Скорость в прикладных задачах http, обработка изображений у GO на уровне C++, чуть медленнее, но уж куда быстрее Java. При том, что не нужно заботится о памяти, для меня выигрыш очевиден. Чуть проще (меньше кода) можно писать на Scala, используя функциональную парадигму. Тем более не будем забывать, что GO самый молодой язык из всех. Если уж хочется высокой скорости обработки соединений и уж «нечеловеческой» масштабируемости, то надо было Erlang включить, в нем хоть «математики» и медленная, но все остальное на высоте, а «математику» можно вынести на C/C++ или даже на железо.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "В Google провели сравнение производительности C++, Java,..."	+1 +/–
	Сообщение от anonymous (??), 05-Июн-11, 05:06
	я, кагбэ, ещё и на ресурсы намекал. что-то картинка с памятью меня совершенно не радует. честное слово, я уж лучше Dylan тогда возьму, на нём хоть писать приятней.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 05:15
	Не совсем понял, что не радует? Менеджмент памяти, типа выделили 17ГБ? Вы наверное просто не понимаете как память работает в системах с виртуальной памятью и что означает это число. Если вам будет проще, то я запустил эти тесты у себя и при выполнении GO не наблюдалось каких либо подтормаживаний и т.д. Вот скриншот с результатами максимальной нагрузки: http://www.cl.ly/7KDe Потребление памяти у C++ было где-то в 2.8 раза меньше.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??), 05-Июн-11, 05:22
	> Не совсем понял, что не радует? Менеджмент памяти, типа выделили 17ГБ? Вы > наверное просто не понимаете как память работает в системах с виртуальной > памятью и что означает это число. это число означает то, что менеджер памяти — хреновый. (на всякий случай: не надо мне пояснять, что такое virtual memory, зачем в процессорах mmu, как делается garbage collection и прочие элементарные вещи; я не только знаю, но и писал это все — кроме mmu, конечно, потому как микросхемы не дизайнил; вменяемой программе столько незакомиченой памяти не надо)
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 05:26
	Для начало надо было бы уточнить, что вообще делает программа. Потом надо бы вспомнить, что GO декларируется как concurent language (собственно как Erlang, который выжирает и не такое количество ОЗУ). Потом было бы неплохо пошерстить в нете на тему менеджмента памяти в этих самых concurent & soft realtime languages. Если вам действительно интересно, пройдите весь этот процесс. Если вам просто хочется поспорить, то это с кем-то другим. Приятных снов)
	Ответить | Правка | Наверх | Cообщить модератору

	43. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??), 05-Июн-11, 05:29
	я, собственно, не имел опыта конкретно с эрлангом, но то, что столько памяти не надо — видно по результатам других языков. если языку надо — работа с памятью в этом языке сделана криворукими макаками. к «реалтаймовости» это имеет отношение опосредованое, в том плане, что она тоже, видимо, сделана криворукими макаками, раз одна из ключевых систем была им уже доверена.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 05:35
	> я, собственно, не имел опыта конкретно с эрлангом, но то, что столько > памяти не надо — видно по результатам других языков. если языку > надо — работа с памятью в этом языке сделана криворукими макаками. > к «реалтаймовости» это имеет отношение опосредованое, в том плане, что она > тоже, видимо, сделана криворукими макаками, раз одна из ключевых систем была > им уже доверена. Ну вот спорят до сих пор, зачем Erlang'у столько памяти нужно, много лет спорят. А им отвечают, хотите все наши профиты — просто забудьте и используйте Erlang дальше, неизвестно зачем хотите много свободной памяти — используйте Java'у, Scala и т.д. Так собственно и живем. Так что для меня такое поведение GO, скорее плюс перед другими, уж лучше тормознуть на секунду перед стартом, чем потом тормозить отдавая/принимая данные от клиентов, как это делает та же Java.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	46. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 05:58
	Ну, не знаю, сказал же вам, посмотрите что за тест проходят программы, вам должно стать ясно почему concurent-языки столько будут выжирать. Если взять просто GO, и написать программку которая обрабатывает http (POST, GET, PUT), то памяти оно будет жрать меньше Java, это точно, насчет C++ не скажу. Как под нагрузкой, так и просто с один клиентом. Насчет Erlang я, если честно, так сразу не могу угадать, о какой из тысяч серьезных программ написанных на Erlang, вы говорите. Как варианты: Riak, Mnesia, Ejabberd, Disco, CouchDB, Misultin, RabbitMQ, Erlyvideo. Это самые попсовые open source и на слуху. Большинство софта написанного на Erlang пишется с использованием фреймворка OTP, который, в отличии от самого языка, достаточно сложен в освоении и требует очень высокой квалификации программиста, гораздо выше среднего. Поэтому софт в основном пишется коммерческий.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В Google провели сравнение производительности C++, Java,..."	–2 +/–
	Сообщение от anonymous (??), 05-Июн-11, 06:08
	> Ну, не знаю, сказал же вам, посмотрите что за тест проходят программы, вот честное слово: лень. если этот тест показывает, как не неприспособленой к реалиям конкретного языка задаче некий язык сливает — тест проводили тупые макаки. если язык просто слил — язык делали тупые макаки. что совой об пень, что пнём об сову. > Насчет Erlang я, если честно, так сразу не могу угадать, о какой > из тысяч серьезных программ написанных на Erlang, вы говорите. о том, что широко используется in the wild: ejabberd. всё остальное — известные, но нишевые вещи. я не сказал, что на эрланге ничего достойного нет, и тем более не сказал, что ничего не пишут in-house. > который, в отличии от самого языка, достаточно сложен в освоении и требует очень высокой квалификации программиста, гораздо выше среднего у меня есть личное мнение, что если фреймворк сложен для освоения, то он как-то неправильно сделан. задача фреймворка — облегчать работу, а не усложнять. если сложность освоения фреймворка сравнима со сложностью создания своего велосипеда… ну, я лично сделаю велосипед. особенно, если язык достаточно «элитарный», и всё равно никакой взаимозаменяемости винтиков (как у жабы, например) там нет априори.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	48. "В Google провели сравнение производительности C++, Java,..."	+1 +/–
	Сообщение от Аноним (17), 05-Июн-11, 06:15
	> вот честное слово: лень. Уж я тут помочь не смогу никак вам. > о том, что широко используется in the wild: ejabberd. всё остальное — известные, но нишевые вещи Ejabberd тоже нишевый, ничего обычного в нем я не вижу. Хотя может у него нету альтернатив достойных, поэтому он ставится по умолчанию… Разве что так. > у меня есть личное мнение, что если фреймворк сложен для освоения, то он как-то неправильно сделан. задача фреймворка — облегчать работу, а не усложнять. Ну тогда давайте забросим функциональное программирование, да и Scala тоже, еще можно выбросить из пайтона всю «сложную функциональщину», а boost это ж ваще ад :) OTP делает Erlang самым надежным из всех языков программирования, ради такого постараться явно стоит. > и всё равно никакой взаимозаменяемости винтиков (как у жабы, например) там нет априори. Не понял к чему это.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	49. "В Google провели сравнение производительности C++, Java,..."	–1 +/–
	Сообщение от anonymous (??), 05-Июн-11, 06:25
	> Ejabberd тоже нишевый, ничего обычного в нем я не вижу. Хотя может > у него нету альтернатив достойных, поэтому он ставится по умолчанию… Разве > что так. в своё время особо и не было. а потом я как-то перестал искать, потому что у меня нет серверов, где понадобятся системы такого масштаба. > Ну тогда давайте забросим функциональное программирование а каким боком функциональщина относится к сложности фреймворка? предлагаю не смешивать «сложность фреймворка» и «немассовость идей, на которых он построен». > да и Scala тоже я только «за». > еще можно выбросить из пайтона всю «сложную функциональщину» лучше всего — вместе с гвидобейсиком. > а boost это ж ваще ад и ещё какой: натягивают ужа на ежа. > OTP делает Erlang самым надежным из всех языков программирования, > ради такого постараться явно стоит. возможно, я не в курсе. хотя мне мало понятно, как *усложнение* структуры может повысить её *надёжность*. чем сложнее — тем больше потенциальных точек отказа. > Не понял к чему это. к тому, что в некоторых случаях велосипедить строго запрещают. ибо тех же жабокодеров — пяток за пучок, и если каждому позволить велосипедить, то их будет сложно заменять (они и так-то особым интеллектом не отличаются, а уж если начнут свои велосипеды строчить…) программист на эрланге — в общем случае — товар штучный, и вполне возможно, что лучше позволить ему делать велосипеды. по крайней мере, я так предполагаю.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	50. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (17), 05-Июн-11, 06:31
	Ну раз для вас все так черно-бело, могу вас поздравить — вы достигли состояния дзен. Теперь можно идти работать в гугл, получив крутой дедовский ящик, а в свободное время писать программы одна строка — одна процессорная инструкция.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	51. "В Google провели сравнение производительности C++, Java,..."	–1 +/–
	Сообщение от anonymous (??), 05-Июн-11, 06:34
	> Ну раз для вас все так черно-бело жутко интересно, где «чёрно-белость». ну, кроме того, что я уже немолодой пень, и привык называть фигню фигнёй, а не политкорректно «некоей штучкой».
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	151. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (-), 06-Июн-11, 14:38
	> и привык называть фигню фигнёй, а не политкорректно «некоей штучкой». Зачет, зачет :). Old-school detected :D
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	115. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonimus (?), 05-Июн-11, 21:37
	http://steve.vinoski.net/pdf/IEEE-Reliability_with_Erlang.pdf
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	42. "В Google провели сравнение производительности C++, Java,..."	+1 +/–
	Сообщение от anonymous (??), 05-Июн-11, 05:27
	чуть поясню: подобное «резервирование» вредно уже тем, что система не может предсказать, понадобится ли программе действительно вся эта память, или жирная дура затребовала столько на случай, если больше никогда не подвезут и золотую рыбку фугасом пришибёт. а если эта программа ещё и ключевой компонент системы, то вполне можно предположить, что программа знает, что делает — и больше никому регионов не давать, потому что «всё — столик забронирован». чтобы ключевой компонент внезапно не врезал дуба. собственно, это называется… ну, скажем так: не совсем корректное поведение. если заменить три последних слова в прошлом предложении обсценной лексикой, то получится где-то то, что я имел в виду.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	58. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Andrew Kolchoogin (?), 05-Июн-11, 10:53
	> собственно, это называется… ну, скажем так: не совсем корректное поведение. Угу. "Анноит -- пиши комплейн..." :) Строго говоря, ядрам современных операционных систем плевать на VSZ, вопрос в другом: как ЭТО запустить на 32-хбитных платформах. А также в обосновании сильного повышения производительности от такого монстроидного VSZ. Тем более, что malloc()-то deferred. Зааллоцировать можно сколько угодно^W^Wстолько, сколько лимиты для процесса позволят, а вот есть ли это ОЗУ IRL, так сказать -- это вопрос непростой. Можно и SIGKILL получить по "Out of swap space"...
	Ответить | Правка | Наверх | Cообщить модератору

	67. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??), 05-Июн-11, 13:29
	> Строго говоря, ядрам современных операционных систем плевать на VSZ … > Тем более, что malloc()-то deferred. Зааллоцировать можно сколько угодно^W^Wстолько, > сколько лимиты для процесса позволят, а вот есть ли это ОЗУ > IRL, так сказать — это вопрос непростой. Можно и SIGKILL получить > по «Out of swap space»… вот. я на это и намекал, собственно. если всей оперативки со всем свопом, положим 8 гигов, а пять програм потребовали по два — то регионы-то свои они получат. а когда все дружно попытаются их использовать, придёт им полярный лис. это раз. два. если оно *реально* занимает память (благодаря ли кривому менеджеру памяти, или ещё почему), и при этом не монопольное — рано или поздно её начнут бить^w^w^w начнётся задорный своп. что, несомненно, только добавит скорости и реалтаймовости. в общем, всё просто: «тормозит? твой сервер гуано! бери новый, бери два!» эх, где ж на всех бамбуковых палок набрать?
	Ответить | Правка | Наверх | Cообщить модератору

	109. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от Аноним (-), 05-Июн-11, 19:53
	> наверное просто не понимаете как память работает в системах с виртуальной > памятью и что означает это число. Это некоторые особо тупые анонимы не понимают что на 32-битной системе процесс не может схапать более 2^32 байтов памяти. Не важно, реальная она там будет или виртуальная. Там чисто физически на адрес в рамках процесса есть только 32 бита. И все.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	99. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (-), 05-Июн-11, 19:35
	> Насчет того что на 32-битах не взлетит, так это надо быть дауном > чтобы так думать и вообще не иметь не малейшего понятия о > работе виртуальной памяти. Действительно, надо. Поскольку я не даун, я знаю что в системе с 32-битной адресацией... процессу ВНЕЗАПНО нельзя сожрать более 4Гб памяти. Любой. Виртуальной, физической. Не важно. Адресация - 32 бита. Это 4Гб. Система в целом - может жрать и больше, если постараться. А вот 1 процесс - не может ввсе-равно.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	9. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним123321 (ok), 05-Июн-11, 00:40
	> у Go совсем другая цель, нежели скорость или там размер кода нет. как раз именно _скорость_ :-) и не просто так его сделали компилируемым в машинный-код
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	31. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от анон (?), 05-Июн-11, 03:28
	>повышение производительности труда программистов и легкость сопровождения кода Эта цель достигается не созданием новых языков, а правильной организацией обучения будущих программистов. А задачи go вполне понятны - чтобы было медленно и прожорливо. Иначе как же железо новое впаривать?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	63. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (-), 05-Июн-11, 12:28
	Бред какой-то. Гуглу нужно бросать свои разработки и идти в министерство образования ЗОГа?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В Google провели сравнение производительности C++, Java, Go ..."	+3 +/–
	Сообщение от szh (ok), 05-Июн-11, 14:36
	> А задачи go вполне понятны - чтобы было медленно и прожорливо. Иначе как же железо новое впаривать? Гугл не занимается продажей железа, думать головой будешь прежде чем "разоблачать" ?
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	57. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от anonymous (??), 05-Июн-11, 10:46
	А какя тогда цель? Go заохавает мир? =)
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема