Comments 49
Есть надежда, что это повлияет на safari/opera+webkit?
p.s. Мицгол, я каждую вашу заметку как повесть читаю. Красиво написано.
p.s. Мицгол, я каждую вашу заметку как повесть читаю. Красиво написано.
+11
Очевидно же в Opera это будет.
+4
Очевидно, что давление на Apple (как на производителей Safari) и на Microsoft (как на производителей IE) усилится, им придётся либо что-то делать, либо мириться с тормозами результатов выполнения транскомпилированных программ и библиотек в своих браузерах. Так что надежда есть.
В отношении Opera место надежды занимает уверенность (Opera в феврале начала переходить на V8). Нет только ясности: Бог его знает, когда они окончательно перейдут на V8 и выпустят Opera 14.
В отношении Opera место надежды занимает уверенность (Opera в феврале начала переходить на V8). Нет только ясности: Бог его знает, когда они окончательно перейдут на V8 и выпустят Opera 14.
+2
На десктопах производительность браузеров и так достаточна. А вот на мобильных устройствах всё куда печальнее: мало где можно заставить Canvas выдавать больше 3 FPS, а уж про WebGL можно даже не заикаться, столь мизерная у него производительность. И, боюсь, asm.js здесь не поможет, т.к. тормозит сама отрисовка.
Плюс на HTML5 до сих пор нельзя сделать кроссбраузерные эмуляторы старых приставок, т.к. всё ещё нет нормального API для синтеза звука (пока что тут WebKit впереди всех, остальные сильно отстали).
Плюс на HTML5 до сих пор нельзя сделать кроссбраузерные эмуляторы старых приставок, т.к. всё ещё нет нормального API для синтеза звука (пока что тут WebKit впереди всех, остальные сильно отстали).
+2
Понимаю, что речь в вашем посте идет о мобильных браузерах, но как обстоят дела с производительностью у Firefox OS? Там по идее порт настольной версии Firefox и все должно работать быстро.
+1
А вот на мобильных устройствах всё куда печальнее: мало где можно заставить Canvas выдавать больше 3 FPS
Ну тут вы перегибаете. Начиная с iOS5 и Android4 можно делать вполне играбельные приложения.
+1
Ага, и с записью звука там тоже все печально.
0
Если вы про Web Audio API, оно вскоре появится в Firefox wiki.mozilla.org/WebAudio_API_Rollout_Status
+2
И можно даже дополнительно сообщить, что здесь «вскоре» означает «не более чем через три месяца», потому что именно такой срок отделяет Aurora-версию от официального выпуска.
+1
Достаточно, говорите? Посмотрите быстро ли работает у вас PDF.js. У меня на больших документах — со скрипом.
+3
В частности, при помощи операции «|0» и других подобных специальных приёмов тип значения каждого входного параметра функции, равно как и выходного значения, оказывается однозначно заданным и неизменным.
Одна из основных фишек js — нетипизированные параметры, и я так понял такие функции не поддадутся оптимизации в принципе.
Не получится так, что расплатой за скорость будет потеря удобства и робастности кода?
Т.е. код будет менее универсальным, но более быстрым, а надо ли?
0
Asm.js — это дополнительная возможность оптимизации, которую можно (а можно и не) использовать. Если не нравится, можно использовать классический VanillaJS с прежней скоростью.
+4
asm.js не предназначен для ручной оптимизации кода.
Он предназначен для компиляции в JavaScript с других языков (например C) при помощи Emscripten.
Впрочем, даже сейчас Javascript JIT активно угадывает тип используемых переменных. Возьмем функцию
JIT-компилятор превратит функцию increase примерно в такой псевдокод
Идея asm.js в том, чтобы раскидывать подсказки для JIT-компилятора.
Если внутри файла в нужных местах сгенерированы подсказки, то компилятор может проверить, что все будет ок, в момент разбора файла, и ему не надо будет раскидывать по сгенерированному коду инструкции типа «если тип не угадал, перекомпилим-ка функцию заново».
Он предназначен для компиляции в 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; // Быстрое целочисленное сложение
}
Если внутри файла в нужных местах сгенерированы подсказки, то компилятор может проверить, что все будет ок, в момент разбора файла, и ему не надо будет раскидывать по сгенерированному коду инструкции типа «если тип не угадал, перекомпилим-ка функцию заново».
+3
Я понимаю, что не для ручной.
Я имею ввиду немного другое.
В моих веб проектах часто встречаются параметры функций априори имеющие несколько возможных типов.
Взять к примеру, тот же самый Ext Js, где ширина может быть инициирована числом или строкой.
В конструкторе параметр проверяется с помощью instanceof либо typeof и на этом выстраивается дальнейшая логика работы.
А по поводу приведенного вами примера с детерминированными функциями, тут я полностью согласен, их оптимизировать — одно удовольствие :-) Только, я вот не знаю как у вас, в моих проектах таких минимум.
И говоря о том что, мы будем работать лишь в 2 раза медленней с++, я б добавил, что на сервере — возможно да, тут я всеми руками за, а на клиенте с тяжелой веб мордой, извините — вряд ли.
Если только найдутся особо ретивые бойцы которые начнут руками молотить код, чтоб он подходил под оптимизацию.
Но это вряд ли кому будет нужно, если толькописьками скоростью мериться. Проще заказчику объяснить что 1Гб оперативы мало и все.
Я имею ввиду немного другое.
В моих веб проектах часто встречаются параметры функций априори имеющие несколько возможных типов.
Взять к примеру, тот же самый Ext Js, где ширина может быть инициирована числом или строкой.
В конструкторе параметр проверяется с помощью instanceof либо typeof и на этом выстраивается дальнейшая логика работы.
А по поводу приведенного вами примера с детерминированными функциями, тут я полностью согласен, их оптимизировать — одно удовольствие :-) Только, я вот не знаю как у вас, в моих проектах таких минимум.
И говоря о том что, мы будем работать лишь в 2 раза медленней с++, я б добавил, что на сервере — возможно да, тут я всеми руками за, а на клиенте с тяжелой веб мордой, извините — вряд ли.
Если только найдутся особо ретивые бойцы которые начнут руками молотить код, чтоб он подходил под оптимизацию.
Но это вряд ли кому будет нужно, если только
0
Там дальше разъясняют, что не добавили поддержку, а просто увеличили производительность на бенчмарке asm.js.
Кстати, как альтернативное мнение о asm.js (с которым я согласен) можно почитать замечательную статью от одного из разработчиков V8:
mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
Кстати, как альтернативное мнение о asm.js (с которым я согласен) можно почитать замечательную статью от одного из разработчиков V8:
mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
0
Прелюбопытно видеть, что mraleph во Твиттере щебечет: оказывается, рост производительности V8 при выполнении кода asm.js является не результатом поддержки директивы "use asm" и не последствием внедрения AOT (которого не было и в помине!…), а просто итогом нескольких оптимизаций общего характера, внесённых в движок V8 и оказывающих влияние на весь JavaScript в целом.
Похоже на то, что я напрасно и чрезмерно был увлечён энтузиазмом Резига, господа читатели.
Похоже на то, что я напрасно и чрезмерно был увлечён энтузиазмом Резига, господа читатели.
+2
Впрочем, рано вешать нос; дождёмся публикации результатов каких-нибудь новейших испытаний скорости выполнения тестов Asm.js. А не то вдруг там и впрямь заметный рост производительности V8, хотя и без AOT.
0
на наборе микробенчмарков V8 стал в среднем в 2-3 раза быстрее, на каких-то показывая скорость эквивалентную той, что дает Mozilla-вский AOT. однако еще много работы впереди. если вы напишите asm.js, который на V8 почему-то работает медленно — обязательно засылайте его в code.google.com/p/v8/issues/entry
+1
вообще это два разных бага.
code.google.com/p/v8/issues/detail?id=2599 — добавить поддержку asm.js
code.google.com/p/v8/issues/detail?id=2424 — тот, про который вы говорите.
code.google.com/p/v8/issues/detail?id=2599 — добавить поддержку asm.js
code.google.com/p/v8/issues/detail?id=2424 — тот, про который вы говорите.
+1
Меня вот давно интересует, зачем все упираются в javascript с такими костылями, хотя можно было бы все организовать по принципу .net, стандартизировать байткод (его подмножества для такого случая) и библиотеки, и позволить пользоваться любым языком. Ведь javascript для многих не самый желанный язык.
+1
Учитывая современные тенденции по созданию трансляторов из чего угодно в JS, в скором времени JS и станет таким стандартизированным «байткодом».
И будут холивары в стиле «да что ты пишешь на этом тормозном %Lang_name%, написал бы нормально, на JS++» ).
И будут холивары в стиле «да что ты пишешь на этом тормозном %Lang_name%, написал бы нормально, на JS++» ).
+2
код жс — это текст, байткод — бинарный
-1
Ну почему же.
Текст — это тоже байты.
Да и информация, интерпретируемая как машинные числа, может быть одновременно и текстовой.
Например, представим, что в байткоде есть инструкция AddL и 10 регистров, адресующихся в формате rXrX. Тогда вполне нормальный кусок текста AddLr0r1 является struct {long instruction; char leftSource; char leftOffset; char rightSource; char rightOffset;}, где из leftOffset и rightOffset вычитается 48.
Текст — это тоже байты.
Да и информация, интерпретируемая как машинные числа, может быть одновременно и текстовой.
Например, представим, что в байткоде есть инструкция AddL и 10 регистров, адресующихся в формате rXrX. Тогда вполне нормальный кусок текста AddLr0r1 является struct {long instruction; char leftSource; char leftOffset; char rightSource; char rightOffset;}, где из leftOffset и rightOffset вычитается 48.
0
да это странный подход немного, видно из-за обратной совместимости js останется навсегда с нами.
asm.js больше похож на временный костыль, но хватит ли сил его убрать неизвестно.
— и меня уже притомляют маркетинговые названия…
asm.js больше похож на временный костыль, но хватит ли сил его убрать неизвестно.
— и меня уже притомляют маркетинговые названия…
0
Видимо в силу того что он есть в каждом браузере. А браузер есть почти на каждом телефоне\планшете\ноутбуке\компьюторе.
+1
А почему «во браузере», но при этом «в движке»?
+4
Обычная безграмотность, не обращайте внимания.
+5
Ошибаетесь.
Есть правило, в соответствии с которым я действую.
Нет правил, нарушаемых этими словосочетаниями.
Есть правило, в соответствии с которым я действую.
Нет правил, нарушаемых этими словосочетаниями.
-3
Здесь эта форма предлога является стилистическим приёмом для придания торжественности тексту. (Подробности см., например, вон там: Розенталь Д. Э., Джанджакова Е. В., Кабанова Н. П., «Справочник по правописанию, произношению, литературному редактированию», глава XLV, §199, пункт 9, подпункт 4.)
Употреблять этот приём я могу, разумеется, не только неуклонно, но и выборочно, по своему вкусу.
Приём же этот служит как один из способов, необходимых для создания впечатления «красивонаписано» — подобного тому, которое nick4fake испытал и выразил выше.
Употреблять этот приём я могу, разумеется, не только неуклонно, но и выборочно, по своему вкусу.
Приём же этот служит как один из способов, необходимых для создания впечатления «красиво
0
Лично у меня от такой стилистики складывается впечатление, что вы описываете технологии которым уже минимум лет 100) Ну и как определить можно ли употребить сей торжественный предлог со следующим словом или нет. Например «во дни сомнений» звучит еще более менее, а вот «во пасти безумия», к примеру, совсем слух режет. Я так понимаю четкого правила на этот счет нет?
0
«Во» выглядит не особенно приемлемо, когда следующее слово начинается единственным согласным перед нередуцированным гласным звуком. (Обобщение закона Гавлика на предлоги.)
0
UFO just landed and posted this here
Sign up to leave a comment.
Движок V8 и браузер Google Chrome станут лучше поддерживать Asm.js