смысл очень простой: asm.js вырос из emscripten, который фактически компилирует LLVM биткод в JS. Биткод работает с указателями и сырой памятью, но в JS указателей нет, поэтому память эмулируется типизированными массивами, которые все указывают на один и тот же ArrayBuffer, а указатели эмулируют целочисленной переменной. При этом поддерживается только правильно выравненные указатели, т.е. int16 должен быть выравнен на 2 байта, а int32 — на 4 байта и так далее.

Теперь если представить что i — это правильно выравненный указатель на double, то как прочитать double по «адресу» i? Надо взять Float64Array представление кучи и прочитать из него элемент с индексом (i / 8) (double занимаем 8 байт).

Отсюда и требование на сдвиг — это деление на размер элемента в преположении что остальное это «адрес», потому что emscripten всегда такой код рожает. В рукописном коде выглядит, конечно же, сюрреалистично

у меня вообще разницы нет (asm.js на самом деле чуть медленнее) в FF Nightly, какая у вас версия FF?

Интересно, конечно, почему так, ну что же, коварная консоль)

Про консоль я выясню у Мозиловцев.

Точно pure. Замеряно на FF Nightly и Chrome Dev Channel на Mac Book. Но замер запущен не из консоли, а из самого JS скрипта.

Число переданное в функцию: 10000000

Кстати походу FF замедляет нормальные функции (гонит их только на интерпретаторе?) если их выполнять прямо из консоли.

Я выполнял из контекста страницы (добавил в конец JS файла)

  function measure(name, f) {
    console.log(name + " start")
    var start = Date.now();
    var result = f(10000000);
    var end = Date.now();
    console.log(JSON.stringify(result));
    console.log(name + " took " + (end - start) + " ms.");
  }

measure("pi (pure JS)", pi);

Ваш код на FF Nightly не проходит asm.js-верификацию c сообщениями типа

[12:43:56.056] TypeError: asm.js type error: non-expression-statement call must be coerced @ pi.js:91

(надо писать +floor, +pow везде)

А теперь внимание, сюрприз, производительность при этом у него не страдает. Как следствие, если взять и аккуратно переписать этот код на простой человеческий JavaScript получим ту же самую производительность и читаемый код

[13:02:08.076] Error: successfully compiled asm.js code (total compilation time 0ms) @ pi.js
[13:02:08.084] "pi (asm.js) start"
[13:02:30.776] "{"hex":"7AF5863EFF","fraction":1.4803089050105553}"
[13:02:30.776] "pi (asm.js) took 22692 ms."
[13:02:30.786] "pi (pure JS) start"
[13:02:51.523] "{"hex":"7AF5863EFF","fraction":1.4803089050105553}"
[13:02:51.523] "pi (pure JS) took 20736 ms."

Как из всего этого следует вывод? Без надобности тут вам asm.js.

Это, впрочем, и из кода видно — нет там ничего такого, что вменяемый JIT не осилил бы оптимизировать самостоятельно, без назойливых ручных |0 и +foo

Странно называть функцию clone, когда она на самом деле не клонирует:

var a = { ref: HUGE_OBJECT };
var b = clone(a);
b.ref = null; 
a = null;
// а HUGE_OBJECT-то утёк

Ну и в бенчмарке у вас замер «new constructor» замеряет совсем не то, что вы думаете — совсем даже не скорость создания объекта, а скорость присвоения свойства prototype (FF, Chrome страдают от этого, Safari — нет)

Здесь нет ничего про насильственную замену.

Если люди увидят достоинства Dart над JavaScript и большей частью пересядут на него, то в чем проблема? В амбициозности? «Через тернии к звездам» Надо стремится к светлому будущему, иначе оно никогда не настанет.

Как я уже говорил выше, я не считаю, что JavaScript может взять и исчезнуть по щелчку пальцами. Все решают массы и время. Демократия в чистом виде.

Я против насильственной замены JS на Dart.

А где вы видите насильственную замену JS на Dart и «уничтожение JS»? Это такой мем, который возник на пустом месте.

Заменить JS полностью на Dart можно было бы только, если бы двое из ларца (одинаковы с лица) выскочили и за ночь переписали весь интернет и все браузеры :-)

Dart предлагает платформу, кто хочет пользуется. Кто не хочет — не пользуется.

показывая, что у Дарта нет никаких объективных преимуществ на JS

Вы показываете отталкиваясь от весьма субъективных критериев.

Для кого-то возможность получить исключение, а не undefined (или значение с Array.prototype!) при выходе за границы массива это уже преимущество. Точно так же, кому-то не интересно наворачивать снова и снова весь boilerplate связанный с prototype для того, чтобы выразить распространенную концепцию «вот объект он несет данные, а вот методы, которые с ним работают». Кому-то хочется сказать, что параметр x ожидается типа Foo и хочется выразить это знание прямо в коде, а не запихивать в jsdoc-комментарий.

Для меня, например, «аккуратная» и простая семантика, богатая стандартная библиотека (в которой многое унифицировано и причесано, например, парадигмы stream и future используются везде от клиентского dart:html до серверного dart:io), легко предсказуемая высокая производительность (достигаемая за счет гораздо более простой, и как следствие более стабильной и расширяемой VM), либеральная опциональная типизация — это все достоинства Dart.

Есть, конечно, и недостатки. Например, на мой взгляд Dart одновременно и недостаточно динамический (mirror builders должны улучшить ситуацию, но когда они будут специфицированы, не говоря уж о реализации не ясно) и не достаточно статический (и еще я бы предпочел поддержку non-nullable типов).

Языки программирования вещь очень субъективная, и меня всегда коробит, когда люди начинают обобщать их личные предпочтения и стиль разработки на большое число программистов. Я вот не обобщаю.

Положа руку на сердце, это вовсе не смертельные недостатки для языка программирования

Стоит отказаться от классовой парадигмы — и работа с JavaScript становится лёгкой и приятной.

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

И он не производит впечатления простоты и понятности.

Может быть я читаю что-то неправильно, но это все совершенно явно ваша личная позиция, которую вы пытаетесь перенести на очень большой класс программистов.

Глупо было бы отрицать, что на свете много программистов, которые разделяют вашу точку зрения. Им нравится JavaScript со всеми его достоинствами и недостатками, и они не видят причины заменять его в повседневной работе чем-то другим.

Не менее странно, однако, утверждать, что все программисты должны довольствоваться JavaScript, а не стремиться к тем средствам разработки, которые удобны для них (а если они стремятся, то это «узкий кругозор» виноват!).

Справедливости ради стоит заметить, что там написано, почему Дарт не нужен вам. Вы довольны его семантикой, средствами разработки, доступными из коробки библиотеками и производительностью. Не совсем понятно как из этого проистекает ненужность Дарт кому-либо другому, кто не столь доволен JavaScript.

было бы интересно посмотреть на ваши бенчмарки

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

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

тест этот совсем не замеряет скорости округления, потому что loop invariant code motion выносит инвариант цикла за цикл.

замеряется по сути дела скорость кручения пустого цикла.

почитайте: mrale.ph/blog/2012/12/15/microbenchmarks-fairy-tale.html

лично для меня преимущество Dart в том, что это структурированный язык программирования, в котором есть привычные для большинства людей примитивы модульности, а семантика непозволяет прочитать undefined из-за пределов массива, а затем радостно помножить его с другим undefined прочитанным из несуществующего свойства или там сложить со строчкой «123».

к этому нормальному языку прилагается из коробки из коробки достаточно богатая библиотека которая покрывает и клиент и сервер, а еще есть пакеты реализующие вещи из будущего типа web components.

и при этом все это работает в любом современном браузере.

У V8 на самом деле есть ряд проблем с кодом, который emscripten выдает, многие из них правда asm.jsом не решаются, надо просто инфраструктуру чинить (например, проблемы при огромном количестве локальных переменных), некоторые решаются, но уж лучше их починить в общем случае (например, недостаточная хорошая протяжка информации о типах в пределах одного метода).

asm.js впрочем позволяет выделывать трюки, которые над обычным JS не так-то просто совершать: например, на x64 выкинуть все array bounds check и вместо это использовать перехват segfault для обнаружения доступа за границы кучи-типизированного массива.

LLVM IR оно на самом деле IR и есть, т.е. промежуточное представление.

Есть очень хорошее письмо на эту тему от одного из разработчиков LLVM: lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

У него есть проблемы с переносимостью, оно слишком низкоуровневое и быстренько сгенерировать из него хороший код не так-то просто.

Тут правда стоит заметить две вещи:

a) Emscripten генерирует JavaScript / asm.js как раз из LLVM IR (т.е. фактически asm.js это высокоуровневый переносимый формат для LLVM IR :-)),

b) Mozilla не сообщает накиках чисел о том, как быстро asm.js валидируется и компилируется (есть основания полагать, что там не все так радужно, David Herman даже писал, что они рассматривают вариант с кэшированием сгенерированного нативного кода).

Да предсказуемость, это, конечно, один из козырей asm.js и она действительно тот самый 1% бъет в яблочко на некоторых задачах. Правда бъёт она не в стиле «а мы тут немного затюним», а в стиле «а сейчас надо вычислительное ядро переписать на С++». Как по мне, так уж лучше бы мы эти 99% медленно превратили в 99.9%, а потом в 99.99% и так далее, чем сразу такая капитуляция.

Кстати, давно вас онлайн хотел поймать, была пара нубских вопросов по особенностям v8:)

А меня просто поймать, можно написать в личку или на почту me@mrale.ph (или рабочую) :-)