Команда разработчиков системы распределенных вычислений Yahoo объявила (http://developer.yahoo.net/blogs/hadoop/2009/05/hadoop_sorts...) о том, что используя Apache Hadoop, они смогли побить мировой рекорд в сортировке неспецифичных (general purpose) данных. Новое значение рекорда — 1 терабайт за 62 секунды или петабайт за 16.25 часа. Измерения проводились на кластере Yahoo Hammer, который содержит приблизительно 3800 серверов, в каждом из которых по 2 четырех ядерных процессора Xeon 2.5ГГц, 4 SATA диска, 16Гб ОЗУ, 1Гбит сетевая карта. В качестве ОС используется REHL 5.1, а для обработки данных Sun Java JDK версий 1.6.0_05-b13 и 1.6.0_13-b03.Apache Hadoop — это открытая среда для проведения процессороемких распределенных вычислений. Ее использование позволяет приложениям получать доступ к массивам не структурированной информации петабайтного объема. Проект начал развиваться в качестве открытой альтернативы Google File System (GFS) и приприетарной реал...
URL: http://news.cnet.com/8301-13846_3-10242392-62.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=21767
"А сейчас мы послушаем начальника транспортного цеха..." ©
(Переписать Apache Hadoop на C++ и посмотреть. Я думаю, это нереально будет сделать в обозримый кусок времени. ;)
Кто там говорил про тормоза Java? User239? Ну ну.
>Кто там говорил про тормоза Java? User239? Ну ну.ну думайте, что говорите же. производительность кластера не является доказательством или опровержением производительности/работоспособности явы
речь не о производительности кластера, а о рекорде установленном приложением написанном на java
"
Платформа Hadoop состоит из нескольких элементов. В основании лежит распределенная файловая система Hadoop Distributed File System (HDFS), распределяющая файлы по нескольким узлам хранения в кластере Hadoop. Над файловой системой HDFS (в рамках рассмотрения этой статьи) располагается механизм MapReduce, состоящий из узлов типов JobTracker и TaskTracker.
"Вобще то тут не сказано что сама сортировка- производилась приложением написанном на джаве... Поэтому критичные к скорости компоненты- вполне могли быть написаны на самом что ни наесть.. вплоть до ассемблера... Сообщение таким образом говорит как раз о суммарной производительности кластера а не о достоинствах жабы...
Вы бы хоть в SVN им заглянули, прежде чем тут чушь писать.ximaera@loderunner:~$ svn ls http://svn.apache.org/repos/asf/hadoop/core/trunk/src/mapred
mapred-default.xml
org/
ximaera@loderunner:~$Вопрос на засыпку -- как, уже глядя на это, определить, что код будет на Java?
>Кто там говорил про тормоза Java? User239? Ну ну.решение на основе явы может с успехом применяться в тех случаях, когда быстродействие является определяющим фактором ? может. так никто и не сомневался.
>>Кто там говорил про тормоза Java? User239? Ну ну.
>
>решение на основе явы может с успехом применяться в тех случаях, когда
>быстродействие является определяющим фактором ? может. так никто и не сомневался.
>Может ли алюминий использоваться для производства молока?
- Может, из него делают алюминевые бидоны.
- Это функция транспортировки а не производства. Производят молоко все таки коровы...
> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker.
>> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker.Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на "Name Node and Job Tracker" ?
>>> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker.
>
>Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на
>"Name Node and Job Tracker" ?А зачем такое предполагать? Очевидно что на Map-Reduce делать сортировку пузырем это идиотизм..
>Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на
>"Name Node and Job Tracker" ?Зачем предполагать, когда можно проверить? Реализован он так: "static class TotalOrderPartitioner implements Partitioner<Text,Text>", далее здесь: http://svn.apache.org/viewvc/hadoop/core/trunk/src/examples/...
Вы школу в каком году заканчиваете?
>>>Кто там говорил про тормоза Java? User239? Ну ну.
>>
>>решение на основе явы может с успехом применяться в тех случаях, когда
>>быстродействие является определяющим фактором ? может. так никто и не сомневался.
>>
>
>Может ли алюминий использоваться для производства молока?
>- Может, из него делают алюминевые бидоны.
>- Это функция транспортировки а не производства. Производят молоко все таки коровы...
>http://developer.yahoo.net/blogs/hadoop/Yahoo2009.pdf -- тут написано какое software юзалось, про С++ там не слова! Все делалось на джава!
>Кто там говорил про тормоза Java? User239? Ну ну.я говорил. в статье не написано сколько они этот свой кластер тюнили, не удивлюсь если 2-3 мес
>Кто там говорил про тормоза Java? User239? Ну ну.Дык сравните с таким же переписанных на сях.А то если соревноваться только с самим собой в чистом поле - всегда будешь на первом месте почему-то :D.Даже можно рекорд установить.Свой.Персональный.А то что чемпиона мира по бегу рядом не было - можно и не упоминать, говоря про первое место :D
с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило...
>с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило...ну так и обьемы данных не маленькие..
На С++ таки оно было бы существенно быстрее :)
>На С++ таки оно было бы существенно быстрее :)Возможно оно и так было на С... Hadoop написанный на жабе - не производит никаких вычислений и никаких сортировок...это нечто иное
http://www.ibm.com/developerworks/ru/library/l-hadoop/index....
>Возможно оно и так было на С... Hadoop написанный на жабе -
>не производит никаких вычислений и никаких сортировок...это нечто иное
>http://www.ibm.com/developerworks/ru/library/l-hadoop/index....Пф. Производительность зависит не от той демонстрационной утилиты, которую ребята пускали ради рекорда (не сортировку же они рекламируют этим, подумайте сами), а от скорости Hadoop -- её, в конце концов, и измеряли. А Hadoop написан на Java.
Специально для Вас:"There are now 4 Hadoop map/reduce applications to support the benchmark:
1. TeraGen is a map/reduce program to generate the data.
2. TeraSort samples the input data and uses map/reduce to sort the data
into a total order.
3. TeraSum is a map/reduce program computes the 128 bit sum of the crc32
of each key/value pair.
4. TeraValidate is a map/reduce program that validates the output is
sorted and computes the sum of the checksums as TeraSum.
The update to the terasort programs will be checked in as HADOOP-5716."http://svn.apache.org/viewvc/hadoop/core/trunk/src/examples/.../
Проверка своих фантазий о том, что, "может быть, оно было на C", занимает 2 минуты. А отказ от этой проверки говорит о неуважении к другим участникам форума.
Религия C++ еще заразнее, чем я думал.
> На С++ таки оно было бы существенно быстрее :)На С++ его нет. И не будет.
>> На С++ таки оно было бы существенно быстрее :)
>
>На С++ его нет. И не будет.Вообще GoogleFS + MapReduse это вроде на С + Python сделано. Но открытых на С++ не предвидется.
> На С++ таки оно было бы существенно быстрее :)http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_...
I decided to do an experiment. I wrote the LCS algorithm in a bunch of different languages, to compare how complex the code was, and how fast it ran. I wrote the comp bio algorithm in C, C++, OCaml, Java, and Python, and recorded the results. What I got timing-wise for running the programs on arrays of 2000 elements each was:
* OCaml: 0.6 seconds *interpreted*, 0.3 seconds fully compiled.
* C: 0.8 seconds.
* Java: about 1 second for the JVM to start up, 0.7 seconds to run the code
* C++: 2.3 seconds.
* Python: over 5 minutes.
Зачем одновремено давать ссылку и искажать те факты которые по этой ссылке есть:*Java: 1 minute 20 seconds.
А прочитать ниже было уже никак?
"About a year later, testing a new JIT for Java, the Java time was down to 0.7 seconds to run the code, plus about 1 second for the JVM to start up."
> * OCaml: 0.6 seconds *interpreted*, 0.3 seconds fully
>compiled.Отсюда мораль: придет злобный асемблерщик и всех порвет как всегда - сями и т.п. явно сгенерен дерьмовый код в узком месте.В глубоких циклах достаточно жалкую пару команд сэкономить и будет о-го-го какой выигрыш в сумме :)
Кстати сишные компилеры умеют генерить в некоторых ситуациях дерьмовый код.Если кто вдруг не знал - сюрприз! :D
Впрочем жабистам и прочим придуркам которые даже не имеют представления в какой именно код трансформируется их конструкция - простительно.Что с тупых и убогих взять?Они только на форумах бухтеть умеют, а "под микроскопом" тот бред выдаваемый компилером и JIT ни разу не видели все-равно.Там же высокие концепции!Взять кластеров на 4-ядерниках побольше - и вот вам мировой рекорд!Главное взять достаточно много машин :D
>Впрочем жабистам и прочим придуркам которые даже не имеют представления в какой
>именно код трансформируется их конструкция - простительно.Что это, мы-то, как раз-таки, имеем представление в какой код транслируется байткод: на [i386] получается код x86, на [amd64] -- x86-64, на [sparc] -- код для risc-процессора SPARC, на [mips], очевидно же(!) -- код MIPS, на [arm] -- код ядра процессоров ARM, если нету пришлёпки Jazelle DBX.
Притом что байткод переносим между архитектурами без перекомпиляции исходников, а конкретная виртуальная машина оптимизирует выполнение "по месту" с учётом особенностей CPU (длина конвеера, количество РОН, размер кэша, объём оперативной памяти). Количество аппаратных параметров, которые учитываются JVM для обеспечения такой же скорости исполнения как и у блобов, полученных методом красноглазой оптимизации исходников C++, не так много, но они важны для выбора правильной стратегии GC и тем самым влияют на общий отклик java-приложения. Некоторые java-приложения замахиваются даже на реал-тайм режим исполнения (Oracle/BEA JRockit JVM, IBM J9).
>Что с тупых и убогих
>взять?Они только на форумах бухтеть умеют, а "под микроскопом" тот бред
>выдаваемый компилером и JIT ни разу не видели все-равно.Там же высокие
>концепции!Взять кластеров на 4-ядерниках побольше - и вот вам мировой рекорд!Главное
>взять достаточно много машин :DКто там говорил, что микроядро всё время будет проигрывать монолитному ядру в эффективности? Торвальдс(tm), кажется. Так напишите Hadoop на C/C++, чтобы доказать обратное. :))
>Кто там говорил, что микроядро всё время будет проигрывать монолитному ядру в
>эффективности? Торвальдс(tm), кажется. Так напишите Hadoop на C/C++, чтобы доказать обратное.
>:))MapReduce очень просто реализовать на чём угодно, хоть на bash-е. Есть уже готовые реализации на многих языках (просто поищи, например в QT 4.4.x она уже есть: QFuture mappedReduced(list, mapFunction, reducefunction) ). Основная проблема здесь в управляющей логике, которая должна эфективно разбивать на подзадачи, поддерживать высокий уровень надёжности и минимизировать блуждание данных по кластеру без нужды, иначе сетевая подсистема станет узким местом.
Проблема именно в *алгоритме* *управляющих* серверов.
Ява просто позволила найти достаточно толковых энтузиастов, которые оттюнили этот алгоритм. Перенести готовые наработки на другой язык - не проблема. Можна даже просто скомпилировать Cи++ и Яву в один бинарник при помощи gcj и не парится. Скорости от этого не прибавится - статическая оптимизация _сейчас_ проигрывает динамической.
>>Кто там говорил, что микроядро всё время будет проигрывать монолитному ядру в
>>эффективности? Торвальдс(tm), кажется. Так напишите Hadoop на C/C++, чтобы доказать обратное.
>>:))
>
>MapReduce очень просто реализовать на чём угодно, хоть на bash-е.Вот, кстати, примитивная реализация Hadoop (раскидывание задач по кластеру) на bash-e:
http://blog.last.fm/2009/04/06/mapreduce-bash-script
http://github.com/erikfrey/bashreduce/blob/master/br (3 страницы кода).PS.
Чел ищет сипласпласника... :-)
>Скорости от этого не прибавится - статическая оптимизация _сейчас_
>проигрывает динамической.User294 считает по другому! Не было разрывов, не было!!!
Only in your dreams JAVA could be faster than C++ :)
>Only in your dreams JAVA could be faster than C++ :)http://www.mail-archive.com/hadoop-user@lucene.apache.o...
MapReduce in C++ vs MapReduce in Java
... Java version was about 4 times quicker. ...
А как они определили, что 1Тб отсортирован?
Сколько на это уходит время?
А если N+1 элемент будет меньше чем N+2, а если N*(N+1)
Помимо доказательства верности алгоритма, надо доказать правильность его реализации.
А то что, Yahoo на своём заборе нарисовала, так это каждый умеет.
>А как они определили, что 1Тб отсортирован?
>Сколько на это уходит время?
>А если N+1 элемент будет меньше чем N+2, а если N*(N+1)
>Помимо доказательства верности алгоритма, надо доказать правильность его реализации.
>А то что, Yahoo на своём заборе нарисовала, так это каждый умеет.
>Ну прогу проверки в сто раз легче написать!
Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и поместить их на отдельные машины.
>Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и
>поместить их на отдельные машины.Ну ведь бывают ситуации когда разбить не получается?
>Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и
>поместить их на отдельные машины.Так понт Hadoop как раз и заключается что он САМ разбивает на блоки и размазывает по всем нодам кластера. Дальше алгоритмы гоняются в параллель по нодам и агрегируется результат.
"Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop на соревновании Terasort, равнялся 209 секундам."Интересно, там тоже было "приблизительно" 3800 серверов с такой же конфигурацией или все-таки поменьше.
>"Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop на соревновании Terasort,
>равнялся 209 секундам."
>
>Интересно, там тоже было "приблизительно" 3800 серверов с такой же конфигурацией или
>все-таки поменьше.http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoo...
* 910 nodes
* 2 quad core Xeons @ 2.0ghz per a node
* 4 SATA disks per a node
* 8G RAM per a node
* 1 gigabit ethernet on each node
* 40 nodes per a rack
* 8 gigabit ethernet uplinks from each rack to the core
* Red Hat Enterprise Linux Server Release 5.1 (kernel 2.6.18)
* Sun Java JDK 1.6.0_05-b13
>>все-таки поменьше....
>* 910 nodes
>* 2 quad core Xeons @ 2.0ghz per a nodeИтого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег не хватило? :)
>Итого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег
>не хватило? :)Не надо считать всех дураками. Если бы было целесообразнее использовать с++, а раз шли на рекорд то целесообразна была скорость, то использовали бы с++. Только они вот делают, а вы все повторяете устаревшие догмы, стыдно, товарищ.
>Не надо считать всех дуракамитогда кем их считать, если они говорят глупости?
НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется в идеальный машинный код (что в обозримом будущем не предвидится), то подобные же методы можно использовать в си-компиляторе. и уже си-код будет исполняться так же быстро, но без дополнительного jit оверхеда.>устаревшие догмы
2+2=4 устаревшая догма
>[оверквотинг удален]
>
>тогда кем их считать, если они говорят глупости?
>НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется
>в идеальный машинный код (что в обозримом будущем не предвидится), то
>подобные же методы можно использовать в си-компиляторе. и уже си-код будет
>исполняться так же быстро, но без дополнительного jit оверхеда.
>
>>устаревшие догмы
>
>2+2=4 устаревшая догмаМожет так оказатся что качество С компилера хуже чем JIT компилера. Ну а JIT компиляция штука происходящая один раз и ее время никак не зависит от обьема входных данных задачи обсуждаемой в топике.
>Может так оказатся что качество С компилера хуже чем JIT компилера.Ну вот когда будут доказательства - отлично, поговорим :).Вот только про рекорд - протрубили, а то что рекорд персональный, Васи Пупкина и в отсутствие чемпиона мира по бегу - не сказали.Чем некоторые особенно braindead`нутые жабисты и пользуются вереща про супер-скорость :D.Если кто не понял - доказательство что X быстрее Y делается так: берется X на нем реализуется некий алгоритм.Берется Y и на нем тоже реализуется тот же алгоритм, 1 в 1.Сравнивается время за которое алгоритм отстреливается там и сям, делаются выводы.
А когда вопли вида "Y отстрелялся за столько-то, за сколько там отстреляется X мы не проверяли но Y - рулез, рулез!!!" - это по ламерски как-то совсем.
А насчет JIT - managed код не дается на халяву.Как я понимаю - проверки всякие подшиваются и прочая, чтоб он managed был и оставался.И местами все это может сиииииииильно икнуться где-то в глубоком цикле например.Где пара лишних команд где их всего 2 и было будет означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео - везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает в эти самые разы, невзирая на верещания местных чудиков :D.И кстати чудики почему-то очень не любят проводить честные сравнения в упомянутом выше стиле.Помнится предложение переписать quicklz на жаве так как им хочется они проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный такой подход к бенчмаркам - или соревноваться сами с собой или ныкаться по кустам если чемпион по бегу рядом :)
>А насчет 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г)
>[оверквотинг удален]
>например.Где пара лишних команд где их всего 2 и было будет
>означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом
>на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео
>- везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает
>в эти самые разы, невзирая на верещания местных чудиков :D.И кстати
>чудики почему-то очень не любят проводить честные сравнения в упомянутом выше
>стиле.Помнится предложение переписать quicklz на жаве так как им хочется они
>проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный
>такой подход к бенчмаркам - или соревноваться сами с собой или
>ныкаться по кустам если чемпион по бегу рядом :)Так а я и не говорю что джава круче. Вы просто утверждали что Джава даже теоретически не может быть быстрее С компилера, а я думаю что это не так. Ну а сравнение языков на разных алгоритмах можно посмотреть например вот здесь: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al.... Как мы видим джава идет по производительности один в один с С но безбожно сливает по памяти.
>>Не надо считать всех дураками
>
>тогда кем их считать, если они говорят глупости?
>НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется
>в идеальный машинный код (что в обозримом будущем не предвидится), то
>подобные же методы можно использовать в си-компиляторе. и уже си-код будет
>исполняться так же быстро, но без дополнительного jit оверхеда.МОЖЕТ!!! Да может же!
А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной кеша и набором команд, а не под сферического коня в вакууме как делает это Си компилятор.А также JIT например ничего не мешает профилировать методы на лету, инлайнить наиболее часто выполняющиеся, а не все и т.п.
JIT может автоматически распараллеливать циклы на многопроцессорных машинах. И отрыв от Си все дальше и дальше.
Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее.
>
>>устаревшие догмы
>
>2+2=4 устаревшая догмаУ вас пока получается 2+2=5, изучайте арифметику, а также азы компиляции и оптимизации.
>JIT может автоматически распараллеливать циклы на многопроцессорных машинах.А пруфлинк можно?
>А пруфлинк можно?К пущей досаде жабистов могу припомнить что пруфлинк про gcc и как раз вот такую вот технологию оптимизации для него :D недавно пролетал на опеннете.
>МОЖЕТ!!! Да может же!А проверки характерные для 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, изучайте арифметику, а также азы компиляции и
>оптимизации.Пока что любители тыкать в букварь не провели одинаковых честных сравнений :).В итоге в теории оно может и круто.А на практике доказать?В честном бенче?Почему жабисты или соревнуются сами с собой (рекорды ставят) или драпают в кусты?Это подозрительно... %)
>>МОЖЕТ!!! Да может же!
>
>А проверки характерные для 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.>итоге в теории оно может и круто.А на практике доказать?В честном
>бенче?Почему жабисты или соревнуются сами с собой (рекорды ставят) или драпают
>в кусты?Это подозрительно... %)А работать кто будет?
>Ну так побейте вон сишную версию того же 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)
>(и я не даю методу завершится, чтоб не вынуждать JVM делать замену кода на лету).s/и я не даю/и я даю/
>А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной
>кеша и набором команд, а не под сферического коня в вакууме
>как делает это Си компилятор.-march и про остальные опции вы, видимо, не слыхали.
>А также JIT например ничего не мешает профилировать методы на лету, инлайнить
>наиболее часто выполняющиеся, а не все и т.п.Любая профилировка - огромные накладные расходы, так что такую статистику собирать не станут, а заинлайнят согласно статическому анализу - как в С, так и jit.
>JIT может автоматически распараллеливать циклы на многопроцессорных машинах. И отрыв от Си
>все дальше и дальше.Вообще-то это умеет и gcc, о чем вы снова не слыхали. Что такое openmp, знаете? В 4.4 есть то же самое, но "на лету".
>Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее.
Конечно, так вас и допустят профилировать реальные процессы. А тестовый код, да, отпрофайлят на ура, только потом эту информацию никак не подсунуть jit с реальной задачей :)
>
>>А потому что JIT оптимизирует код под конкретный процессор с конкретной величиной
>>кеша и набором команд, а не под сферического коня в вакууме
>>как делает это Си компилятор.
>
>-march и про остальные опции вы, видимо, не слыхали.Слыхали, а вот вы не понял сути вопроса. Вы что - будете генерировать 10 выполнимых файлов под все возможные процессоры?
>Вообще-то это умеет и gcc, о чем вы снова не слыхали. Что
>такое openmp, знаете? В 4.4 есть то же самое, но "на
>лету".Знаем, не надо наездов.
>
>>Зная runtime информацию можно сгенерировать более оптимальный код нежели не зная ее.
>
>Конечно, так вас и допустят профилировать реальные процессы. А тестовый код, да,
>отпрофайлят на ура, только потом эту информацию никак не подсунуть jit
>с реальной задачей :)JIT может все. И чем дальше тем больше он будет уметь. Вот собственно все.
>Вы что - будете генерировать 10 выполнимых файлов под все возможные процессоры?Компилятор, не?
>JIT может все
Никто не сомневался, что java - зрелая и развитая технология.
Только для исполнения она требует немного - а если считать память, то в десятки и сотни раз - больше машинного ресурса. Вот собственно всё.
Под виртуальную машину сотню мегабайт на каждом компьютере - и всё. Остальное так же. Пора бы вам признать поражение, а также то, почему Java стал и остаётся одним из самых популярных языков программирования. Отнюдь не из-за пиара, в программерской среде он не играет роли.
>почему Java стал и остаётся одним из самых популярных языков программирования.
>Отнюдь не из-за пиара, в программерской среде он не играет роли.вынесем за скобки сомнительный пассаж про неподдатливых программеров.
платформа java популярна, потому что крупным игрокам дешевле прикупить железа, чем нанять хороших специалистов.
>вынесем за скобки сомнительный пассаж про неподдатливых программеров.
>платформа java популярна, потому что крупным игрокам дешевле прикупить железа, чем нанять
>хороших специалистов.И это правильно!
50 грамм кремния должны стоить дешевле двух кило мозга!