| 1.4, iZEN (ok), 23:01, 16/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"А сейчас мы послушаем начальника транспортного цеха..." ©
(Переписать Apache Hadoop на C++ и посмотреть. Я думаю, это нереально будет сделать в обозримый кусок времени. ;)
| | |
| |
| 2.6, stone3 (?), 00:52, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Кто там говорил про тормоза Java? User239? Ну ну.
ну думайте, что говорите же. производительность кластера не является доказательством или опровержением производительности/работоспособности явы
| | |
| |
| 3.9, idkfa (?), 06:48, 17/05/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
речь не о производительности кластера, а о рекорде установленном приложением написанном на java
| | |
| |
| 4.14, Jet (??), 10:49, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
"
Платформа Hadoop состоит из нескольких элементов. В основании лежит распределенная файловая система Hadoop Distributed File System (HDFS), распределяющая файлы по нескольким узлам хранения в кластере Hadoop. Над файловой системой HDFS (в рамках рассмотрения этой статьи) располагается механизм MapReduce, состоящий из узлов типов JobTracker и TaskTracker.
"
Вобще то тут не сказано что сама сортировка- производилась приложением написанном на джаве... Поэтому критичные к скорости компоненты- вполне могли быть написаны на самом что ни наесть.. вплоть до ассемблера... Сообщение таким образом говорит как раз о суммарной производительности кластера а не о достоинствах жабы...
| | |
|
|
| 2.7, Voviandr (ok), 01:26, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Кто там говорил про тормоза Java? User239? Ну ну.
решение на основе явы может с успехом применяться в тех случаях, когда быстродействие является определяющим фактором ? может. так никто и не сомневался.
| | |
| |
| 3.16, Jet (??), 10:54, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Кто там говорил про тормоза Java? User239? Ну ну.
>
>решение на основе явы может с успехом применяться в тех случаях, когда
>быстродействие является определяющим фактором ? может. так никто и не сомневался.
>
Может ли алюминий использоваться для производства молока?
- Может, из него делают алюминевые бидоны.
- Это функция транспортировки а не производства. Производят молоко все таки коровы...
| | |
| |
| 4.21, pavlinux (ok), 15:11, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker. | | |
| |
| 5.26, Jet (??), 18:34, 17/05/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker.
Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на "Name Node and Job Tracker" ?
| | |
| |
| 6.27, crypto5 (?), 19:00, 17/05/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
 >>> For the larger sorts, we used 64 bit JVMs for the Name Node and Job Tracker.
>
>Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на
>"Name Node and Job Tracker" ?
А зачем такое предполагать? Очевидно что на Map-Reduce делать сортировку пузырем это идиотизм..
| | |
|
|
| 4.30, crypto5 (?), 19:43, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>>Кто там говорил про тормоза Java? User239? Ну ну.
>>
>>решение на основе явы может с успехом применяться в тех случаях, когда
>>быстродействие является определяющим фактором ? может. так никто и не сомневался.
>>
>
>Может ли алюминий использоваться для производства молока?
>- Может, из него делают алюминевые бидоны.
>- Это функция транспортировки а не производства. Производят молоко все таки коровы...
>
http://developer.yahoo.net/blogs/hadoop/Yahoo2009.pdf -- тут написано какое software юзалось, про С++ там не слова! Все делалось на джава!
| | |
|
|
| 2.33, sluge (??), 11:28, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Кто там говорил про тормоза Java? User239? Ну ну.
я говорил. в статье не написано сколько они этот свой кластер тюнили, не удивлюсь если 2-3 мес
| | |
| 2.40, User294 (??), 14:06, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Кто там говорил про тормоза Java? User239? Ну ну.
Дык сравните с таким же переписанных на сях.А то если соревноваться только с самим собой в чистом поле - всегда будешь на первом месте почему-то :D.Даже можно рекорд установить.Свой.Персональный.А то что чемпиона мира по бегу рядом не было - можно и не упоминать, говоря про первое место :D
| | |
|
| |
| 2.11, crypto5 (?), 08:57, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило...
ну так и обьемы данных не маленькие..
| | |
|
| |
| |
| 3.37, ximaera (?), 13:40, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Возможно оно и так было на С... Hadoop написанный на жабе -
>не производит никаких вычислений и никаких сортировок...это нечто иное
>http://www.ibm.com/developerworks/ru/library/l-hadoop/index.html
Пф. Производительность зависит не от той демонстрационной утилиты, которую ребята пускали ради рекорда (не сортировку же они рекламируют этим, подумайте сами), а от скорости Hadoop -- её, в конце концов, и измеряли. А Hadoop написан на Java.
| | |
| 3.38, ximaera (?), 13:53, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Специально для Вас:
"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/org/apache/hadoop
Проверка своих фантазий о том, что, "может быть, оно было на C", занимает 2 минуты. А отказ от этой проверки говорит о неуважении к другим участникам форума.
| | |
|
| 2.18, Vasiliy (??), 14:23, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> На С++ таки оно было бы существенно быстрее :)
На С++ его нет. И не будет.
| | |
| |
| 3.34, uZver (ok), 11:53, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> На С++ таки оно было бы существенно быстрее :)
>
>На С++ его нет. И не будет.
Вообще GoogleFS + MapReduse это вроде на С + Python сделано. Но открытых на С++ не предвидется.
| | |
|
| 2.19, Volodymyr Lisivka (?), 15:09, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
 > На С++ таки оно было бы существенно быстрее :)
http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php
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.
| | |
| |
| 3.24, Zzz (??), 16:44, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Зачем одновремено давать ссылку и искажать те факты которые по этой ссылке есть:
*Java: 1 minute 20 seconds.
| | |
| |
| 4.25, noname (??), 17:07, 17/05/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
А прочитать ниже было уже никак?
"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."
| | |
|
| 3.41, User294 (??), 14:16, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
> * OCaml: 0.6 seconds *interpreted*, 0.3 seconds fully
>compiled.
Отсюда мораль: придет злобный асемблерщик и всех порвет как всегда - сями и т.п. явно сгенерен дерьмовый код в узком месте.В глубоких циклах достаточно жалкую пару команд сэкономить и будет о-го-го какой выигрыш в сумме :)
Кстати сишные компилеры умеют генерить в некоторых ситуациях дерьмовый код.Если кто вдруг не знал - сюрприз! :D
Впрочем жабистам и прочим придуркам которые даже не имеют представления в какой именно код трансформируется их конструкция - простительно.Что с тупых и убогих взять?Они только на форумах бухтеть умеют, а "под микроскопом" тот бред выдаваемый компилером и JIT ни разу не видели все-равно.Там же высокие концепции!Взять кластеров на 4-ядерниках побольше - и вот вам мировой рекорд!Главное взять достаточно много машин :D
| | |
| |
| 4.43, iZEN (ok), 14:34, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Впрочем жабистам и прочим придуркам которые даже не имеют представления в какой
>именно код трансформируется их конструкция - простительно.
Что это, мы-то, как раз-таки, имеем представление в какой код транслируется байткод: на [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++, чтобы доказать обратное. :))
| | |
| |
| 5.44, Volodymyr Lisivka (?), 15:06, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Кто там говорил, что микроядро всё время будет проигрывать монолитному ядру в
>эффективности? Торвальдс(tm), кажется. Так напишите Hadoop на C/C++, чтобы доказать обратное.
>:))
MapReduce очень просто реализовать на чём угодно, хоть на bash-е. Есть уже готовые реализации на многих языках (просто поищи, например в QT 4.4.x она уже есть: QFuture mappedReduced(list, mapFunction, reducefunction) ). Основная проблема здесь в управляющей логике, которая должна эфективно разбивать на подзадачи, поддерживать высокий уровень надёжности и минимизировать блуждание данных по кластеру без нужды, иначе сетевая подсистема станет узким местом.
Проблема именно в *алгоритме* *управляющих* серверов.
Ява просто позволила найти достаточно толковых энтузиастов, которые оттюнили этот алгоритм. Перенести готовые наработки на другой язык - не проблема. Можна даже просто скомпилировать Cи++ и Яву в один бинарник при помощи gcj и не парится. Скорости от этого не прибавится - статическая оптимизация _сейчас_ проигрывает динамической.
| | |
| |
| 6.48, Аноним (-), 19:16, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Скорости от этого не прибавится - статическая оптимизация _сейчас_
>проигрывает динамической.
User294 считает по другому! Не было разрывов, не было!!!
| | |
|
|
|
|
|
| 1.20, pavlinux (ok), 15:10, 17/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как они определили, что 1Тб отсортирован?
Сколько на это уходит время?
А если N+1 элемент будет меньше чем N+2, а если N*(N+1)
Помимо доказательства верности алгоритма, надо доказать правильность его реализации.
А то что, Yahoo на своём заборе нарисовала, так это каждый умеет.
| | |
| |
| 2.28, crypto5 (?), 19:00, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А как они определили, что 1Тб отсортирован?
>Сколько на это уходит время?
>А если N+1 элемент будет меньше чем N+2, а если N*(N+1)
>Помимо доказательства верности алгоритма, надо доказать правильность его реализации.
>А то что, Yahoo на своём заборе нарисовала, так это каждый умеет.
>
Ну прогу проверки в сто раз легче написать!
| | |
|
| 1.22, FSA (??), 15:12, 17/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и поместить их на отдельные машины.
| | |
| |
| 2.29, crypto5 (?), 19:01, 17/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и
>поместить их на отдельные машины.
Ну ведь бывают ситуации когда разбить не получается?
| | |
| 2.35, uZver (ok), 11:56, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Куда такие объёмый данных? Гораздо проще разбить на логически разделённые блоки и
>поместить их на отдельные машины.
Так понт Hadoop как раз и заключается что он САМ разбивает на блоки и размазывает по всем нодам кластера. Дальше алгоритмы гоняются в параллель по нодам и агрегируется результат.
| | |
|
| 1.23, kandrew (?), 15:52, 17/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 "Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop на соревновании Terasort, равнялся 209 секундам."
Интересно, там тоже было "приблизительно" 3800 серверов с такой же конфигурацией или все-таки поменьше.
| | |
| |
| 2.32, Pasystem (??), 09:33, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>"Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop на соревновании Terasort,
>равнялся 209 секундам."
>
>Интересно, там тоже было "приблизительно" 3800 серверов с такой же конфигурацией или
>все-таки поменьше.
http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_s
* 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
| | |
| |
| 3.42, User294 (??), 14:17, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>>все-таки поменьше.
...
>* 910 nodes
>* 2 quad core Xeons @ 2.0ghz per a node
Итого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег не хватило? :)
| | |
| |
| 4.49, Аноним (-), 19:26, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Итого: добавили мощи - подтянули рекорд.А если еще вдвое больше машин?Что, денег
>не хватило? :)
Не надо считать всех дураками. Если бы было целесообразнее использовать с++, а раз шли на рекорд то целесообразна была скорость, то использовали бы с++. Только они вот делают, а вы все повторяете устаревшие догмы, стыдно, товарищ.
| | |
| |
| 5.50, аноним (?), 19:36, 18/05/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Не надо считать всех дураками
тогда кем их считать, если они говорят глупости?
НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется в идеальный машинный код (что в обозримом будущем не предвидится), то подобные же методы можно использовать в си-компиляторе. и уже си-код будет исполняться так же быстро, но без дополнительного jit оверхеда.
>устаревшие догмы
2+2=4 устаревшая догма
| | |
| |
| 6.51, crypto5 (?), 19:44, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>тогда кем их считать, если они говорят глупости?
>НЕ МОЖЕТ байт-код исполняться быстрее нативного. Даже если байт-код на лету компилируется
>в идеальный машинный код (что в обозримом будущем не предвидится), то
>подобные же методы можно использовать в си-компиляторе. и уже си-код будет
>исполняться так же быстро, но без дополнительного jit оверхеда.
>
>>устаревшие догмы
>
>2+2=4 устаревшая догма
Может так оказатся что качество С компилера хуже чем JIT компилера. Ну а JIT компиляция штука происходящая один раз и ее время никак не зависит от обьема входных данных задачи обсуждаемой в топике.
| | |
| |
| 7.53, User294 (??), 20:30, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Может так оказатся что качество С компилера хуже чем JIT компилера.
Ну вот когда будут доказательства - отлично, поговорим :).Вот только про рекорд - протрубили, а то что рекорд персональный, Васи Пупкина и в отсутствие чемпиона мира по бегу - не сказали.Чем некоторые особенно braindead'нутые жабисты и пользуются вереща про супер-скорость :D.Если кто не понял - доказательство что X быстрее Y делается так: берется X на нем реализуется некий алгоритм.Берется Y и на нем тоже реализуется тот же алгоритм, 1 в 1.Сравнивается время за которое алгоритм отстреливается там и сям, делаются выводы.
А когда вопли вида "Y отстрелялся за столько-то, за сколько там отстреляется X мы не проверяли но Y - рулез, рулез!!!" - это по ламерски как-то совсем.
А насчет JIT - managed код не дается на халяву.Как я понимаю - проверки всякие подшиваются и прочая, чтоб он managed был и оставался.И местами все это может сиииииииильно икнуться где-то в глубоком цикле например.Где пара лишних команд где их всего 2 и было будет означать что скорость работы попросту %$нется вдвое.Что и наблюдается с софтом на яве где скорость реально важна - сжатие, шифрование, кодирование\декодирование видео - везде где лишних тактов нахаляву хапнуть проблематично, жава почему-то сливает в эти самые разы, невзирая на верещания местных чудиков :D.И кстати чудики почему-то очень не любят проводить честные сравнения в упомянутом выше стиле.Помнится предложение переписать quicklz на жаве так как им хочется они проигнорировали, обосрав стиль его авторов которые родили жава-версию тем не менее.Оригинальный такой подход к бенчмаркам - или соревноваться сами с собой или ныкаться по кустам если чемпион по бегу рядом :)
| | |
| |
| 8.54, iZEN (ok), 20:35, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | Сколько раз тебе нужно говорить, что lzma- и zip-алгоритмы в JavaSE написаны с и... текст свёрнут, показать | | |
|
|
| 6.52, Аноним (-), 20:12, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | МОЖЕТ Да может же А потому что JIT оптимизирует код под конкретный процессор... большой текст свёрнут, показать | | |
| |
| 7.56, crypto5 (?), 20:46, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>JIT может автоматически распараллеливать циклы на многопроцессорных машинах.
А пруфлинк можно?
| | |
| 7.57, User294 (??), 21:22, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | А проверки характерные для managed кода куда денутся Испарятся Зато си-компилят... большой текст свёрнут, показать | | |
| |
| 8.60, Аноним (-), 22:49, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | На численных алгоритмах все обычно без managed проверок идет их еще компилятор ... большой текст свёрнут, показать | | |
|
| 7.59, Аноним (-), 22:01, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | -march и про остальные опции вы, видимо, не слыхали Любая профилировка - огромн... большой текст свёрнут, показать | | |
| |
| 8.61, Аноним (-), 22:53, 18/05/2009 [^] [^^] [^^^] [ответить] | +/– | Слыхали, а вот вы не понял сути вопроса Вы что - будете генерировать 10 выполни... большой текст свёрнут, показать | | |
| |
| 9.64, аноним (?), 08:15, 19/05/2009 [^] [^^] [^^^] [ответить] | +1 +/– | Компилятор, не Никто не сомневался, что java - зрелая и развитая технология То... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
