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

Hadoop установил новый мировой рекорд, opennews (?), 16-Май-09, (0) [смотреть все] А сейчас мы послушаем начальника транспортного цеха Переписать Apache Had, iZEN (ok), 23:01 , 16-Май-09, (4) Кто там говорил про тормоза Java User239 Ну ну , Аноним (-), 23:49 , 16-Май-09, (5) +2 // ну думайте, что говорите же производительность кластера не является доказательс, stone3 (?), 00:52 , 17-Май-09, (6) // речь не о производительности кластера, а о рекорде установленном приложением нап, idkfa (?), 06:48 , 17-Май-09, (9) –1 // Платформа Hadoop состоит из нескольких элементов В основании лежит распределен, Jet (??), 10:49 , 17-Май-09, (14) Вы бы хоть в SVN им заглянули, прежде чем тут чушь писать ximaera loderunner , ximaera (?), 13:33 , 18-Май-09, (36) решение на основе явы может с успехом применяться в тех случаях, когда быстродей, Voviandr (ok), 01:26 , 17-Май-09, (7) // Может ли алюминий использоваться для производства молока - Может, из него делают, Jet (??), 10:54 , 17-Май-09, (16) // Hadoop установил новый мировой рекорд, pavlinux (ok), 15:11 , 17-Май-09, (21) Ну предположим что сортировка проводилась методом пузыря Как этот алгоритм ре, Jet (??), 18:34 , 17-Май-09, (26) –1 А зачем такое предполагать Очевидно что на Map-Reduce делать сортировку пузырем, crypto5 (?), 19:00 , 17-Май-09, (27) –1 Зачем предполагать, когда можно проверить Реализован он так static class Tota, ximaera (?), 13:57 , 18-Май-09, (39) http developer yahoo net blogs hadoop Yahoo2009 pdf -- тут написано какое soft, crypto5 (?), 19:43 , 17-Май-09, (30) я говорил в статье не написано сколько они этот свой кластер тюнили, не удивлюс, sluge (??), 11:28 , 18-Май-09, (33) Дык сравните с таким же переписанных на сях А то если соревноваться только с сам, User294 (??), 14:06 , 18-Май-09, (40) с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило , funky_dennis (?), 07:18 , 17-Май-09, (10) // ну так и обьемы данных не маленькие , crypto5 (?), 08:57 , 17-Май-09, (11) На С таки оно было бы существенно быстрее , Deniel (?), 10:48 , 17-Май-09, (13) // Возможно оно и так было на С Hadoop написанный на жабе - не производит никаки, Jet (??), 10:53 , 17-Май-09, (15) –1 // Пф Производительность зависит не от той демонстрационной утилиты, которую ребят, ximaera (?), 13:40 , 18-Май-09, (37) Специально для Вас There are now 4 Hadoop map reduce applications to support th, ximaera (?), 13:53 , 18-Май-09, (38) Религия C еще заразнее, чем я думал , Knuckles (ok), 13:19 , 17-Май-09, (17) На С его нет И не будет , Vasiliy (??), 14:23 , 17-Май-09, (18) // Вообще GoogleFS MapReduse это вроде на С Python сделано Но открытых на С , uZver (ok), 11:53 , 18-Май-09, (34) http scienceblogs com goodmath 2006 11 the_c_is_efficient_language_fa phpI dec, Volodymyr Lisivka (?), 15:09 , 17-Май-09, (19) // Зачем одновремено давать ссылку и искажать те факты которые по этой ссылке есть , Zzz (??), 16:44 , 17-Май-09, (24) // А прочитать ниже было уже никак About a year later, testing a new JIT for Java, noname (??), 17:07 , 17-Май-09, (25) +1 Отсюда мораль придет злобный асемблерщик и всех порвет как всегда - сями и т п , User294 (??), 14:16 , 18-Май-09, (41) // Что это, мы-то, как раз-таки, имеем представление в какой код транслируется байт, iZEN (ok), 14:34 , 18-Май-09, (43) MapReduce очень просто реализовать на чём угодно, хоть на bash-е Есть уже готов, Volodymyr Lisivka (?), 15:06 , 18-Май-09, (44) Вот, кстати, примитивная реализация Hadoop раскидывание задач по кластеру на b, Volodymyr Lisivka (?), 16:19 , 18-Май-09, (45) User294 считает по другому Не было разрывов, не было , Аноним (-), 19:16 , 18-Май-09, (48) Only in your dreams JAVA could be faster than C , Marinov (?), 16:28 , 18-Май-09, (46) // http www mail-archive com hadoop-user lucene apache org msg02139 htmlMapReduce, Volodymyr Lisivka (?), 17:38 , 18-Май-09, (47) А как они определили, что 1Тб отсортирован Сколько на это уходит время А если , pavlinux (ok), 15:10 , 17-Май-09, (20) // Ну прогу проверки в сто раз легче написать , crypto5 (?), 19:00 , 17-Май-09, (28) Куда такие объёмый данных Гораздо проще разбить на логически разделённые блоки , FSA (??), 15:12 , 17-Май-09, (22) // Ну ведь бывают ситуации когда разбить не получается , crypto5 (?), 19:01 , 17-Май-09, (29) Так понт Hadoop как раз и заключается что он САМ разбивает на блоки и размазывае, uZver (ok), 11:56 , 18-Май-09, (35) Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop н, kandrew (?), 15:52 , 17-Май-09, (23) // http developer yahoo net blogs hadoop 2008 07 apache_hadoop_wins_terabyte_sort, Pasystem (??), 09:33 , 18-Май-09, (32) // Итого добавили мощи - подтянули рекорд А если еще вдвое больше машин Что, де, User294 (??), 14:17 , 18-Май-09, (42)   // Не надо считать всех дураками Если бы было целесообразнее использовать с , а р, Аноним (-), 19:26 , 18-Май-09, (49)   тогда кем их считать, если они говорят глупости НЕ МОЖЕТ байт-код исполняться бы, аноним (?), 19:36 , 18-Май-09, (50) –1   gt оверквотинг удален Может так оказатся что качество С компилера хуже чем JIT, crypto5 (?), 19:44 , 18-Май-09, (51)   Ну вот когда будут доказательства - отлично, поговорим Вот только про рекорд , User294 (??), 20:30 , 18-Май-09, (53)   Сколько раз тебе нужно говорить, что lzma- и zip-алгоритмы в JavaSE написаны с и, iZEN (ok), 20:35 , 18-Май-09, (54)   gt оверквотинг удален Так а я и не говорю что джава круче Вы просто утверждал, crypto5 (?), 20:45 , 18-Май-09, (55)   МОЖЕТ Да может же А потому что JIT оптимизирует код под конкретный процессор , Аноним (-), 20:12 , 18-Май-09, (52)   А пруфлинк можно , crypto5 (?), 20:46 , 18-Май-09, (56)   К пущей досаде жабистов могу припомнить что пруфлинк про gcc и как раз вот такую, User294 (??), 21:25 , 18-Май-09, (58)   А проверки характерные для managed кода куда денутся Испарятся Зато си-компилято, User294 (??), 21:22 , 18-Май-09, (57)   На численных алгоритмах все обычно без managed проверок идет их еще компилятор , Аноним (-), 22:49 , 18-Май-09, (60)   Ну я запустил этот QuickLZ У меня на 2GHz Celeron 550 оно показывает скорость с, Volodymyr Lisivka (?), 03:57 , 19-Май-09, (62)   s и я не даю и я даю , Volodymyr Lisivka (?), 03:59 , 19-Май-09, (63)   -march и про остальные опции вы, видимо, не слыхали Любая профилировка - огромны, Аноним (-), 22:01 , 18-Май-09, (59)   Слыхали, а вот вы не понял сути вопроса Вы что - будете генерировать 10 выполни, Аноним (-), 22:53 , 18-Май-09, (61)   Компилятор, не Никто не сомневался, что java - зрелая и развитая технология Толь, аноним (?), 08:15 , 19-Май-09, (64) +1   Под виртуальную машину сотню мегабайт на каждом компьютере - и всё Остальное та, Интегратор Императора (?), 12:29 , 19-Май-09, (65)   вынесем за скобки сомнительный пассаж про неподдатливых программеров платформа j, аноним (?), 14:20 , 19-Май-09, (66)   И это правильно 50 грамм кремния должны стоить дешевле двух кило мозга , Аноним (-), 14:38 , 19-Май-09, (67)   4,5,10,13,20,22,23

Сообщения

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

	42. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от User294 (??), 18-Май-09, 14:17
	>>все-таки поменьше. ... >*  910 nodes >* 2 quad core Xeons @ 2.0ghz per a node Итого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег не хватило? :)
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 18-Май-09, 19:26
	>Итого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег >не хватило? :) Не надо считать всех дураками. Если бы было целесообразнее использовать с++, а раз шли на рекорд то целесообразна была скорость, то использовали бы с++. Только они вот делают, а вы все повторяете устаревшие догмы, стыдно, товарищ.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Hadoop установил новый мировой рекорд"	–1 +/–
	Сообщение от аноним (?), 18-Май-09, 19:36
	>Не надо считать всех дураками тогда кем их считать, если они говорят глупости? НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется в идеальный машинный код (что в обозримом будущем не предвидится), то подобные же методы можно использовать в си-компиляторе. и уже си-код будет исполняться так же быстро, но без дополнительного jit оверхеда. >устаревшие догмы 2+2=4 устаревшая догма
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от crypto5 (?), 18-Май-09, 19:44
	>[оверквотинг удален] > >тогда кем их считать, если они говорят глупости? >НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется >в идеальный машинный код (что в обозримом будущем не предвидится), то >подобные же методы можно использовать в си-компиляторе. и уже си-код будет >исполняться так же быстро, но без дополнительного jit оверхеда. > >>устаревшие догмы > >2+2=4 устаревшая догма Может так оказатся что качество С компилера хуже чем JIT компилера. Ну а JIT компиляция штука происходящая один раз и ее время никак не зависит от обьема входных данных задачи  обсуждаемой в топике.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от User294 (??), 18-Май-09, 20:30
	>Может так оказатся что качество С компилера хуже чем JIT компилера. Ну вот когда будут доказательства - отлично, поговорим :).Вот только про рекорд - протрубили, а то что рекорд персональный, Васи Пупкина и в отсутствие чемпиона мира по бегу - не сказали.Чем некоторые особенно braindead`нутые жабисты и пользуются вереща про супер-скорость :D.Если кто не понял - доказательство что X быстрее Y делается так: берется X на нем реализуется некий алгоритм.Берется Y и на нем тоже реализуется тот же алгоритм, 1 в 1.Сравнивается время за которое алгоритм отстреливается там и сям, делаются выводы. А когда вопли вида "Y отстрелялся за столько-то, за сколько там отстреляется X мы не проверяли но Y - рулез, рулез!!!" - это по ламерски как-то совсем. А насчет JIT - managed код не дается на халяву.Как я понимаю - проверки всякие подшиваются и прочая, чтоб он managed был и оставался.И местами все это может сиииииииильно икнуться где-то в глубоком цикле например.Где пара лишних команд где их всего 2 и было будет означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео - везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает в эти самые разы, невзирая на верещания местных чудиков :D.И кстати чудики почему-то очень не любят проводить честные сравнения в упомянутом выше стиле.Помнится предложение переписать quicklz на жаве так как им хочется они проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный такой подход к бенчмаркам - или соревноваться сами с собой или ныкаться по кустам если чемпион по бегу рядом :)
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от iZEN (ok), 18-Май-09, 20:35
	>А насчет JIT - managed код не дается на халяву.Как я понимаю >- проверки всякие подшиваются и прочая, чтоб он managed был и >оставался.И местами все это может сиииииииильно икнуться где-то в глубоком цикле >например.Где пара лишних команд где их всего 2 и было будет >означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом >на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео >- везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает >в эти самые разы, невзирая на верещания местных чудиков :D. Сколько раз тебе нужно говорить, что lzma- и zip-алгоритмы в JavaSE написаны с использованием нативных библиотек, потому что УЖЕ написаны и переписывать==пустая трата времени. >И кстати >чудики почему-то очень не любят проводить честные сравнения в упомянутом выше >стиле.Помнится предложение переписать quicklz на жаве так как им хочется они >проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный >такой подход к бенчмаркам - или соревноваться сами с собой или >ныкаться по кустам если чемпион по бегу рядом :) DelphiTest: http://izen.dev.juga.ru/downloads/delphitest.zip JavaTest: http://izen.dev.juga.ru/downloads/javatest.zip (написано в далёком 2002г)
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от crypto5 (?), 18-Май-09, 20:45
	>[оверквотинг удален] >например.Где пара лишних команд где их всего 2 и было будет >означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом >на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео >- везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает >в эти самые разы, невзирая на верещания местных чудиков :D.И кстати >чудики почему-то очень не любят проводить честные сравнения в упомянутом выше >стиле.Помнится предложение переписать quicklz на жаве так как им хочется они >проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный >такой подход к бенчмаркам - или соревноваться сами с собой или >ныкаться по кустам если чемпион по бегу рядом :) Так а я и не говорю что джава круче. Вы просто утверждали что Джава даже теоретически не может быть быстрее С компилера, а я думаю что это не так. Ну а сравнение языков на разных алгоритмах можно посмотреть например вот здесь: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al.... Как мы видим джава идет по производительности один в один с С но безбожно сливает по памяти.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	52. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 18-Май-09, 20:12
	>>Не надо считать всех дураками > >тогда кем их считать, если они говорят глупости? >НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется >в идеальный машинный код (что в обозримом будущем не предвидится), то >подобные же методы можно использовать в си-компиляторе. и уже си-код будет >исполняться так же быстро, но без дополнительного jit оверхеда. МОЖЕТ!!! Да может же! А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной кеша и набором команд, а не под сферического коня в вакууме как делает это Си компилятор. А также JIT например ничего не мешает профилировать методы на лету, инлайнить наиболее часто выполняющиеся, а не все и т.п. JIT может автоматически распараллеливать циклы на многопроцессорных машинах. И отрыв от Си все дальше и дальше. Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее. > >>устаревшие догмы > >2+2=4 устаревшая догма У вас пока получается 2+2=5, изучайте арифметику, а также азы компиляции и оптимизации.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	56. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от crypto5 (?), 18-Май-09, 20:46
	>JIT может автоматически распараллеливать циклы на многопроцессорных машинах. А пруфлинк можно?
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от User294 (??), 18-Май-09, 21:25
	>А пруфлинк можно? К пущей досаде жабистов могу припомнить что пруфлинк про gcc и как раз вот такую вот технологию оптимизации для него :D недавно пролетал на опеннете.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от User294 (??), 18-Май-09, 21:22
	>МОЖЕТ!!! Да может же! А проверки характерные для managed кода куда денутся?Испарятся? >как делает это Си компилятор. Зато си-компилятор не втюхивает с ножом к горлу всяческие проверки, сбор мусора и т.п..И - да, за счет этого вполне можно пальнуть себе в пятку если програмер дятел (buffer overrun, etc).Но если он не дятел - он может скажем заранее проверить данные и - тогда совсем не обязательно молотить лишнюю проверку где-то в глубоком цикле работающем с этим буфером например.А вот jit совсем не обязан знать что прогер вон там уже проверил входные данные и посчитал заранее что все ок, а поскольку managed то он никак не может допустить выход за пределы буфера и прочая.А значит-тупо воткнет проверок и т.п., просадив скорость в эти самые разы, т.к. половину цикла займут проверки на вшивость и прочая а не полезная деятельность. >А также JIT например ничего не мешает профилировать методы на лету, инлайнить >наиболее часто выполняющиеся, а не все и т.п. Ага, только вот думать он не научится.И потому ради соблюдения managed может набить каких-нить проверок и костылей там где этого по факту было не надо. >JIT может автоматически распараллеливать циклы на многопроцессорных машинах. Это не только JIT может.И?Кстати а что если сишники-сиплюсплюсники тоже отпрофилируют и заинлайнят?Они то с включенным мозгом могут это и получше безмозглой железяки сделать в принципе.Или вообще читерство: мелкий кус на асме оптимизнуть.Вон кодеки-когда скорости мало - програмеры творят чудеса.И в итоге - рантайм детект типа проца и пинок в горячих циклах аккуратно оптимизнутого кода на асме под конкретные процы(как минимум, конкретные типы SIMD-команд).Кусочки небольшие, т.к. только для самых горячих циклов.Ну а фигли, когда хочется HD в реалтайме декодить а проца ну никак не хватает - еще и не так разопрешься :D. И какой там jit, оно простым сям то в пару раз может вставить влегкую.Я вон как-то компилил XVID "чисто на си" и сравнивал vs "C+asm вставки".Как-то не впечатлило.В смысле, сишная версия очень тормозная оказалась супротив "обычной" где си+асм. >И отрыв от Си все дальше и дальше. Ну так побейте вон сишную версию того же quicklz хотя-бы на яве.И хрен с ней с параллельностью, хоть на 1 ядре для начала - слабо?А то по бенчам авторов либы явистая версия сливает сишной в 2.5-3 раза при равных условиях.Жабисты злобно прошипели что дескать авторы оной либы не владеют явой и ... свалили в кусты.Вместо того чтобы выдать на гора переписанную ими версию либы "от тех кто явой владеет" которая бы натянула сишную версию, как это было ими разрекламлено :).Кстати если у вас не кластер а просто многопроцессорник - иногда распараллеливание дурную шутку играет, отравляя кэши процессора(ов) и т.п. - в итоге порой просаживая скорость вместо выигрыша.Такие приколы тоже бывают. А так - у меня есть H.264 файлик который мой процессор еле-еле декодирует в реалтайме юзая x264 (с его си+асм вставками).А давайте вы его на яве натянете?Ведь вы же так круто оптимизируетесь на много ядер?У меня как раз 2 ядра у проца - нормально вполне.Ну и посмотрим как там jit по скорости - неукладывание в реалтайм в таком случае сразу видно, хи-хи.Не хотите? :D >Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее. Пожалуйста - сгенерите.Вон тот же quicklz - достаточно простой и при том чувствительный к скорости проца и памяти алгоритм.И планка известна - сишная версия.В отличие от абстрактного соревнования сам с собой при котором как ни ползи к финишу а номер 1 всяко будешь, тут вон результат "чемпиона мира по бегу" как точка отсчета есть. >У вас пока получается 2+2=5, изучайте арифметику, а также азы компиляции и >оптимизации. Пока что любители тыкать в букварь не провели одинаковых честных сравнений :).В итоге в теории оно может и круто.А на практике доказать?В честном бенче?Почему жабисты или соревнуются сами с собой (рекорды ставят) или драпают в кусты?Это подозрительно... %)
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	60. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 18-Май-09, 22:49
	>>МОЖЕТ!!! Да может же! > >А проверки характерные для managed кода куда денутся?Испарятся? > На численных алгоритмах все обычно без managed проверок идет (их еще компилятор удаляет, до jit даже не доходят). А основное время как раз числодробилки и занимают. >[оверквотинг удален] > >>JIT может автоматически распараллеливать циклы на многопроцессорных машинах. > >Это не только JIT может.И?Кстати а что если сишники-сиплюсплюсники тоже отпрофилируют и >заинлайнят?Они то с включенным мозгом могут это и получше безмозглой железяки >сделать в принципе.Или вообще читерство: мелкий кус на асме оптимизнуть.Вон кодеки-когда >скорости мало - програмеры творят чудеса. >А так - у меня есть H.264 файлик который мой процессор еле-еле >декодирует в реалтайме юзая x264 (с его си+асм вставками).А давайте вы >его на яве натянете? А ведь никто не спорил что руки творят чудеса. Да, включив мозг можно побить и сишный компилер и jit, но мы вроде речь ведем про обычную написанную программу. Но уверен что включив мозг можно и на яве написать декодер h264 с отличной производительностью, но чудес не бывает, пространства для тюнинга здесь меньше, если только сам jit тюнить. > >>И отрыв от Си все дальше и дальше. > >Ну так побейте вон сишную версию того же quicklz хотя-бы на яве. Ну и что? Есть достаточно авторитетные тест и я их помнится приводил когда Си сливает яве на вычислительных алгоритмах, только вы их упорно игнорируете, а зря, см. ссылку ниже. Я бы все таки сказал что на Си должен писать сишник, на яве жибист. >>Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее. > >Пожалуйста - сгенерите. Так и генерят! Взять тот же cli .net. Они допольнительную информацию используют на полную катушку. > >Пока что любители тыкать в букварь не провели одинаковых честных сравнений :). А вот и привели :) http://kano.net/javabench/ И вывод автора - The results I got were that Java is significantly faster than optimized C++ in many cases. >итоге в теории оно может и круто.А на практике доказать?В честном >бенче?Почему жабисты или соревнуются сами с собой (рекорды ставят) или драпают >в кусты?Это подозрительно... %) А работать кто будет?
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Volodymyr Lisivka (?), 19-Май-09, 03:57
	>Ну так побейте вон сишную версию того же quicklz хотя-бы на яве. Ну я запустил этот QuickLZ. У меня на 2GHz Celeron 550 оно показывает скорость сжатия в ~380MBps после того, как код отработает хотя-бы секунду (и я не даю методу завершится, чтоб не вынуждать JVM делать замену кода на лету). У него на Core 2 Duo 2.6GHz сишный код сжимает со скоростю 263MBps. Может он просто ошибся в бенчмарке (там много граблей)? У меня: Intel(R) Celeron(R) CPU          550  @ 2.00GHz Linux 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux java version "1.6.0_12" Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	63. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Volodymyr Lisivka (?), 19-Май-09, 03:59
	>(и я не даю методу завершится, чтоб не вынуждать JVM делать замену кода на лету). s/и я не даю/и я даю/
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 18-Май-09, 22:01
	>А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной >кеша и набором команд, а не под сферического коня в вакууме >как делает это Си компилятор. -march и про остальные опции вы, видимо, не слыхали. >А также JIT например ничего не мешает профилировать методы на лету, инлайнить >наиболее часто выполняющиеся, а не все и т.п. Любая профилировка - огромные накладные расходы, так что такую статистику собирать не станут, а заинлайнят согласно статическому анализу - как в С,  так и jit. >JIT может автоматически распараллеливать циклы на многопроцессорных машинах. И отрыв от Си >все дальше и дальше. Вообще-то это умеет и gcc, о чем вы снова не слыхали. Что такое openmp, знаете? В 4.4 есть то же самое, но "на лету". >Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее. Конечно, так вас и допустят профилировать реальные процессы. А тестовый код, да, отпрофайлят на ура, только потом эту информацию никак не подсунуть jit с реальной задачей :)
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	61. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 18-Май-09, 22:53
	> >>А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной >>кеша и набором команд, а не под сферического коня в вакууме >>как делает это Си компилятор. > >-march и про остальные опции вы, видимо, не слыхали. Слыхали, а вот вы не понял сути вопроса. Вы что - будете генерировать 10 выполнимых файлов под все возможные процессоры? >Вообще-то это умеет и gcc, о чем вы снова не слыхали. Что >такое openmp, знаете? В 4.4 есть то же самое, но "на >лету". Знаем, не надо наездов. > >>Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее. > >Конечно, так вас и допустят профилировать реальные процессы. А тестовый код, да, >отпрофайлят на ура, только потом эту информацию никак не подсунуть jit >с реальной задачей :) JIT может все. И чем дальше тем больше он будет уметь. Вот собственно все.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Hadoop установил новый мировой рекорд"	+1 +/–
	Сообщение от аноним (?), 19-Май-09, 08:15
	>Вы что - будете генерировать 10 выполнимых файлов под все возможные процессоры? Компилятор, не? >JIT может все Никто не сомневался, что java - зрелая и развитая технология. Только для исполнения она требует немного - а если считать память, то в десятки и сотни раз - больше машинного ресурса. Вот собственно всё.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Интегратор Императора (?), 19-Май-09, 12:29
	Под виртуальную машину сотню мегабайт на каждом компьютере - и всё. Остальное так же. Пора бы вам признать поражение, а также то, почему Java стал и остаётся одним из самых популярных языков программирования. Отнюдь не из-за пиара, в программерской среде он не играет роли.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от аноним (?), 19-Май-09, 14:20
	>почему Java стал и остаётся одним из самых популярных языков программирования. >Отнюдь не из-за пиара, в программерской среде он не играет роли. вынесем за скобки сомнительный пассаж про неподдатливых программеров. платформа java популярна, потому что крупным игрокам дешевле прикупить железа, чем нанять хороших специалистов.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Hadoop установил новый мировой рекорд"	+/–
	Сообщение от Аноним (-), 19-Май-09, 14:38
	>вынесем за скобки сомнительный пассаж про неподдатливых программеров. >платформа java популярна, потому что крупным игрокам дешевле прикупить железа, чем нанять >хороших специалистов. И это правильно! 50 грамм кремния должны стоить дешевле двух кило мозга!
	Ответить | Правка | Наверх | Cообщить модератору

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

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