Производительность скомпилированного кода Haxe

Как скомпилированный код Haxe сравнивается по производительности с различными целями?

Например, получается ли PHP из Haxe быстрее или медленнее, чем исходный PHP-код?

Как насчет Javascript? Вспышка? С++? И Т. Д.

Есть ли какой-то серьезный эталон?


performance haxe
person Pier    schedule 14.08.2013    source источник

Ответы (2)


arrow_upward
16
arrow_downward

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

  • Если поискать, можно найти несколько бенчмарков, сравнивающих OpenFL/NME с Flash. Одним из примеров является вот этот

  • Мне сказали, что CPP работает немного медленнее, чем обычный C++. Я предполагаю, что оптимизированный вручную C++ может стать немного быстрее. Пример теста от создателя HXCPP здесь

  • Что касается JS, я знаю, что Haxe придерживается относительно лучших практик для повышения производительности. Например, строго типизированный характер Haxe, как правило, приводит к лучшей производительности с JIT-компиляторами Javascript, поэтому код Haxe вполне сравним с хорошо написанным Javascript. (Обратите внимание, я говорю об обычном JS здесь, а не о графике canvas/openFL - очевидно, что для этого потребуются ваши собственные тесты).

  • Что касается PHP, я не уверен, как сгенерированный Haxe PHP сравнивается с PHP, написанным вручную. Что я могу вам сказать, так это то, что вы можете почти без проблем переключиться с PHP на Neko (оба легко работают на apache), и вы получите код намного быстрее, чем рукописный PHP. Ваши узкие места будут связаны с доступом к БД и т. д., а не с выполнением кода.

  • Что касается флэш-памяти, поищите вокруг, и вы, вероятно, найдете тесты. Haxe предоставляет вам некоторые функции времени компиляции, такие как дженерики, безопасность типов и встраивание функций, которые могут повысить производительность во время выполнения.

В целом

Самый большой прирост производительности с Haxe достигается не за счет сравнения его с написанным от руки кодом на том же языке, а за счет возможности без особых усилий переключиться на более быструю платформу. Пишите на PHP, переключайтесь на неко -> огромное ускорение. Пишите во Flash, переключайтесь на OpenFL (C++) -> огромное ускорение.

Надеюсь, кто-то еще может опубликовать несколько ссылок на более релевантные тесты :)

person Jason O'Neil    schedule 14.08.2013
comment
Хороший ответ. Тем не менее, я проверил и обнаружил, что Haxe обеспечивает более высокую производительность SWF по сравнению с таким же хорошо написанным кодом в AS3, в основном из-за оптимизации времени компиляции. Кодировщики PHP рассказали мне о некотором повышении скорости благодаря строгой типизации, но вы правы на 100% - узкое место редко связано с PHP, скорее это обработка БД. - person Creative Magic; 14.08.2013
comment
Спасибо за Ваш ответ. Если никто не предоставит более конкретных данных, я дам вам правильный ответ. Что вы имеете в виду, когда пишете на PHP, переключаетесь на неко? - person Pier; 14.08.2013
comment
@CreativeMagic интересен в плане оптимизации времени компиляции. Я подозревал, что да, но я не активный пользователь флэш-памяти. Все еще было бы интересно увидеть некоторые тесты, если вы знаете какие-либо... - person Jason O'Neil; 14.08.2013
comment
@Pier, не беспокойся, я тоже надеюсь увидеть конкретные данные. Я имел в виду, что PHP и Neko в Haxe имеют очень похожие API. Фреймворк, который я использую (ufront), компилируется в PHP и Neko, как и Haxe DB Records, веб-< href="http://haxe.org/manual/dispatch" rel="nofollow noreferrer">диспетчер и системный пакет. neko.Web и php.Web практически идентичны. Если вам не нужны существующие библиотеки или функции PHP, развертывание в Neko почти всегда будет быстрее, и вы можете поменять их в любое время. - person Jason O'Neil; 14.08.2013
comment
@JasonO'Neil, ну, это не так уж загадочно, поскольку Flash Player паршиво справляется с оптимизацией чего-либо на реальном уровне компиляции. Например: сделать переменную myVerySuperLongVariableName = 1; и я = 1; Запустите цикл для изменения данных переменных, и вы увидите, что я работаю быстрее. Обычные компиляторы изменили бы все переменные на a, b, c и т. д. в пределах области видимости, но Flash этого не сделал (сейчас не уверен). Я сделаю несколько SWF-файлов, чтобы сравнить некоторые важные вещи и опубликовать их на своей веб-странице позже. опубликую ссылку. - person Creative Magic; 14.08.2013
comment
@CreativeMagic На самом деле это совсем не так. Во-первых, во flash (AVM2) сравнение строк выполняется за O (1), поэтому не имеет значения, как долго имя вашей переменной. Во-вторых, внутри переменных функции вообще нет имени, им присваивается целочисленный индекс (ваш файл swf/swc не содержит имен переменных). Однако компилятор Adobe flash может все испортить на совершенно другом уровне. И, наконец, оптимизация haxe работает и на другом уровне. Компилятор Haxe не делает много работы по реальной оптимизации, кроме встраивания, выгода от правильной типизации, ничего больше. - person stroncium; 04.04.2014
comment
Эй, @JasonO'Neil, я только что пересмотрел этот ответ и обнаружил, что оба они легко работают на apache. Вы знаете, как легко установить mod_neko на Apache? Потому что, куда бы я ни посмотрел, это не кажется простым. - person Pier; 16.04.2014
comment
Привет @Pier, ты прав, я забыл, что инструкции по установке не совсем понятны. При компиляции neko компилирует файл mod_neko2.ndll, но вам нужно самостоятельно добавить конфиг apache. Мне помогли эти две страницы: haxe.org/doc/build/mod_neko и haxe.org/doc/build/mod_neko/jan_cheatsheet ... Если у вас все еще есть проблемы спросите в списке рассылки Haxe, и я постараюсь написать для вас более четкие инструкции. Удачи! После настройки apache довольно просто переключиться с использования Haxe/PHP на Haxe/Neko. - person Jason O'Neil; 19.04.2014

arrow_upward
2
arrow_downward

Вы можете посмотреть на эту статью. Он сравнивает компиляторы Haxe. PHP кажется самым медленным среди 5 целевых компиляторов. https://hal.inria.fr/hal-01356849/document

person staticx    schedule 21.05.2017
comment
Не стесняйтесь спрашивать подробности. Я автор этой статьи ☺️ - person staticx; 22.05.2017