форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от opennews (??) on 05-Июн-11, 00:16
Роберт Хандт (Robert Hundt) из компании Google опубликовал (https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...) отчет с результатами тестирования качества оптимизации циклов в реализациях языков C++, Java, Go и Scala. Как и ожидалось, в тестах производительности и потребления памяти лидирует C++, но в отчете отмечается, что достижение высоких показателей связано с необходимостью проведения дополнительных оптимизаций, которые требуют дополнительной квалификации и зачастую не используются программистами среднего уровня. Оценка числа строк кода, потребовавшихся для реализации поставленной задачи (в списке указан размер, относительно кода на языке Scala). Наиболее компактным языком оказался Scala - для решения задачи потребовалось 658 строк. -  1.3x - C++ Dbg/Opt -  1.6x - Java -  1.9x - Java Pro -  1.0x - Scala -  0.5x - Scala Pro -  1.4x - Go -  1.2x - Go Pro Размер результирующих бинарных файлов, после сборки (показатели, относительно размера сген... URL: http://www.theregister.co.uk/2011/06/03/google_paper_on_cplu.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=30784
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "В Google провели сравнение производительности C++, Java, Go ..."	–6 +/–
Сообщение от Аноним (??) on 05-Июн-11, 00:16
ну все так и думали, правда несомневаюсь что гугловцы еще приукрасили статистику GO
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 00:31
	Офигенное приукрашение: 94x - Go (1249101 байт) Что, всего в ДЕВЯНОСТО ДВА раза слили? Epic failure.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	16. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от ZOG on 05-Июн-11, 01:04
	Ты смотри на другую колонку: real. Там результаты вполне сопоставимые. Ну и нужно учитывать, что Go ещё совсем молодой и плохо оптимизирован. Многие вещи пока не оптимизируют для простоты изменения.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	18. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 01:11
	Go линкуется стаически по умолчанию. Размер рантайма 1.1 + метр. Для сравнения если статически слинковать приплюснутый код то добавится около 750 кб(libc ...)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	23. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 01:39
	> Go линкуется стаически по умолчанию. Размер рантайма 1.1 + метр. > Для сравнения если статически слинковать приплюснутый код то добавится около 750 кб(libc > ...) А даже real памяти - какого черта в 4 раза больше сожрано? Даже если там метр рантайма, это никак не оправдывает сжирание 500 мегов. На virtual лучше вообще не смотреть - там просто хардкор! Интересно, а оно с 16.2Гб на 32-битной машине просто умерло бы сразу, обломившись столько скушать? ;)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	66. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 13:05
	Там сколько-то процентов от адресного пространства _резервируется_ заранее, для скорости. Это вообще никак не выделенная память. Если взять очень большой файл и сделать mmap, то к virt приплюсуется размер файла, но это же не значит, что он весь в память прочитался, почему же тогда на Go все так обижены?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	71. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 05-Июн-11, 13:46
	> Там сколько-то процентов от адресного пространства _резервируется_ заранее, для скорости. > Это вообще никак не выделенная память. Если взять очень большой файл > и сделать mmap, то к virt приплюсуется размер файла, но это > же не значит, что он весь в память прочитался, почему же > тогда на Go все так обижены? почитай повыше об этом.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	72. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 05-Июн-11, 13:47
	> почитай повыше об этом. тьфу. пониже. %-)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	98. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:32
	> Там сколько-то процентов от адресного пространства В случае 32-битной машины это 400% адресного пространства. Столько не дадут. В случае 64 бит машины - там доли процента и не разглядишь...
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	107. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:50
	> Это вообще никак не выделенная память. Если взять очень большой файл > и сделать mmap, то к virt приплюсуется размер файла, На 32-битной машине нельзя замапить в одном процессе более 2^32 адресов (реально даже меньше). Ваш Капитан, как обычно.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	92. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 17:25
	А статью то никто и не читал. 94х это относительно "C++ Opt" кода, который прошел минимум 3х очень квалифицированных программистов после написания. Были использованны внутренние гугловские библиотеки и ручное выравнивание памяти. Куда более интересен результат "C++ Dbg"...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	108. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:51
	> более интересен результат "C++ Dbg"... Чем же вам так интересен результат кода с дебаговой информацией? Это отладочная версия, в боевых условиях не применяется.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	160. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 17:09
	читайте внимательней "Dbg" - написанный на скорую руку код
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. "В Google провели сравнение производительности C++, Java, Go ..."	+2 +/–
Сообщение от Аноним (??) on 05-Июн-11, 00:33
Ява по минимуму слила в 3.7 раза. Ну жабисты ж не жадные, им в 4 раза больше серверов закупить не проблема :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

	84. "В Google провели сравнение производительности C++, Java, Go ..."	–4 +/–
	Сообщение от chinarulezzz (ok) on 05-Июн-11, 14:32
	ну, у них бабки водятся в отличии от цэпэпэшников. :)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	100. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:37
	> ну, у них бабки водятся в отличии от цэпэпэшников. :) Ну да, а LSE видимо бомжи вообще какие-то.И зарплатый и цппшиков как у бомжей, заметно на любом сайте с вакансиями.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	123. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от chinarulezzz (ok) on 05-Июн-11, 22:55
	> Ну да, а LSE видимо бомжи вообще какие-то. это те которые то на виндовсе, то на линуксе, то на сишарпе то на яве или цэпэпэ? > И зарплатый и цппшиков как > у бомжей, заметно на любом сайте с вакансиями. не спорю.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	152. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 14:44
	>> И зарплатый и цппшиков как у бомжей, заметно на любом сайте с вакансиями. > не спорю. Проблема только в том что жабисты получают хуже бомжей - у си++ "бомжей" зарплаты почему-то выше. Наверное, дело в том что на яве пишет каждая вторая специально обученная обезьяна, а си++ будучи довольно замороченным языком все-таки обеспечивает отсев идиотов от программеров. Разумеется, быдлокодер - дешевле специалиста. Только принцип как заплачено, так и зафигачено - не отменяли.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	163. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от chinarulezzz (ok) on 06-Июн-11, 21:47
	> Проблема только в том что жабисты получают хуже бомжей - разве что в твоём уютном параллельном мирке :) > у си++ "бомжей" зарплаты почему-то выше. Ниже) За явой - ынтырпрайз рынок, а за цэпэпэ - быдлософт и прикладуха. > Наверное, дело в том что на яве > пишет каждая вторая специально обученная обезьяна, а си++ будучи довольно замороченным > языком все-таки обеспечивает отсев идиотов от программеров. ггг) то-то с++ распространеннее чем С#, PHP и т.д.) Заморощенный язык для заморощенных погромистов :D > Разумеется, быдлокодер - дешевле > специалиста. Только принцип как заплачено, так и зафигачено - не отменяли. цэпэпэшникам виднее.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

12. "В Google провели сравнение производительности C++, Java, Go ..."	+10 +/–
Сообщение от Аноним (??) on 05-Июн-11, 00:54
А где C? Почему с Си не сравнивали?...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 01:22
	C обычно показывает себя чуть шустрее плюсов и чуть экономичнее.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	22. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 01:35
	> C обычно показывает себя чуть шустрее плюсов и чуть экономичнее. На нем сложно наворотами разбрасываться, что способствует культурному и экономному стилю программирования :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	56. "В Google провели сравнение производительности C++, Java, Go ..."	–5 +/–
	Сообщение от Tiny on 05-Июн-11, 10:25
	Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия под ООП с использованием структур.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	59. "В Google провели сравнение производительности C++, Java, Go ..."	+4 +/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 10:57
	> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. > void*, Мимикрия под ООП с использованием структур. Ограниченность C способствует удержанию в голове программиста идеи, что программа пишется для того, чтобы быстро работала и легко читалась другими людьми. А что до void * -- во-первых, reinterpret_cast<> и в C++ никто не отменял, а во-вторых -- попробуйте догадаться, не перелопатив ВЕСЬ исходный код, как именно на C++ отработает конструкция вида a+b. :)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Tiny on 05-Июн-11, 11:41
	Касты вас использовать никто не заставляет, ООП и шаблоны позволяют избавиться от такой необходимости, чего не скажешь о С. А по поводу оператора сложения - чем он в этом плане отличается от обычной функции?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	70. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 05-Июн-11, 13:43
	> А по поводу оператора сложения - чем он в этом плане отличается от обычной функции? тем, что у него есть исторически сложившееся значение. вообще, лучше бы CLU развили, а не отходы жизнедеятельности страусов.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	94. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 17:53
	> Касты вас использовать никто не заставляет, А void * -- заставляют, что ли? > ООП и шаблоны позволяют избавиться от такой необходимости, чего не скажешь о С. О, да. Особенно при обращении к совсем не объектной операционке. > А по поводу оператора сложения - чем он в этом плане отличается от обычной функции? Да вот именно, что в C++ -- ничем. А в C -- отличается. Поэтому я могу быть совершенно уверен, что оператор '+' в коде на C делает что-то, вполне соответствующее моему пониманию. А вот как именно его перегрузил былоко^Wпрограммист на C++ -- пойди пойми, не перелопатив исходники.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	114. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от анон on 05-Июн-11, 21:05
	>А void * -- заставляют, что ли? Порой без этого никак. >оператор '+' Данный оператор и в С++ будет делать что-то, вполне соответствующее вашему пониманию. Другое дело что в переменных типов отличных от стандартных данное действие бессмысленно.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	116. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:19
	> Данный оператор и в С++ будет делать что-то, вполне соответствующее вашему пониманию. Если его не перегрузили. А перегрузить его можно весьма эзотерическим способом. ;) И получить что-нибудь вида operator+(char *, int) -- тупо делающий realloc и заполняющий конец пробелами. Или не заполняющий?-) Правильно, см. исходники -- там и будет написано. ;)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	119. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от анон on 05-Июн-11, 22:29
	Ок. Зачем кому-то заниматься подобным? К тому же не стоит забывать и о макросах.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	121. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:41
	> Ок. Зачем кому-то заниматься подобным? О. Мы подошли к Главному Вопросу Программирования: "Зачем быдлокодить?" :))) Ответа на него у меня, к сожалению, нет. :))) > К тому же не стоит забывать и о макросах. #define TRUE FALSE ?-)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	161. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от анон on 06-Июн-11, 18:18
	Речь о другом на самом деле. Никто не вынуждает перегружать операторы. А без void* порой не обойтись.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	162. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от dmi3s (ok) on 06-Июн-11, 18:47
	> И получить что-нибудь вида operator+(char *, int) Конкретно вот это получить нельзя. Хотелось бы обсуждать вкус помидоров с теми, кто их ел.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	156. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 15:53
	> А в C -- отличается. Поэтому я могу быть совершенно уверен, что > оператор '+' в коде на C делает что-то, вполне соответствующее моему > пониманию. справедливости ради: #define + -
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	158. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 15:55
	но не везде прокатывает, да. %-)
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	69. "В Google провели сравнение производительности C++, Java,..."	–2 +/–
	Сообщение от anonymous (??) on 05-Июн-11, 13:40
	> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия > под ООП с использованием структур. ООП is not a silver bullet. also, ООП -- это мимикрия под структуры с усложнённым синтаксисом.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	77. "В Google провели сравнение производительности C++, Java,..."	–1 +/–
	Сообщение от Tiny on 05-Июн-11, 14:22
	>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия >> под ООП с использованием структур. > ООП is not a silver bullet. also, ООП -- это мимикрия под > структуры с усложнённым синтаксисом. Потрудитесь узначть что такое ООП для начала
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	79. "В Google провели сравнение производительности C++, Java,..."	–2 +/–
	Сообщение от anonymous (??) on 05-Июн-11, 14:26
	> Потрудитесь узначть что такое ООП для начала это фетиш некоторых wannabe-программистов. которые считают, что симула-подобные императивные языки — это Ъ и вершина технологий.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	117. "В Google провели сравнение производительности C++, Java,..."	+4 +/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:24
	>> Потрудитесь узначть что такое ООП для начала > это фетиш некоторых wannabe-программистов. которые считают, что симула-подобные > императивные языки — это Ъ и вершина технологий. Вы перегибаете палку. Для "объектируемых" алгоритмов ООП весьма и весьма полезен, т.к. сокращает процесс отладки. Для "необъектируемых" -- " -- " -- " -- " -- вреден, т.к. удлиняет -- " -- " -- " -- К примеру, практически любую GUI-софтину можно натянуть на объектную модель. С brute-force кракалкой паролей всё строго наоборот. Multi-threaded-сервер для ООП хорош. Сервер на основе FSM -- плох. От алгоритмов надо идти, а не от парадигмы. Ну и, конечно, "когда под рукой нет ничего, кроме молотка, всё вокруг кажется гвоздями" -- если программист никакой другой модели, кроме объектной, не знает -- плохи дела...
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	159. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 15:59
	> Вы перегибаете палку. немного. я, впрочем, не говорил, что ООП не нужно вовсе; я просто имел в виду, что есть определённый подвид людей, для которых всё, что не-ООП — это ерунда, устарело, ненужно и неудобно. опять же — можно было бы тролльнуть человека тем, что «ООП придумали те, кто не смог сделать замыкания», но, кажется, он бы всё равно не понял.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	138. "В Google провели сравнение производительности C++, Java,..."	–1 +/–
	Сообщение от oops_ on 06-Июн-11, 06:26
	>>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. void*, Мимикрия >>> под ООП с использованием структур. >> ООП is not a silver bullet. also, ООП -- это мимикрия под >> структуры с усложнённым синтаксисом. > Потрудитесь узначть что такое ООП для начала Это всего лишь надстройка над структурным программированием.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	164. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от анон on 06-Июн-11, 22:40
	ru.wikipedia.org/wiki/Объектно-ориентированное_программирование посмотрите пункт "основные понятия".
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	165. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 22:47
	> ru.wikipedia.org/wiki/Объектно-ориентированное_программирование посмотрите пункт > "основные понятия". мало того, что ссылка на русскую педию, так ещё и не в тему.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	166. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от анон on 06-Июн-11, 22:55
	А что не так с русской вики? Очередные придирки с претензией на интеллектуальность? Насчет ссылки - можно было и догадаться. Прочитайте основные принципы ООП и ответьте - причем здесь структуры?
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	170. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 23:09
	> причем здесь структуры? действительно: при чём струкруты к структурному программированию? советую уйти хотя бы в ту же вику и не возвращаться, пока не наступит просветление.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	173. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от анон on 07-Июн-11, 07:13
	Считайте что "структуры" в данном конексте и есть "структурное программирование".  Глупые придирки означают лишь то, что вам нечего ответить по делу.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

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

	175. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от анон on 07-Июн-11, 08:02
	>я также могу считать Дело ваше. Только в текущем контексте подмена слов вполне допустима. >мне достаточно этой «описки» По вашим постам впрочем не сложно понять, что основная цель спора - переход на личности. В таком случае нам с вами разговаривать не о чем.
	Ответить | Правка | ^ к родителю #174 | Наверх | Cообщить модератору

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

	177. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от анон on 07-Июн-11, 08:35
	>а вот то, что ты как минимум облажался, попутав «структуры» и «структурное программирование» Признаю, просто запутало то что изначально речь шла именно о структурах. >а до сих пор не понимаешь, почему после такой ошибки серьёзно с тобой разговаривать просто смешно. Понимаю и извиняюсь за ваше потраченное время.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	179. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 07-Июн-11, 08:49
	и вот почему сразу было не сказать: «пардон, ошибся, вас много, я один»? зачем было всё это время упорствовать? как будто больше никто никогда не ошибается…
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	101. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:38
	> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. Почему-то быдлокода на высокоуровневых языках куда больше. Если можно просто и безбашенно воротить огромные сложные сущности - это и начинают делать. А потом - ой, тормозит? Ну, докупите еще серверов!
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	118. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:29
	>> Ограниченность С не способствует ничему кроме быдлокодинга в крупных проектах. > Почему-то быдлокода на высокоуровневых языках куда больше. Потому, что пишут на них больше. Писали бы на языке Ассемблера -- быдлокод был бы там. А вообще -- возьмите ядро Linux'а версий примерно 2.0-2.2, и посмотрите в тамошний C. Вырвиглазный пиз^W^WОчень своеобразный стиль кодирования. :)
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	130. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Бублик on 06-Июн-11, 02:02
	Увы, быдлокода на любых массовых языках полно. Быдлокод чаще всего элементарно рентабельней.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	140. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от iZEN (ok) on 06-Июн-11, 07:47
	> Увы, быдлокода на любых массовых языках полно. Быдлокод чаще всего элементарно рентабельней. "Быдлокод" чаще всего поддаётся рефакторингу и покрытием Unit-тестами. Но! Быдлокод сначала пишут, а потом рефакторят и не делают предварительных оптимизаций, то есть "на выброс, а там поглядим, нужно ли". Для старой школы традиционен подход водопадной модели разработки, когда сначала много-много думают, потом просто думают, потом пишут, как монолит: на века.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	137. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от oops_ on 06-Июн-11, 06:20
	>> C обычно показывает себя чуть шустрее плюсов и чуть экономичнее. > На нем сложно наворотами разбрасываться, что способствует культурному и экономному стилю > программирования :) Насчет культуры поспорил бы. Слижком уж волно писать позволяет.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

13. "В Google провели сравнение производительности C++, Java, Go ..."	+7 +/–
Сообщение от Loooooker on 05-Июн-11, 00:58
Зато респект за честность. Интересно было бы регулярно смотреть результаты теста, скажем, раз в год.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Stax (ok) on 05-Июн-11, 01:55
Нормально так джава, нужно всего в 6 раз больше памяти, чем проге на C++ и до 12 раз медленнее..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Tav (ok) on 05-Июн-11, 02:39
Java и Scala компилируются в байт-код JVM, причем едва-ли есть существенные возможности JVM, недоступные из Java. Так каким образом реализация на Scala оказалась быстрее? Наводит на мысль, что вариант на Java реализован далеко не оптимальным образом.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	133. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Tav (ok) on 06-Июн-11, 02:18
	Так и есть: http://jeremymanson.blogspot.com/2011/06/scala-java-shootout...
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

52. "В Google провели сравнение производительности C++, Java, Go ..."	–2 +/–
Сообщение от Аноним (??) on 05-Июн-11, 08:41
Молодцы, полностью подтвердили статус-кво. Рулил, рулит и будет рулит в обозримом будующем только нативно компилируемый C/C++, поделки на виртуальных машинах - жрущая память тормозня, а их недоязык go не нужен вовсе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	147. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от kernel Doh on 06-Июн-11, 13:00
	Вот только сложность кода C++ по сравнению с JAVA в разы выше. И обычно гораздо дешевле купить +1 новый сервер, чем брать разработчика C++ стоимостью в 2xjava
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	155. "В Google провели сравнение производительности C++, Java,..."	+/–
	Сообщение от anonymous (??) on 06-Июн-11, 15:51
	> Вот только сложность кода C++ по сравнению с JAVA в разы выше. ORLY?
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

53. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Аноним (??) on 05-Июн-11, 09:05
Чем они собирали C++ код ? gcc или clang ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от croster (ok) on 05-Июн-11, 11:17
В тестах не хватает C#, интересно было бы глянуть на его результаты. Жалко, что в статье не описана точная конфигурация оборудования (указано лишь, что это древний Pentium IV), ОС и версии используемых копиляторов. В остальном все предсказуемо - по производительности и экономности расходования памяти C++ впереди планеты всей. Вчера наткнулся на интересное сравнение C# (MS .Net 4.0 и Mono 2.6.4), Java 1.6 и C++. Кому интересно - вот ссылка: http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	81. "В Google провели сравнение производительности C++, Java, Go ..."	+2 +/–
	Сообщение от iZEN (ok) on 05-Июн-11, 14:27
	> В тестах не хватает C#, интересно было бы глянуть на его результаты. Ага, ещё весь Windows-рантайм за ним тянуть и реестр до кучи. Весело.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	91. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от croster (ok) on 05-Июн-11, 17:03
	И что в этом плохого? Java ничуть не менее монструозная платформа.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	97. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от iZEN (ok) on 05-Июн-11, 19:05
	> И что в этом плохого? Java ничуть не менее монструозная платформа. Так, для общего развития: JRE занимает 15МБ.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	103. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:40
	> Так, для общего развития: JRE занимает 15МБ. Да ну? А чушки на 100 мегов в пакетах - это что?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	122. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 22:45
	Linux x86 - RPM Installer 20.06 MB Windows x86 Offline    15.77 MB
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	126. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от yz on 05-Июн-11, 23:42
	Это только рантайм, либы тянутся из JDK за приложением.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	127. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от iZEN (ok) on 06-Июн-11, 01:39
	> Это только рантайм, либы тянутся из JDK за приложением. Даже на компе, который физически не имеет доступ в интернет? :))
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	143. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от линуксоит on 06-Июн-11, 12:19
	при чем тут доступ в интернет?
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	169. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от iZEN (ok) on 06-Июн-11, 23:06
	> при чем тут доступ в интернет? Ответ был на это: "Это только рантайм, либы тянутся из JDK за приложением." Видимо товарищ, сказавший это, думает, что либы из состава JDK загружаются из интернета, если нет в запущенной JRE. Видимо товарищ не в курсе, что JDK — это комплект разработчика, ни его, ни его либы не нужно тянуть и устанавливать на клиентских компьютерах. JRE — это рантайм, то есть в ней всё необходимое, что нужно клиентским программе и библиотекам для работы.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	178. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 07-Июн-11, 08:45
	нах ява, на си все проще
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	157. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от dd (??) on 06-Июн-11, 15:54
	Стандартный либы тянутся как раз из рантайма ;) JDK для этого не нужен. Если для разработки Java-приложения не использовались third-party библиотеки, то для исполнения программы нужен только рантайм.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	153. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 14:46
	> Linux x86 - RPM Installer 20.06 MB > Windows x86 Offline 15.77 MB А если распаковать? Хотя, конечно, дотнет 4 его натянет - там примерно 200Мб барахла, чтоли...а если считать винду - ну наверное ее (или линукс или что там еще) тогда и для явы надо посчитать. А то ява почему-то тоже не запускается на bare metal.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	120. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Andrew Kolchoogin on 05-Июн-11, 22:39
	>> И что в этом плохого? Java ничуть не менее монструозная платформа. > Так, для общего развития: JRE занимает 15МБ. Да Тьюринг с вами! 47549669 байт у меня ТОЛЬКО rt.jar :)
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	128. "В Google провели сравнение производительности C++, Java, Go ..."	+2 +/–
	Сообщение от iZEN (ok) on 06-Июн-11, 01:41
	>>> И что в этом плохого? Java ничуть не менее монструозная платформа. >> Так, для общего развития: JRE занимает 15МБ. > Да Тьюринг с вами! > 47549669 байт у меня ТОЛЬКО rt.jar :) Ага. Потому что уровень ZIP-компрессии у rt.jar == 0. А в инсталляторе JRE используется алгоритм PACK200.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	131. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Бублик on 06-Июн-11, 02:04
	> И что в этом плохого? Java ничуть не менее монструозная платформа. Кофейный рантайм требует где-то около 10Мб. А сколько там шарп? Пятую сотню мегабайт уже разменял?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	141. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от croster (ok) on 06-Июн-11, 09:18
	>Пятую сотню мегабайт уже разменял? Ничего подобного, в районе 70 Мб. Вот, например: http://ftp.novell.com/pub/mono/archive/2.10.2/macos-10-x86/5...
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	144. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от линуксоит on 06-Июн-11, 12:21
	>>Пятую сотню мегабайт уже разменял? > Ничего подобного, в районе 70 Мб. Вот, например: > http://ftp.novell.com/pub/mono/archive/2.10.2/macos-10-x86/5... для обеих платформ 41 мерабайт .NET 4 Client, 25 мегабайт .NET 4 X86 или X64
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	112. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от none_first (ok) on 05-Июн-11, 20:29
	странное сравнение ;) а цель такого (смысл кода) сравнения? это никак не оценивает платформу.... в новости задача была и реализация, да и код (судя по кол-ву строк) присутствует, а по ссылке что-то странное
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

62. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
Сообщение от Александер on 05-Июн-11, 11:54
http://jeremymanson.blogspot.com/2011/06/scala-java-shootout...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

65. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Аноним (??) on 05-Июн-11, 12:57
Итого: Программу на С++ можно запустить и отлаживать на  любом компе, на Java и Scala - только с 2-мя гигами памяти и более быстрым процессором, а Go - вообще не запустится ни на одном современном десктопе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

73. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
Сообщение от Iridium on 05-Июн-11, 14:05
Полнейшая чушь! Сравнили тёплое с мягким и наказали кого попало. :( Давайте, до кучи, приплетём PHP, Perl, Delphi, C#… Что там ещё есть? Bash? Python? WhiteSpace? Да какая разница! Лишь бы сравнительную стаью написать!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

74. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Аноним (??) on 05-Июн-11, 14:05
Здесь обсуждение в группе Go: http://groups.google.com/group/golang-nuts/browse_thread/thr...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	104. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:44
	> Здесь обсуждение в группе Go: golang-nuts? Хахаха, эпичные парни! Они сами заранее ответили на вопрос "are you nuts?!". Как вы яхту назовете...
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	132. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 06-Июн-11, 02:05
	Про мышей не забудьте.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

89. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Аноним (??) on 05-Июн-11, 16:20
Как всегда особо порадовала попытка жаберов сравниться по скорости с нормальными языками. И снова Fail.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	95. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от croster (ok) on 05-Июн-11, 18:02
	У них это постоянно. То орут, что java не тормозит, то упорото доказывают, что java быстрее си и плюсов.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	106. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Аноним (??) on 05-Июн-11, 19:46
	> У них это постоянно. То орут, что java не тормозит, то упорото > доказывают, что java быстрее си и плюсов. Быстрее ... в 1/4 раза :))
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	111. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от qwerqwwe on 05-Июн-11, 20:26
	Go обосрался куда сильнее, но почему-то это не вызывает таких же сильных эмоций у жабафобов.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	135. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от Аноним (??) on 06-Июн-11, 03:29
	> Go обосрался куда сильнее, но почему-то это не вызывает таких же сильных > эмоций у жабафобов. Про Go изначально так и сказали: "это наш yблюдок, никому нахрен не нужен, но нам люб". А Java позиционировали как general-purpose.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	148. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от bvf (ok) on 06-Июн-11, 13:18
	А почему эта статистика должна вызывать эмоции? даже если бы ява просрала бы все тесты производительности за неё все еще платят хорошие деньги. Вообще производительность java это одна из мистических вещей, которую невероятно сложно оценить, так как все зависит от подбора параметров под конкретный алгоритм. И так же от количества статистики собранной jit компилятором для проведения оптимизаций. От используемого сборщика мусора. Ну и главный критерий влияющий на измерение статистики это то сколько микрософт заплатила за сравнение javavs.net. :) Гуглы вне подозрений, и поэтому их тесты представляют большой интерес. Но продажность всех остальных не вызывает сомнений.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	149. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от bvf (ok) on 06-Июн-11, 13:25
	Результаты статистического сравнения зависит от того кто платит. Ясень пень что любое сравнение технологий это маркетинговая реклама. И мы все хорошо знаем, что больше всего за маркетинг и рекламу платит микрософть.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

113. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
Сообщение от gegMOPO4 (ok) on 05-Июн-11, 20:32
О-хо-хонюшки. Опять детский сад. Ну нельзя сравнивать языки на основании одного-единственного теста. Нужны десятки, а то и сотни, самых разных тестов, потому, что, если что-то окажется ими непокрытым, то возможно на этом направлении будет совершенно иная картина. Хорошо, что Роберт хотя бы признал, что различные способы решения на одном и том же языке дают большую разницу, чем решения на разных языках (и нужно задание давать профессионалам, а не пытаться скалькировать решение на слабознакомом языке).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	125. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от vle (ok) on 05-Июн-11, 23:24
	> О-хо-хонюшки. Опять детский сад. JFYI http://shootout.alioth.debian.org/
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	150. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от gegMOPO4 (ok) on 06-Июн-11, 14:24
	И самое разумное там сказано на этой странице: http://shootout.alioth.debian.org/dont-jump-to-conclusions.php .
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	180. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от vle (ok) on 10-Июн-11, 00:33
	Да, я просто к тому, что какие-никакие бенчмарки, включающие более одного теста, в природе существуют. Как их "читать" - вопрос отдельный.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	181. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от gegMOPO4 (ok) on 10-Июн-11, 00:43
	Да, каждый читает (и понимает) их в меру своей распущенности. ;)
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	129. "В Google провели сравнение производительности C++, Java, Go ..."	+1 +/–
	Сообщение от iZEN (ok) on 06-Июн-11, 01:45
	> О-хо-хонюшки. Опять детский сад. Ну нельзя сравнивать языки на основании одного-единственного > теста. Нужны десятки, а то и сотни, самых разных тестов, потому, > что, если что-то окажется ими непокрытым, то возможно на этом направлении > будет совершенно иная картина. Давайте сравнивать: IBM Lotus Symphony (Embedded Java + Eclipse RCP) и Oracle OpenOffice (голимый C++) в офисной продуктивности.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	136. "В Google провели сравнение производительности C++, Java, Go ..."	–3 +/–
	Сообщение от Аноним (??) on 06-Июн-11, 03:31
	> Давайте сравнивать: IBM Lotus Symphony (Embedded Java + Eclipse RCP) и Oracle > OpenOffice (голимый C++) в офисной продуктивности. Если ты не в курсе, OOo даже не C++, но с намёками на срaную жаву слили с заменой на LO без жавы. Никому это VM'ное гoвнецo не нужно.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	139. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от iZEN (ok) on 06-Июн-11, 07:42
	>> Давайте сравнивать: IBM Lotus Symphony (Embedded Java + Eclipse RCP) и Oracle >> OpenOffice (голимый C++) в офисной продуктивности. > Если ты не в курсе, OOo даже не C++, Cделай хотя бы раз "cd /usr/ports/editors/openoffice.org-3/ && make install clean" во FreeBSD, потом будешь говорить, что оно не на C++. :))
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	146. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
	Сообщение от ХРЕН on 06-Июн-11, 12:52
	A KDE2 вам не пропатчить ?
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

124. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от vle (ok) on 05-Июн-11, 23:22
Вот еще для забавы http://code.google.com/p/go/issues/detail?id=9 Кое-где очень весело.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

172. "В Google провели сравнение производительности C++, Java, Go ..."	–1 +/–
Сообщение от Аналитик on 07-Июн-11, 01:59
Ээээ... Знаете, такие тесты напоминают мне один случай. В двух соседних деревнях, Горюновка и Бедяевка производились исследования длины половых членов мужской части народонаселения. Среднее значение по Горюновке не превысило 12 см, в то время, как в Бедяевке этот же показатель переваливал за 24 см. Злые языки поговаривали, что исследованию этому верить нельзя из-за различия в методологии: в Горюновке производились измерения, в то время, как в Бедяевке - опросы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

182. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
Сообщение от Николай (??) on 10-Июн-11, 17:10
"Показатели, относительно оптимизированного варианта на С++; Признаком "Opt" отмечен оптимальный вариант, предложенный в процессе анализа несколькими специализирующимися на оптимизации разработчиками. "Dbg" - написанный на скорую руку код" То ли перевод кривой то ли кто-то не разбирается совсем. Первая строка первой таблицы: 1.3x     C++ Dbg/Opt    (850 строк) Т.е. код один, а opt и dbg -- это различные режимы компиляции.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	183. "В Google провели сравнение производительности C++, Java, Go ..."	+/–
	Сообщение от Николай (??) on 10-Июн-11, 17:12
	Да, и последняя таблица -- это не производительность, а "Время выполнения"
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

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

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