The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Hadoop установил новый мировой рекорд

16.05.2009 18:55

Команда разработчиков системы распределенных вычислений Yahoo объявила о том, что используя Apache Hadoop, они смогли побить мировой рекорд в сортировке не специфичных (general purpose) данных. Новое значение рекорда — 1 терабайт за 62 секунды или петабайт за 16.25 часа. Измерения проводились на кластере Yahoo Hammer, который содержит приблизительно 3800 серверов, в каждом из которых по 2 четырехядерных процессора Xeon 2.5ГГц, 4 SATA диска, 16Гб ОЗУ, 1Гбит сетевая карта. В качестве ОС используется RHEL 5.1, а для обработки данных Sun Java JDK версий 1.6.0_05-b13 и 1.6.0_13-b03.

Apache Hadoop — это открытая среда для проведения процессороемких распределенных вычислений. Ее использование позволяет приложениям получать доступ к массивам неструктурированной информации петабайтного объема. Проект начал развиваться в качестве открытой альтернативы Google File System (GFS) и проприетарной реализации алгоритма MapReduce.

Hadoop — это единственный открытый алгоритм, когда-либо побеждавший в соревновании GraySort. Прошлогодний результат сортировки 1 терабайта данных, показанный также Hadoop на соревновании Terasort, равнялся 209 секундам.

  1. Главная ссылка к новости (http://news.cnet.com/8301-1384...)
  2. OpenNews: Поисковая технология Microsoft Kumo использует компоненты Apache Lucene
  3. OpenNews: Cloudera готова изменить мнение о сложности развертывания Apache Hadoop
  4. OpenNews: LiveCD на базе OpenSolaris со встроенной Hadoop инфраструктурой
  5. OpenNews: Intel, HP и Yahoo займутся крупномасштабными распределенными вычислениями
  6. OpenNews: Yahoo способствует созданию открытых средств для распределенных вычислений
Автор новости: blkdog
Тип: К сведению
Короткая ссылка: https://opennet.ru/21767-apache
Ключевые слова: apache, cluster, mapreduce
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, iZEN (ok), 23:01, 16/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "А сейчас мы послушаем начальника транспортного цеха..." ©
    (Переписать Apache Hadoop на C++ и посмотреть. Я думаю, это нереально будет сделать в обозримый кусок времени. ;)
     
  • 1.5, Аноним (-), 23:49, 16/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кто там говорил про тормоза Java? User239? Ну ну.
     
     
  • 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.
    "

    Вобще то тут не сказано что сама сортировка- производилась приложением написанном на джаве... Поэтому критичные к скорости компоненты- вполне могли быть написаны на самом что ни наесть.. вплоть до ассемблера... Сообщение таким образом говорит как раз о суммарной производительности кластера а не о достоинствах жабы...

     
     
  • 5.36, ximaera (?), 13:33, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бы хоть в SVN им заглянули, прежде чем тут чушь писать.

    ximaera@loderunner:~$ svn ls http://svn.apache.org/repos/asf/hadoop/core/trunk/src/mapred
    mapred-default.xml
    org/
    ximaera@loderunner:~$

    Вопрос на засыпку -- как, уже глядя на это, определить, что код будет на Java?

     
  • 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 делать сортировку пузырем это идиотизм..

     
  • 6.39, ximaera (?), 13:57, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну предположим что сортировка проводилась методом пузыря... Как этот алгоритм реализован на
    >"Name Node and Job Tracker" ?

    Зачем предполагать, когда можно проверить? Реализован он так: "static class TotalOrderPartitioner implements Partitioner<Text,Text>", далее здесь: http://svn.apache.org/viewvc/hadoop/core/trunk/src/examples/org/apache/hadoop

    Вы школу в каком году заканчиваете?

     
  • 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

     

  • 1.10, funky_dennis (?), 07:18, 17/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило...
     
     
  • 2.11, crypto5 (?), 08:57, 17/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >с 4ядерным ксеоном и с 16гб оперативы чоб оно тормозило...

    ну так и обьемы данных не маленькие..

     

  • 1.13, Deniel (?), 10:48, 17/05/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На С++ таки оно было бы существенно быстрее :)
     
     
  • 2.15, Jet (??), 10:53, 17/05/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >На С++ таки оно было бы существенно быстрее :)

    Возможно оно и так было на С... Hadoop написанный на жабе - не производит никаких вычислений и никаких сортировок...это нечто иное
    http://www.ibm.com/developerworks/ru/library/l-hadoop/index.html

     
     
  • 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.17, Knuckles (ok), 13:19, 17/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Религия C++ еще заразнее, чем я думал.
     
  • 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.45, Volodymyr Lisivka (?), 16:19, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Кто там говорил, что микроядро всё время будет проигрывать монолитному ядру в
    >>эффективности? Торвальдс(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.
    Чел ищет сипласпласника... :-)

     
  • 6.48, Аноним (-), 19:16, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Скорости от этого не прибавится - статическая оптимизация _сейчас_
    >проигрывает динамической.

    User294 считает по другому! Не было разрывов, не было!!!

     
  • 3.46, Marinov (?), 16:28, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Only in your dreams JAVA could be faster than C++ :)
     
     
  • 4.47, Volodymyr Lisivka (?), 17:38, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Only in your dreams JAVA could be faster than C++ :)

    http://www.mail-archive.com/hadoop-user@lucene.apache.org/msg02139.html

    MapReduce in C++ vs MapReduce in Java

    ... Java version was about 4 times quicker. ...

     

  • 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 написаны с и... текст свёрнут, показать
     
  • 8.55, crypto5 (?), 20:45, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Так а я и не говорю что джава круче Вы просто утверждал... текст свёрнут, показать
     
  • 6.52, Аноним (-), 20:12, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    МОЖЕТ Да может же А потому что JIT оптимизирует код под конкретный процессор... большой текст свёрнут, показать
     
     
  • 7.56, crypto5 (?), 20:46, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/

    >JIT может автоматически распараллеливать циклы на многопроцессорных машинах.

    А пруфлинк можно?


     
     
  • 8.58, User294 (??), 21:25, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    К пущей досаде жабистов могу припомнить что пруфлинк про gcc и как раз вот такую... текст свёрнут, показать
     
  • 7.57, User294 (??), 21:22, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А проверки характерные для managed кода куда денутся Испарятся Зато си-компилят... большой текст свёрнут, показать
     
     
  • 8.60, Аноним (-), 22:49, 18/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    На численных алгоритмах все обычно без managed проверок идет их еще компилятор ... большой текст свёрнут, показать
     
  • 8.62, Volodymyr Lisivka (?), 03:57, 19/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я запустил этот QuickLZ У меня на 2GHz Celeron 550 оно показывает скорость с... текст свёрнут, показать
     
     
  • 9.63, Volodymyr Lisivka (?), 03:59, 19/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    s и я не даю и я даю ... текст свёрнут, показать
     
  • 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 - зрелая и развитая технология То... текст свёрнут, показать
     
     
  • 10.65, Интегратор Императора (?), 12:29, 19/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Под виртуальную машину сотню мегабайт на каждом компьютере - и всё Остальное та... текст свёрнут, показать
     
     
  • 11.66, аноним (?), 14:20, 19/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    вынесем за скобки сомнительный пассаж про неподдатливых программеров платформа ... текст свёрнут, показать
     
     
  • 12.67, Аноним (-), 14:38, 19/05/2009 [^] [^^] [^^^] [ответить]  
  • +/
    И это правильно 50 грамм кремния должны стоить дешевле двух кило мозга ... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру