aura
aura личный блог
19 ноября 2015, 03:45

Самый шустрый язык программирования

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

Победила реализация Фортрана от Intel. Приблизиться к ней не смог вообще никто, даже GNU C и GNU C++ (и что еще более удивительно, чистый Си немножко проиграл «плюсам»). 
На четвертом месте язык Applied Type System, про который я к стыду своему слышу в первый раз. Представляет он систему автоматического доказательства теорем, расширенную средствами прикладного программирования. Почему так шустр, даже не знаю, но активно применяется для системного программирования. 

Пятое место давно шлифуемой Ada немудрено, а вот 6-7-е места Java — отличный аргумент против унылого мнения «java тормозит». 

Даже Pascal и C# Mono сильно от Java отстают, в полтора-два раза! В отношении Паскаля это совсем странно. Причина, видимо, в активно развивающихся промышленных технологиях оптимизации кода, ориентированных на поддержку в первую очередь виртуальных машин. 

Довольно быстро работают функциональные Lisp и F#, относительно несильно отстает и JavaScript. А вот классические скрипт-языки Lua, Ruby, Python и PHP тормозят уже в 30-50 раз. 

Резюме. 
Если пишем под линуху нагрузочную математическую прогу — однозначно Фортран. 
Если обычная логика — Си/С++. 
Специализированные и встраиваемые системы — ADA. 
Низкоуровневый системный код — ATS. 
Корпоративные системы — Java. 
Что-то легковесное-скриптовое — JavaScript. 
(Ассе́мблера почемута нет в списках — №1 по производительности)
Материал с сайта: http://www.pcweek.ru/idea/blog/idea/2329.php
29 Комментариев
  • Борис Гудылин
    19 ноября 2015, 04:43
    Мои «тяжелые» алгоритмы (арифметика) при переходе с LUA (QUIK, режим интерпретации) на С++ (DLL) ускорились в 30 раз. Ассемблер на моих формулах уже не помог бы. Выжимать уже нечего.
  • vito2000
    19 ноября 2015, 06:30
    Кроче, С/С++ по скорости хватит везде и за глаза.  А Python Секрета — вообще тормоз :)
  • Антон Денисков (Fry)
    19 ноября 2015, 06:49
    Ассемблера нет в списках, потому что это по сути тесты компиляторов на этапе перевода ЯВУ в ассемблер =). То есть тест отвечает на вопрос: насколько хорошие конструкции кода на ассемблере может строить компилятор из своего ЯВУ.

    Паскаль/дельфи/сбилдер проигрывает закономерно. Кто видел в дебагире или дизассемблере код из борландовского компилятора (а он у них один на все языки по сути), тот знает какой это тихий ужас с точки зрения оптимизации.

    Ява обходит, потому что мой друг приложил руку =))). Он лично писал всю оптимизацию под 64-битные AMD и Intel, а до этого работал над x86 для компилятора Оракал (его код реюзали по полной).

    В целом это всё очень бредовые тесты… И вообще, причём тут трейдинг? =)
  • Антон Денисков (Fry)
    19 ноября 2015, 07:33
    Андрей Аурис, для HFT-бота, который эксплуатирует фактор скорости критическими местами является:
    1) маршрут (нужно убрать всё лишнее)
    2) работа со строковыми типами данных
    3) проверки ошибок (придётся пожертвовать гибкостью и устойчивостью кода в пользу скорости)

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

    В HFT обычно на уровне кода нет никаких таких циклических математических рассчётов, главные задержки которые реально убрать программисту — это избавиться всяких конекторов-адаптеров-трансляторов-проверок.
    Например, важнее всего избавиться от библиотеки-посредника, которая безумно тупо проверяет строковые значения и очень-очень дебильно парсит их в float'ы и int'ы, когда на самом деле надо получить родные для x64 даблы и лонги.
    А затем максимально быстро обратно сгенерировать строку из даблов без всяких проверок, но с кучей оговорок (с фиксированной точностью и не полным диапазоном допускаемых входных значений).

Активные форумы
Что сейчас обсуждают

Старый дизайн
Старый
дизайн