Движок V8 и браузер Google Chrome станут лучше поддерживать Asm.js

[nick4fake]

Есть надежда, что это повлияет на safari/opera+webkit?

p.s. Мицгол, я каждую вашу заметку как повесть читаю. Красиво написано.

[Zelgadis]

Очевидно же в Opera это будет.

[Mithgol]

Как только Opera перейдёт на V8. (Планы такого перехода оглашены.)

[Mithgol]

Очевидно, что давление на Apple (как на производителей Safari) и на Microsoft (как на производителей IE) усилится, им придётся либо что-то делать, либо мириться с тормозами результатов выполнения транскомпилированных программ и библиотек в своих браузерах. Так что надежда есть.

В отношении Opera место надежды занимает уверенность (Opera в феврале начала переходить на V8). Нет только ясности: Бог его знает, когда они окончательно перейдут на V8 и выпустят Opera 14.

[Akuma]

А почему Opera 14? Тринадцатой же еще нет, вроде бы

[Mithgol]

И не будет, потому что символизм.

[Alexey2005]

На десктопах производительность браузеров и так достаточна. А вот на мобильных устройствах всё куда печальнее: мало где можно заставить Canvas выдавать больше 3 FPS, а уж про WebGL можно даже не заикаться, столь мизерная у него производительность. И, боюсь, asm.js здесь не поможет, т.к. тормозит сама отрисовка.
Плюс на HTML5 до сих пор нельзя сделать кроссбраузерные эмуляторы старых приставок, т.к. всё ещё нет нормального API для синтеза звука (пока что тут WebKit впереди всех, остальные сильно отстали).

[jetman]

Понимаю, что речь в вашем посте идет о мобильных браузерах, но как обстоят дела с производительностью у Firefox OS? Там по идее порт настольной версии Firefox и все должно работать быстро.

[leotsarev]

По ощущением, немного тормозней, чем Firefox fo Android, но это отношу на то, что на андроиде у меня 1 гиг, а на Firefox OS — 512.
Если вас интересуют конкретные тесты, пришлите ссылки, я в субботу прогоню их на Geeksphone Peak

[jetman]

Отправил вам в пятницу ссылки — пишу здесь, вдруг не заметили.

[leotsarev]

Простите, не сделал :-(
У меня отмечено в почте, доберусь — сделаю.

[jetman]

Напоминаю. Geeksphone Peak только у вас у одного в России!

[TheShock]

А вот на мобильных устройствах всё куда печальнее: мало где можно заставить Canvas выдавать больше 3 FPS

Ну тут вы перегибаете. Начиная с iOS5 и Android4 можно делать вполне играбельные приложения.

[KvanTTT]

Ага, и с записью звука там тоже все печально.

[leotsarev]

Если вы про Web Audio API, оно вскоре появится в Firefox wiki.mozilla.org/WebAudio_API_Rollout_Status

[Mithgol]

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

[leotsarev]

Я бы не стал давать таких обещаний за разработчиков. :-)

[Mithgol]

Тем не менее именно такой срок соблюдался ими довольно неуклонно, почти два года кряду — с лета 2011 года.

[leotsarev]

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

[Mithgol]

А, вот Вы о чём.

[bolk]

Достаточно, говорите? Посмотрите быстро ли работает у вас PDF.js. У меня на больших документах — со скрипом.

[Damaskus]

В частности, при помощи операции «|0» и других подобных специальных приёмов тип значения каждого входного параметра функции, равно как и выходного значения, оказывается однозначно заданным и неизменным.

Одна из основных фишек js — нетипизированные параметры, и я так понял такие функции не поддадутся оптимизации в принципе.
Не получится так, что расплатой за скорость будет потеря удобства и робастности кода?
Т.е. код будет менее универсальным, но более быстрым, а надо ли?

[SleepingLion]

Asm.js — это дополнительная возможность оптимизации, которую можно (а можно и не) использовать. Если не нравится, можно использовать классический VanillaJS с прежней скоростью.

[leotsarev]

asm.js не предназначен для ручной оптимизации кода.
Он предназначен для компиляции в JavaScript с других языков (например C) при помощи Emscripten.

Впрочем, даже сейчас Javascript JIT активно угадывает тип используемых переменных. Возьмем функцию

function increase(number)
{
  return number + 1; // Медленное сложение, т.к. тип аргумента неизвестен.
}
var num = 0;
for (var i =0; i < 1000000; i++)
{
  num =  increase (num); // Это горячая функция, по статистике аргумент всегда int
}

JIT-компилятор превратит функцию increase примерно в такой псевдокод

function increase(number)
{
  if (number is not integer)
  {
    Singal type inference error // Возврат в медленный режим (самый простой вариант — просто убрать эту оптимизацию)
  } 
  return number + 1; // Быстрое целочисленное сложение
}

Идея asm.js в том, чтобы раскидывать подсказки для JIT-компилятора.

function increase(number)
{
  number = number | 0; // Битовый OR точно вернет integer, а в процессе оптимизации эту инструкцию можно выкинуть.
  return number + 1; // Быстрое целочисленное сложение
}

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

[Damaskus]

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

А по поводу приведенного вами примера с детерминированными функциями, тут я полностью согласен, их оптимизировать — одно удовольствие :-) Только, я вот не знаю как у вас, в моих проектах таких минимум.
И говоря о том что, мы будем работать лишь в 2 раза медленней с++, я б добавил, что на сервере — возможно да, тут я всеми руками за, а на клиенте с тяжелой веб мордой, извините — вряд ли.

Если только найдутся особо ретивые бойцы которые начнут руками молотить код, чтоб он подходил под оптимизацию.
Но это вряд ли кому будет нужно, если только письками скоростью мериться. Проще заказчику объяснить что 1Гб оперативы мало и все.

[Maccimo]

Фрагмент кода, защищённый инструкцией instanceof по сути мало чем отличается от фрагмента кода, защищённого инструкцией |0.
И в том, и в ином случае тип доподлинно известен. Учитывает ли это конкретный движок JS — другой вопрос.

[ashtuchkin]

Там дальше разъясняют, что не добавили поддержку, а просто увеличили производительность на бенчмарке asm.js.

Кстати, как альтернативное мнение о asm.js (с которым я согласен) можно почитать замечательную статью от одного из разработчиков V8:
mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html

[Mairon]

Вячеслав есть здесь на Хабре, поэтому можно попробовать призвать его в тред :)
mraleph

[Mithgol]

Прелюбопытно видеть, что mraleph во Твиттере щебечет: оказывается, рост производительности V8 при выполнении кода asm.js является не результатом поддержки директивы "use asm" и не последствием внедрения AOT (которого не было и в помине!…), а просто итогом нескольких оптимизаций общего характера, внесённых в движок V8 и оказывающих влияние на весь JavaScript в целом.

Похоже на то, что я напрасно и чрезмерно был увлечён энтузиазмом Резига, господа читатели.

[Mithgol]

Впрочем, рано вешать нос; дождёмся публикации результатов каких-нибудь новейших испытаний скорости выполнения тестов Asm.js. А не то вдруг там и впрямь заметный рост производительности V8, хотя и без AOT.

[mraleph]

на наборе микробенчмарков V8 стал в среднем в 2-3 раза быстрее, на каких-то показывая скорость эквивалентную той, что дает Mozilla-вский AOT. однако еще много работы впереди. если вы напишите asm.js, который на V8 почему-то работает медленно — обязательно засылайте его в code.google.com/p/v8/issues/entry

[leotsarev]

вообще это два разных бага.
code.google.com/p/v8/issues/detail?id=2599 — добавить поддержку asm.js
code.google.com/p/v8/issues/detail?id=2424 — тот, про который вы говорите.

[mraleph]

2424 это лишь один из многих. 2223, 2513, 2618, 2678, и т.д. Многие уже починены, но почему-то не закрыты: skinning например сейчас в пределах 5% от показателей OdinMonkey и >3x быстрее чем голый Ion Monkey, при этом V8 не полагается на «use asm» чтобы достичь таких результатов.

[goodbear]

Меня вот давно интересует, зачем все упираются в javascript с такими костылями, хотя можно было бы все организовать по принципу .net, стандартизировать байткод (его подмножества для такого случая) и библиотеки, и позволить пользоваться любым языком. Ведь javascript для многих не самый желанный язык.

[SleepingLion]

Учитывая современные тенденции по созданию трансляторов из чего угодно в JS, в скором времени JS и станет таким стандартизированным «байткодом».
И будут холивары в стиле «да что ты пишешь на этом тормозном %Lang_name%, написал бы нормально, на JS++» ).

[nail84]

код жс — это текст, байткод — бинарный

[Triang3l]

Ну почему же.

Текст — это тоже байты.

Да и информация, интерпретируемая как машинные числа, может быть одновременно и текстовой.

Например, представим, что в байткоде есть инструкция AddL и 10 регистров, адресующихся в формате rXrX. Тогда вполне нормальный кусок текста AddLr0r1 является struct {long instruction; char leftSource; char leftOffset; char rightSource; char rightOffset;}, где из leftOffset и rightOffset вычитается 48.

[kemsky]

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

— и меня уже притомляют маркетинговые названия…

[Bagobor]

Логичный шаг дальше — написать на asm.js интерпретатор байт кода и постепенно реализовавывать нативную поддержку этого байткода в браузерных движках.

[Bagobor]

Видимо в силу того что он есть в каждом браузере. А браузер есть почти на каждом телефоне\планшете\ноутбуке\компьюторе.

[Mithgol]

компьюторе

компьюторе

компьюторе

[nail84]

А почему «во браузере», но при этом «в движке»?

[TheShock]

Обычная безграмотность, не обращайте внимания.

[Mithgol]

Ошибаетесь.

Есть правило, в соответствии с которым я действую.

Нет правил, нарушаемых этими словосочетаниями.

[Mithgol]

Здесь эта форма предлога является стилистическим приёмом для придания торжественности тексту. (Подробности см., например, вон там: Розенталь Д. Э., Джанджакова Е. В., Кабанова Н. П., «Справочник по правописанию, произношению, литературному редактированию», глава XLV, §199, пункт 9, подпункт 4.)

Употреблять этот приём я могу, разумеется, не только неуклонно, но и выборочно, по своему вкусу.

Приём же этот служит как один из способов, необходимых для создания впечатления «красиво написано» — подобного тому, которое nick4fake испытал и выразил выше.

[nail84]

Лично у меня от такой стилистики складывается впечатление, что вы описываете технологии которым уже минимум лет 100) Ну и как определить можно ли употребить сей торжественный предлог со следующим словом или нет. Например «во дни сомнений» звучит еще более менее, а вот «во пасти безумия», к примеру, совсем слух режет. Я так понимаю четкого правила на этот счет нет?

[Mithgol]

«Во» выглядит не особенно приемлемо, когда следующее слово начинается единственным согласным перед нередуцированным гласным звуком. (Обобщение закона Гавлика на предлоги.)

[nail84]

Интересно, спасибо.