Dart VM и мушкетеры

[thedeemon]

Занялся тут изучением вариантов по переносу своего кодека в браузер. На Flash'e у меня уже был декодер, но это нынче не модно. Решил посмотреть разные другие способы, сравнив сперва их скорость на небольшой части кодека, наиболее времязанимающей, - декодировании ключевого кадра в RGB24. Там много массивов, циклов и простой целочисленной арифметики. Стали появляться первые результаты, порой довольно неожиданные. Dart VM, которую позиционируют как более продвинутую и быструю, оказалась втрое медленнее джаваскрипта (в Хроме), сгенеренного из того же самого дартовского исходника штатной утилитой dart2js. JS в Хроме лишь немного медленее чем Flash, и оба в пределах 2x от нативного кода на С++.

Время декодирования одной конкретной картинки 960х540:
На ноуте с Core i3:
Native C++ (старинный интеловский компилятор): 34 ms
Flash (compiled from Haxe): 58 ms
Dart на DartVM: 172 ms
JS, сгенеренный из Dart, в Chrome 37: 62 ms
Тот же JS в IE 11: 95 ms

На простеньком андроидном планшете:
Тот же JS в Chrome 34: 379 ms
Он же в дефолтном браузере там: 971 ms

На стареньком андроидном телефоне:
JS в дефолтном браузере: не взлетел
JS в Firefox: 976 ms
Flash: 472 ms

Тесты можно погонять тут:
JS (generated from Dart)
Flash (compiled from Haxe)
Dart (работает лишь в Dartium)

О размерах:
Flash распространяется скопилированным в байткод, .swf файл: 6 KБ
Dart, распространяется в исходнике: 9 КБ
Сгенеренный из него JS: 135 КБ при включенной минификации, более 300 КБ без оной.
Т.е. хвалебные рассказы про деревотрясение и оптимизацию... для небольших программ неактуальны, dart2js пихает туда довольно толстый рантайм. А еще каждое обращение к элементу массива в сгенеренном коде сопровождается ручной проверкой на выход за пределы с вызовом какой-то дартоспецифичной функции в случае ошибки. Я не знаю, насколько хорошо JS движки это оптимизируют, выглядит как куча ненужной работы.

Буду продолжать наблюдения. В планах еще как минимум генерация JS из Haxe и генерация ASM.js из С++. Писать на самом JS вы меня не заставите. :)

Comments

[mr-aleph.livejournal.com]

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

Мы пытаемся их садить на машинное слово, чаще всего получается, но иногда нет - по историческим причинам, поэтому на границах Uint32/Int32 наблюдаются вот такие артефакты производительности.

Попробуй x64 build там все будет быстро :)

$ ~/src/v8/v8/out/ia32.release/d8 ~/src/dart/dart/sdk/lib/_internal/compiler/js_lib/preambles/d8.js out.js
loading image...
received 149321 bytes.
decompressing 50 times...
t=2571 ms
$ ~/src/dart/dart/out/ReleaseIA32/dart spi.dart 
loading image...
received 149321 bytes.
decompressing 50 times...
t=5918 ms
$ ~/src/v8/v8/out/x64.release/d8 ~/src/dart/dart/sdk/lib/_internal/compiler/js_lib/preambles/d8.js out.js
$ ~/src/dart/dart/out/ReleaseX64/dart spi.dart
loading image...
received 149321 bytes.
decompressing 50 times...
t=1893 ms

Я сделал баг на это дело http://dartbug.com/21557 - хотя вообщем-то это давно известная проблема, надо просто до нее добраться.

[thedeemon.livejournal.com]

O, спасибо!
Я брал комплект darteditor-windows-x64.zip. Там 32-битный дартиум? 64-битный вообще существует?

Кстати, какова официальная политика партии насчет расхождения семантики больших интов между Dart VM и dart2js?

[mr-aleph.livejournal.com]

Dartium там действительно 32-битный, Хром только относительно недавно[1] начали для Win/Mac делать 64-битным. Я поговорю с людьми, может нам надо переключить сборку SDK на 64битный Dartium.

dart/dart-sdk/bin/dart.exe в том же SDK однако 64-битный.

> Кстати, какова официальная политика партии насчет расхождения семантики больших интов между Dart VM и dart2js?

Официальная политика партии соостоит в том, что это на данном этапе развития JS невозможно эффективно реализовать при трансляции в JS. Вот. Т.е. мы об этом знаем, нам хотелось бы это реализовать, но вот не получается. Спека написана таким образом, что размер int в ней не указывается и поэтому dart2js cтрого говоря соответствует спеке.

Вот такая, печальная на мой взгляд, история.

[1] http://blog.chromium.org/2014/08/64-bits-of-awesome-64-bit-windows_26.html

[thedeemon.livejournal.com]

Кстати, в вариантах на С++ и Haxe у меня все делается на 32-битных интах и uint'ах, т.е. самой задаче больше 32 бит не нужно. Надо будет проверить, нет ли в варианте на Дарте мест, где он может решить, что нужны более длинные значения..

[mr-aleph.livejournal.com]

да это понятно :) ну вот допустим 0xFFFFFFFF выглядит для Си-шника как int32/uint32 - а для Dart с его интами это int33 :)

Если вдаваться в подробности, у нас пирамида внутренних представлений выглядит так smi -> mint -> bigint.

Smi = Machine Word Size - 1 bit (int31 on 32-bit, int63 on 64-bit)

Mint = boxed int64

Bigint = понятное дело "бесконечный".

Поэтому когда кто-то делает значение типа 0xFFFFFFFF в 32-bit Dart VM его таращит в Mint и информация о его пределах теряется. Вот отсюда и все проблемы.

Нужно как я в ишуе писал делать нормальный range profiling на бинарных операциях - тогда получится хороший код генерировать.

[thedeemon.livejournal.com]

O! А ежели 0x3FFFFFFF, то в smi влезет же? Возможно, этого мне хватит, завтра посмотрю..

[mr-aleph.livejournal.com]

если все числа в маске 3FFFFFFF то влезет