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

[wizzard]

хотел спросить про js из haxe, но увидел планы и перестал)

еще кстати есть https://github.com/PeyTy/LuaXe

[sorhed.livejournal.com]

Дарт же ужасен, зачем его брать?

[thedeemon.livejournal.com]

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

[sorhed.livejournal.com]

Ну то есть «а почему не emscripten»?

[thedeemon.livejournal.com]

Он в планах. Насколько юзабелен - будем посмотреть.

[sober-space.livejournal.com]

Пытался його устанавливать...

[justy-tylor.livejournal.com]

FIrefox 33 показал JS 74ms и Flash 54ms. Интересно будет сравнить с Haxe и Emscripten. :)

[permea-kra.livejournal.com]

>На ноуте с Core i3:

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

[thedeemon.livejournal.com]

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

Такая линейность зато дает хорошее сжатие - на этой картинке можно наблюдать 10-кратное сжатие без потерь, какой-нибудь PNG так не может даже если очень долго будет стараться.

[loislo.livejournal.com]

а если сорцы и мапы выложить, а то втыкать в минифайеные файлы грустно

[wizzard]

Так есть же сорцы)

http://data.infognition.com/spbench/spi.dart
http://data.infognition.com/spbench/rangecoder.dart

[thedeemon.livejournal.com]

http://stuff.thedeemon.com/lj/spi_unminified.zip

[avnik.livejournal.com]

Коллега, а что вы думаете про всякие генерящие js хаскелеобразные?
(haste, fay)

[thedeemon.livejournal.com]

Полагаю, если стоит задача получить быстрый код, то к ним обращаться бессмысленно. А так - наверное, ярым любителям хаскеля они могут скрасить день (особенно если не нужно с JS библиотеками взаимодействовать). С этими двумя я дело не имел, а вот Elm'ом побаловался, в одном месте на сайте компании он даже используется. Интересная штука, но недостаточно general purpose: навязывает свой хитрый event loop с распространением событий по графу, и оттого зависит от немаленького и не слишком шустрого рантайма. Такой интерпретатор внутри интерпретатора.

[nponeccop.livejournal.com]

an optimized but uncompressed Haste program is normally less than 3x the size of an equivalent hand-written program

[thedeemon.livejournal.com]

А что там со скоростью?
Ссылка "API docs" ведет на список названий модулей на хакадже. Это все доки, или я что-то не понял?

[nponeccop.livejournal.com]

я впервые это увидел сегодня, так что хез

[nealar.livejournal.com]

Язык фей умеет в ЖС-библиотеки, но
1) ещё не вполне взрослый
2) nponeccop смотрел, шо оно генерит, говорит, страшненько. Не думаю, что полученный код может быть быстрым хоть в каких-то условиях.

[nponeccop.livejournal.com]

Я говорил, что он там редукцию графов делает, и не хьюман ридабл. А оверхед мерять надо.

[mr-aleph.livejournal.com]

баг же надо было сделать на эту тему!

до работы дойду - посмотрю, почему на VM так медленно.

[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 то влезет

[theiced.livejournal.com]

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

[triampurum.livejournal.com]

Интересно будет узнать о впечатлениях о js из haxe, да.