Самый быстрый язык программирования: Scala, Java или может быть Python?

Понадобилось мне написать программку, пересчитывающую массив географических координат из одной системы в другую. Написал на Ruby в несколько строчек. Время выполнения — 16,5 сек. Чего так долго? Решил написать то же самое, но на разных языках, чтобы заценить производительность современных языков программирования. Результаты оказались неожиданными.

Выбор языка программирования

Ruby. Простой, удобный и... очень медленный. Вообще-то, это мой любимый язык программирования. Нравится лаконичностью и универсальностью. Хочешь web-приложение — ставь Ruby on Rails и ваяй. Нужен скрипт для системного администрирования — Ruby тоже очень хорош. Но в Руби всё настолько модное, динамическое и объектно-ориентированное, что язык, прямо скажем, очень нетороплив. И это справедливая плата за удобство. 16,5 сек.

JRuby. Обалденный проект! Берет скрип на Ruby и компилирует в байт-код Java. А VM от Явы славится своей отполированностью и производительностью. Плюс огромный бонус — возможность прозрачно вызывать из Ruby код на Java из миллиона первосортных библиотек и наоборот. Но не будем отвлекаться. Взял я свою программу и натравил на нее компилятор JRuby. Время расчетов сократилось в 2 раза и составило 8,6 секунды. Получаем ускорение в 2 раза с нулевыми затратами.

Go. Моднейший и распиаренный язык от Google. Программа компилируется в бинарный код. Разработчики обещают высочайшую производительность. Проверяем. 3,7 сек. Отлично! Но ведь Си всё равно будет быстрее?!

Си. В отличии от Go, тут нет сборщика мусора и раздутого рантайма. Только хардкор! Берем gcc, компилируем, запускаем и получаем первый сюрприз — 4 секунды. Что за дела? Можно предположить, что у Go лучше оптимизация. Тогда попробуем и из gcc выжать максимум. Используем опции -O3 и -march=native (тест на i7). Получаем 3,7. Ровно столько же, сколько выдает Go.

Java. JRuby опробовали и получили 8,6. А что получится, если весь код сразу написать на Java? Тут нас ждет вторая неожиданность — 3,1 сек. Быстрее, чем Go и Си. Как это объяснить я не знаю. Возможно, кто-нибудь в комментариях расскажет, как код в виртуальной машине может выполняться быстрее нативного кода? У меня есть всего одна гипотеза и даже мне она кажется сомнительной: а вдруг виртуальная машина настолько умная, что оптимизирует код во время выполнения и распараллеливает часть задач? В любом случае, Java — это сила!

Scala. Модный ЯП, претендующий на роль убивца Java. Тоже компилируется в бинарный код для виртуальной машины Java. Синтаксис Scala намного более приятный и — что самое главное — намного более лаконичный. А что со скоростью? Наверное, примерно как у JRuby? И тут третий сюрприз — 3,1 сек., то есть как и у Java. Но если не округлять, что у Java 3.104 сек, а у Scala 3,091. Ну вообще!

JavaScript. На примере NodeJS 4-й ветки. Получилось 3,5 сек. Go и C посрамлены. Как интерпретируемая программа может оказаться быстрее нативного кода? Возможно, всё дело в чудо-движке V8 от Google, который не устают нахваливать за скорость. Кстати, это именно он установлен во всех браузерах Chrome и Chromium.

PHP. Вот мы и добрались до самого яркого представителя быдланской пэхапэплеяды. Использовалась версия PHP 5.6, хотя уже есть PHP 7, которая, как заявляют некоторые, примерно в 2 раза быстрее. Но 7 еще мало распространена, а тогда как версия 5.6 вездесуща. В режиме CLI программа отработала за 16,5 сек. Ровно столько же, сколько и на чистом Ruby. Мы получили мощное доказательство того, что не случайно специалисты объединили эти три прекрасные языка — PHP, Python, Ruby — в быдланскую плеяду. Кстати, о Python...

Python. Для теста я использовал Python третьей ветки (3.5). Запускаем, ждем, ждем, ждем... и через 51,412 сек. программа заканчивает расчеты. В быдланской плеяде новый «чемпион». Конечно, я сразу же решил, что где-то пропустил важный нюанс оптимизации. Пришлось погрузиться в изучение этого языка и прочитать не один трактат по оптимизации. Затем я переписал программу, хотя переписывать было почти нечего: включается таймер, далее идет цикл с вычислениями по жестко заданной формуле, таймер выключается и печатаются результаты. 3 часа чтения документации и еще час на оптимизацию кода дали поистине потрясающий результат: время работы сократилось с 51.412 до 50,336 сек.

Perl. Зачем нужен этот старый пердун среди молодых и сильных атлетов? А затем, что время от времени встречаю утверждение, что Perl — это как PHP, только в 100 раз круче и быстрее, поэтому многие крутые проекты пишут на Перле. Может и вправду быстрее? Запускаем и... 18 секунд. На помойку.

Какой язык программирования выбрать?

Любой, который больше нравится. За исключением Python, конечно. Но если требуется выполнить узкую задачу — большое количество арифметических вычислений — и требуется скорость, то Java и Scala очень хороши. Кстати, теперь я понял, почему Hadoop написан на Java, а Spark на Scala.

Сводная таблица

Название Время выполнения (меньше — лучше)
Scala 3,1
Java 3,1
JavaScript 3,5
Go 3,7
C 3,7
JRuby 8,6
Ruby 16,5
PHP 16,5
Perl 18,0
Python 50,3

Методика

Тестовые программы состояли из 3 частей:

  1. Загрузка данных из файла CSV.
  2. Вычисления.
  3. Вывод результатов.

Таймер включался только перед выполнением второй части и выключался перед третьей частью. Считать время импорта данных из CSV не было смысла, так как для этого использовались достаточно объемные библиотеки, которые для каждого языка разные. Таймер включался только для блока вычислений, который во всех языках был одним и тем же. В конце работы программы печаталось два числа: контрольная сумма и время исполнения в миллисекундах. Принудительная оптимизация включалась только для gcc, в остальных случаях использовались параметры компиляции по умолчанию.

Краткость — сестра таланта

В качестве бонуса. Самый большой объем был у программы на Java. Самый малый — у Perl. Почти столько же у JavaScript.

Ваша оценка: Нет Средняя оценка: 4.5 (10 votes)

очень неграмотная статья.
тобишь таймер включался только перед вычислениями? минуя подгрузку таблиц и интерпретацию (которая поставит любой интерпретируемый язык на последние места по сравнению с компилируемыми)?
очень "умно". а ещё более "умно" делать из этого заголовок: "Самый быстрый язык программирования".

по такой логике можно составить список "самых медленных языков программирования", основываясь на том, какой из них позже всех выведет — "Hello world!".

а то что Java и Scala (при всём уважении) показали такие быстрые результаты по сравнению с тем же Go или Си — наводит на мысль что были допущены ошибки не только в замерах скорости.

по идеи должно делаться так:
-получаем время
-запускаем программу
-вычитаем из текущего времение полученное

Ваша оценка: Нет Средняя оценка: 2.3 (12 votes)
pomodor

Глупость. Сравнивать надо реализации одного и того же алгоритма. Если замерять время работы всей программы (то есть, сравнивать кислое с горячим), то мы узнаем только то, разработчики какой библиотеки импорта из CSV пишут более качественный код.

Ваша оценка: Нет Средняя оценка: 4.2 (9 votes)

тест проведён неграмотно.

так а кто вам сказал что тесты производятся совместно со сторонними библиотеками?

обычно делается алгоритм, например вычисление множества квадратных уравнений, перебор массива, чтение из файла с помощью средств языка и его стандартных библиотек.

1. замеряется время.
2. запускается ВСЯ программа, а не её КУСОК.
3. после завершения программы — отнимаем текущее время от замеренного.

и на основании этого делается вывод о скорости программы.
а при создании аналогичных алгоритмов для других языков (опять же средствами языков и его библиотек) можно сделать вывод о СКОРОСТИ ЯЗЫКА для решения данной проблемы.

какие ошибки допустили вы?
1. использовали (я предполагаю) сторонние библиотеки, которые могут быть написаны криво.
2. замерили ТОЛЬКО КУСОК кода, вместо ВСЕЙ программы, забыв и про интерпретацию и при индивидуальную особенность каждого языка. один делает что-то быстрее, другой делает тоже самое медленней.
3. на основании ошибок в методологии — сделали вывод о скорости языков ВООБЩЕ.

>одного и того же алгоритма.

вы приведите тогда пример этого самого "одно алгоритма" хотя бы для "победителей" и "проигравших", чтобы оценить насколько он чист от влияния сторонних библиотек и криворукости создателя.

как я сказал выше, что мешает по вашей странной логике, замерить время ДО 'Hello world" и ПОСЛЕ — и на основании этого сделать вывод о скорости языков? это же проще. пусть неправильно, но для вас — прокатит.

Ваша оценка: Нет Средняя оценка: 3 (10 votes)
pomodor

использовали (я предполагаю) сторонние библиотеки, которые могут быть написаны криво

Уважаемый эксперд, вы хоть статью читали и то, что вам отвечают? Какие кривые библиотеки? Замерялся только блок арифметических вычислений. Алгоритм везде один и тот же. Внешнего кода нет.

Ваша оценка: Нет Средняя оценка: 3.5 (8 votes)

вы можете бодаться дальше, но факт "на лицо" — тест некорректен...
особенно для того что-бы делать из него такие громкие выводы.

не верите мне? ну наберите в интернете "тестирование языков на скорость", там будет описано: как это делают адекватные люди, какие способы используют, какие алгоритмы и результаты, которые (что не удивительно) абсолютно противоречат вашим.

Ваша оценка: Нет Средняя оценка: 1.7 (10 votes)
pomodor

Страшное дело, когда гуманитарий берется рассуждать по техническим вопросам. Ну а попытка спрятаться за Гугл — отличительный признак №1 такого "спеца". :)

тест некорректен

Тест офигительный. Статья еще лучше. Если отдельные пионеры чем-то недовольны, то это проблемы самих пионеров. Читайте правильные статьи, от своих одноклассников. Что я еще могу сказать? ;))

Ваша оценка: Нет Средняя оценка: 4.3 (11 votes)

страшное дело, когда гуманитарий пытается рассуждать по техническим вопросам, поставленным гуманитарием и даже не пытается пользоваться гуглом...
тест некорректен.

Ваша оценка: Нет

кто-нибудь в комментариях расскажет, как код в виртуальной машине может выполняться быстрее нативного кода

Адаптивная оптимизация HotSpot. "HotSpot часто называют самой производительной виртуальной машиной Java в своем классе. В теории с помощью адаптивной оптимизации программа, которая выполняется в этой JVM может быть более производительной, чем эквивалентная ей программа в машинных кодах".

Автору спасибо за качественный обзор!

Ваша оценка: Нет Средняя оценка: 3.5 (6 votes)

Scala мальчикам, Python девочкам.

Ваша оценка: Нет Средняя оценка: 4 (4 votes)

А если попробывать JPython и PyPy?

Ваша оценка: Нет Средняя оценка: 5 (4 votes)

Я бы тогда до кучи заценил-бы ещё и IronPython на нативном .NET и Mono (не уверен, правда, что он будет нормально работать на последнем Mono)

Ваша оценка: Нет Средняя оценка: 4.7 (3 votes)

Во первых — тексты программ в студию. Для объективности, надо-бы посмотреть как расчёты в разных ЯП организованы.

Но вообще, мой опыт показывает, что в общем случае, задачи, будучи правильно реализованными, покажут примерно одинаковую производительность во всех языках и средах выполнения. Примерно одинаковую — это + — 50% по времени выполнения. При этом надо понимать, что области применения у разных языков различные, и, очевидно, какие-то конкретные штуки те или иные языки и среды будут выполнять совершенно по разному.

JavaScript. ... Как интерпретируемая программа может оказаться быстрее нативного кода? ...

JIT это вам совсем не интерпретация. Загуглите педивикию. Вообще, JIT в v8 — давно уже вплотную приблизился по скорости к нативному C,C++. Прямую ссылку не дам, но пару лет назад на конференции разрабов Unity3D — достаточно подробно тему проивзодительности JS в современных браузерах обсасывали. Меня тогда очень поразило, что связка C#->LLVM->ASM.JS уже тогда могла работать быстрее чем нативный C#->IL->JIT из MONO 2.10 в unity3d. Если интересует инфа более релевантная для вашего случая, то она прекрасно гуглится по запросу "javascript v8 vs c++ performance".

Ваша оценка: Нет Средняя оценка: 3.3 (6 votes)
Sunrise

Мне Ruby ещё нравится за то его способность работать с большими числами. Создал недавно алгоритм, выводящий числа Фибоначчи в файл (в столбик) и оставил его работать на некоторое время. Вычислил до 186036-ой позиции (можно было и больше, но я прервал выполнение). 186036-е число в ряду Фибоначчи состоит из 38880 знаков.
Я хочу узнать, какой ещё язык программирования даёт такие возможности.
PS Интересно, что C оказался одним из самых быстрых, Ruby -- медленнее, а Python -- медленнее всех.

Ваша оценка: Нет Средняя оценка: 4.3 (3 votes)
pomodor

Я хочу узнать, какой ещё язык программирования даёт такие возможности.

Практически любой. Фича вводится дополнительной библиотекой. Например, в C# есть структура BigInteger, позволяющая хранить числа любой длины (в пределах доступного объема ОЗУ, разумеется) и выполнять ограниченный набор арифметических операций над ними.

Ваша оценка: Нет Средняя оценка: 5 (3 votes)
Sunrise

Спасибо, не знал!

Ваша оценка: Нет Средняя оценка: 5 (2 votes)
pomodor

Но Ruby действительно рулит! :)

Ваша оценка: Нет Средняя оценка: 3.7 (3 votes)

Практически любой. Фича вводится дополнительной библиотекой. Например, в C# есть структура BigInteger, позволяющая хранить числа любой длины (в пределах доступного объема ОЗУ, разумеется) и выполнять ограниченный набор арифметических операций над ними.

можно это реализовать на любом ООП-языке, особенно поддерживающем перегрузку операторов(можно на питоне, c++, паскале, даже на javascript-e)

Ваша оценка: Нет

все эти ruby, python, java, c# это дикий бред. Может вам, программистам и легко писать на этом дерьме. Но мне как человеку которому приходится поддерживать и ремонтировать это говно никак не удобно. Си и С++ самое то. бинарник и работает. Go не совсем бинарник там компилируется с LLVM. Но там хотя бы ставить разное дерьмо не нужно. Java — это никакая не сила, это убожество за что я в своё время ненавидел sun, но они хотя бы искупили вину запилив zfs и множество других ништяков. Так вот, для того чтобы запустить прогу нужно поставить дофига разного говна в виде .net/mono, JVM и прочего это бред. Концепция JIT/JVM/.net это дикий бред. Я понимаю, это подавалось как кроссплатформенность, да только вот даже одна прога порой не работает с разными версиями JVM. Не сталкивались с тем, что обновив JVM проги переставали работать? а как быть с тем что одна прога требует более свежую версию джавы, а другая более старую? Приходится плясать с бубном ставя разные версии этого отстоя на одну систему. Когда-нибудь пробовали? Нет? Советую, очень увлекательно. так что эти ваши замеры админам мало интересны когда сишную прогу можно сразу запустить, а для джавы и .net нужно плясать с бубном. И да, я знаю про JIT обёртку в исполняемом файле в джаве и .net. Это такой костыль примотанный скотчем, что даже смешно. Компании используют джаву и С#? ну так купились на маркетологов. Помню я в 2004м году были объявления на приём на работу типа "требуется программист на С# опыт не менее 5ти лет". Кто не вкурсе, С# вышел в 2004м. Преимуществ я не вижу, только проблемы одни. И всякие Jruby, scala и прочий шлак это вообще кому оно надо? Лучше изучайте D чтоли.

Ваша оценка: Нет Средняя оценка: 3.7 (3 votes)
pomodor

По-моему, всё ровно наоборот. Скрипт на Ruby будет работать где угодно. Если скрипт старый, то можно использовать RVM. А вот что делать с бинарником C/C++, который, например, динамически слинкован со старыми библиотеками? Только выкинуть.

Ваша оценка: Нет Средняя оценка: 5 (4 votes)

простите, не знаю таких проблем. Если бинарник С/С++ динамически залинкован со старой библиотекой, то обновляется библиотека. На этом и стоится обновление функционала многих самописных программ в разных компаниях. Конечно, если программист чудак на букву м, то можно поиметь ошибку в виде "точка входа в динамическую библиотеку не найдена" итд. Но такое случается гораздо реже, чем морока с той же джавой. А многие вообще тупо статистически линкуют прогу с библиотеками. Обновлять по частям нельзя, зато и проблем с запуском никаких.

Ваша оценка: Нет Средняя оценка: 2 (3 votes)
pomodor

Если бинарник С/С++ динамически залинкован со старой библиотекой, то обновляется библиотека.

Как это она обновляется? Например, старый бинарник требует старую версию glibc. Я могу ее собрать самостоятельно, но для этого мне придется выкачать кучу старых зависимостей и поставить библиотеку в обход системного менеджера пакетов, а то потребуется и на пакетном уровне поставить кучу старья. И совсем прекрасно, если старая библиотека не совместима с новой версией GCC. По-моему, сопровождение старых бинарников C/C++ — то еще удовольствие.

А многие вообще тупо статистически линкуют прогу с библиотеками.

Для старья это единственный разумный выход. Раньше так, например, распространяли бинарники браузера Opera для Linux. Так до сих пор запускается. ;)

Ваша оценка: Нет Средняя оценка: 4.6 (5 votes)

Не сталкивались с тем, что обновив JVM проги переставали работать? а как быть с тем что одна прога требует более свежую версию джавы, а другая более старую? Приходится плясать с бубном ставя разные версии этого отстоя на одну систему.

а зачем ставить еще одну версию, когда можно просто поставлять jvm вместе с софтом, а перед запуском передать в определенных переменных окружения путь к нужному бинарнику java? Я много раз так создавал пакеты под виндой для старого софта, который нуждался в определенной версии jre, например 1.3. Да и некоторые програмы сами так и делают, конечно минус — размер вырастает сразу на 50 Mег.

Ваша оценка: Нет Средняя оценка: 2 (1 vote)

А не поставляют. Я и видел-то прогу с зашитым jvm в экезшник всего один раз. Проблема тут не в размере, проблема тут в "легендарной" совместимости ради которой и был придуман этот дичайший костыль под названием Java Virtual Machine. Ненавижу. Дома я вообще никогда не ставлю того что требует jvm. А на работе выбирать не приходится. Хотя вынужден признать, что нынче программ написанных на джаве мне ставить приходится куда меньше чем прежде. Помню как в 2003м заказчику ставили оракл и оракл формы. О эти чудные мгновенья, именно тогда я проклял джаву и оракл. Заняло неделю чтоб найти jre версию на которой эти формы запустятся... И то не на сайте sun.com, той версии не было уже. Когда я таки запустил формы, у нас были вопли как у роскосмоса при успешном запуске ракеты. А сейчас джава принадлежит ораклу, так что ненавидеть удобно, всё в одном флаконе, не надо распаляться. Но секса с джавой с тех пор не убавилось если программист не потрудился jvm зашить в экзешник. Программисты, скажите, зачем вы пишете программы на джаве? неужели такой охрененный язык ради которого нужно терпеть все эти костыли? Или потому что работодатель хочет, ибо их идиоты повелись на маркетологов джавы?

Ваша оценка: Нет Средняя оценка: 5 (1 vote)

ну что значит не поставляют:) Самому сделать. Моя работа например была создание или изменение инсталяционных файлов с целью их совместимости с новой версией винды. Я руководствовался в свое время приблизительно таким советом (ответ с 256 плюсами), а инсталляшник собирал специальным софтом. Но в некоторых фирмах просто брали или AutoIt для exe (или другой бесплатный софт), или Wix для msi. Кстати версию используемой java и вообще много чего, можно узнать если вскрыть exeшник — это не обязательно всегда настоящий скомпиленный бинарник, иногда это просто сборище файлов. Или даже в логах exe можно ошибку увидеть. Странно что вы так не делали, хотя уверен что в то время(2003) было все труднее

Ваша оценка: Нет

джава имеет один плюс — когда пишешь под мобильные устройства где есть куча процессоров, создаешь 1 версию программы, которая будет работать везде(например под Андроид). А на C++ (при стандартном способе) пришлось бы распространять кучу версий скомпиленных под разные типы процессоров умноженную на количество операционных систем.

хотя c++ под дотнет тоже есть

Ваша оценка: Нет

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

Ваша оценка: Нет Средняя оценка: 2 (8 votes)
pomodor

Да мне как бы хватает интеллекта записать одну формулу на разных языках. Если конкретно тебе не хватает, то советую не на форумах штаны просиживать и в разговоры умных людей встревать, а заняться своим интеллектуальным развитием. А то поздно будет. ;)

Ваша оценка: Нет Средняя оценка: 4 (5 votes)

Писака ты, а не умный людь. :D Сильно сомневаюсь, что ты хоть по одному языку прочитал руководство полностью. А они знаешь ли довольно большие. Конкретно код в студию! На всех языках. Вот потом умничать будешь.

Ваша оценка: Нет Средняя оценка: 1.8 (5 votes)
pomodor

Зачем школоте код? Ты писать грамотно не научился, какой уж тут может быть анализ программного кода? ;)

Ваша оценка: Нет Средняя оценка: 3.4 (5 votes)

Когда нечего сказать, начинаем поучать как правильно писать. :D Прием старый, и не тобой придуманный. Что до анализа программного кода, то я все же что-то, в отличии от тебя, на самом деле изучал. Впрочем, это неважно. Важно чтобы ты всем остальным показал, что ты там напрограммировал. :D

Ваша оценка: Нет Средняя оценка: 2 (4 votes)
pomodor

Нет, просто грамотность — это показатель интеллекта. Если человек русский язык не осилил, то языки программирования и подавно не для его IQ. Перестань прогуливать уроки, поднажми на орфографию и когда-нибудь я соизволю с тобой пообщаться на тему программирования. А пока тебе отведена роль хомячка, подыскивающего IP всяких помоек для обучения фильтра говнокаментов. И не более того, не надо себе льстить. ;)

Ваша оценка: Нет Средняя оценка: 4.2 (5 votes)

ИМХО
Всерьёз читать сей опус не рекомендую.

PS: почитал комменты, автор нагл и агрессивен.

Ваша оценка: Нет Средняя оценка: 3 (2 votes)

какие 3,1 сек у джавы? у меня на компе она только запускается 11 секунд.
там используется файл rt.jar который если не изменяет память представляет собой зип-архив 30 мб. и при запуске он целиком читается с диска, распаковывается каждый файл из него.
все это жутко нерационально реализовано, отсюда и медленно.
и программы на джаве жрут огромное количество оперативки. Многие иде написанные на джаве жрут до хрена памяти и медленно работают даже на очень быстрых компьютерах. У меня на ноутбуке такие проги как pyCharm написанные на джаве запускаются по 2 минуты. не пользуюсь из-за этого.
Питон хоть меньше памяти жрет и быстрее запускается.
В питоне тоже стандартная реализация не совсем рациональная и плохо оптимизированная(по скорости выполнения кода).
В джаве код быстро работает но запускается долго и памяти расходует много.
В C/C++ надо учитывать что там к проге грузятся динамические рантайм-библиотеки размером несколько мегов. Тоже время занимает.

Ваша оценка: Нет

и IDE WebStorm которая на этом сайте рекламируется(написанная на джаве) у меня на компе запускается по 5 минут)))).
Хотя говорят удобная ИДЕ.

Ваша оценка: Нет

JavaScript как язык по динамичности примерно такой же как питон.
Из объектов можно динамически при работе программы удалять-вставлять свойства и методы,
динамическая типизация(можно менять тип переменной при выполнении программы).
Массив в JS может состоять из значений разных типов и можно работать как с динамическим списком(аналог и подходит для реализации типа список питона).

То есть видимо Питон не из-за каких-то своих особенностей медленней чем JS, а из-за того что просто не сделали быструю реализацию.
Потому что V8 для js разрабатывает гугл, а питон Python Software Foundation (некоммерческая организация).

Наверное надо попробовать сделать реализацию питона поверх V8.

Ваша оценка: Нет

Мде. Методика теста вызывает сомнения.

НЕЛЬЗЯ проверять "только арифметический блок"! Рантайм вполне может начать вычисления *ДО* того, как формально управление будет передано алгоритму. V8 может (и будет!) делать такие вот "предварительные оптимизации", которые в рамках данного теста оказываются "за бортом".

Кроме того верно, что один и тот же алгоритм можно имплементировать очень по-разному, в особенности на разных языках, и если автор лучше пишет на одном языке, чем на другом (что очень вероятно) — то будет смещение.

Да, это верно даже в отношении "всего одна формула". Я предлагаю вызов для уважаемого pomodor: я берусь улучшить Ваш "алгоритм" на javascript, python, C (этими языками я владею уверенно) или PHP (у вас очень плохой результат для PHP, уверен, что где-то ошибка) "вслепую", не зная как именно Вы его имплементировали так, что скорость выполнения или использование памяти уменьшится хотя бы на 5%.

Я уж не говорю про статические оптимизации в компилируемых языках.

Именно по этим причинам (а также по целой куче других) тестирование языков и компиляторов на скорость — это не та задача, которую можно решить "вотпрямщас быренько заценим".

Код в студию. Без тест-кейзов исследованию веры нет.

Ваша оценка: Нет

Я уж не говорю про такие прелести как сборщик мусора, который есть в каждом представленном языке, кроме C, и который, полагаю, ни разу не отработал из-за ограниченного объема данных и allocate only подхода. А если и отработал — то ПОСЛЕ ТОГО, КАК ТАЙМЕР ВЫКЛЮЧИЛИ, хе-хе.

Чем и объясняется "фантастическая скорость" Go, Java, JS и иже с ними: у них оставался отложенный кусок, который БУДЕТ создавать проблемы на реальном проекте, но который был "хитро пропущен" в тесте.

Не. Херовый тест.

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.