Вячеслав Егоров mraleph

Мне вот интересно, для чего бы вы его использовали? Руками такой код писать удовольствия мало.

Привязка данных в Dart вдохновлена MDV (Model Driven Views), который действительно не является частью вебкомпонентов. Однако, части необходимые для MDV постепенно проникают в платформу:

groups.google.com/d/msg/mdv-discuss/I6oiK8z0LdI/H3i4MlszsFcJ

Никакой произведенный evalом код не оптимизируется. Но new Function — не eval, поэтому произведенный им код оптимизируется.

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

превратится-ли result в словарь зависит от количества полей и некоторых других факторов.

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

ну и eval'а на V8 нужно избегать как огня — произведенный им код не оптимизируется. хотя в данном конкретном случае это и не важно, потому что основное время тратится в клонировании object literal boilerplate, которое выполняется большей частью в стабе.

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

Меня интересует язык и что делает его «облегченной версией явы».

Библиотека имеет некоторое сходство с Java, но также и имеет и сходство с JavaScript. К тому же она в активной переработке.

что, кроме пары ключевых слов общего с Java?

ну по сравнению с циклом for если зарядить на длинном массиве, много-много раз пустую функцию то будет видна цена вызова.

следует определить понятие быстро :-)

над каждым элементом функция честно вызывается. в зависимости от того, что функция делает цена этого вызова может быть заметна, а может быть амортизированна и не очень заметна.

как это только хром? постоянно гоняем тесты dart2js на FF, Safari, IE: build.chromium.org/p/client.dart/console

эта функция не заинлайнится из-за array literal даже если будет в глобальном scope: code.google.com/p/v8/issues/detail?id=1322

если vector существует в единственном числе, то тут разницы между глобальным и не глобальным scope не должно быть.

Хранение 32-битных величин сложный вопрос. На ia32 те из них которые не влезают в smi (31-bit signed integer) превратятся в полновесные числа с плавающей точкой. Зависит от многих факторов: как много тех кто не влезает в 31бит, как они будут использоваться и т.д. Int32Array может оказаться оптимальным в некоторых случаях.

только вот такой оптимизации V8 не делает пока :-)

мы, видимо, по разному определяем понятие удалить.

прежде всего delete не прописывает undefined, он удаляет свойство полностью оставляя вместо него дырку. разницу просто увидеть на примере кода:

a = [1];
b = [1];
Array.prototype[0] = 42;
console.log(a[0] + " " + b[0]);  // 1 1
delete a[0];
b[0] = undefined;
console.log(a[0] + " " + b[0]);  // 42 undefined

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

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

Все зависит от конкретной задачи, на самом деле. Каждый код очень индивидуален.

> Вы давно видели 32х битные Маки?

Chrome на Mac по сей день 32-битный

omega ~ ∳ file /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome 
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O executable i386

64-битная сборка только на Linux используется AFAIK

> Но у вас в блоге заметил странную магию с «use strict», который не дает захватывать контекст.

В данном конкретном примере "use strict" разрывает связь между arguments и формальными параметрами. Это убирает создание контекста и позволяет инлайнить этот код (если функция создает контекст, то такую пока V8 не инлайнит).

Strict mode описан в стандарте: es5.github.com/#C

> как можно заставить заинланиться некоторые мои функции (например математические).

Если вы набросаете примеры кода, то можно будет обсудить почему что-то не инлайнится и какая будет польза от инлайна :-)

я бы сказал, что это спорная рекомендация и они совсем не эквивалентны. все конечно же зависит от конкретного кода, splice, например, линейная операция по количеству сдвигаемых элементов. в каких-то случаях может лучше arr[i] = null; делать (хоть оно и не эквивалентно delete)

--trace-deopt действительно выпилили.

Что касается --trace-opt/--trace-deopt то они ничего не выводят если ничего не оптимизируется/деоптимизируется. Попробуйте какой-нибудь горячий цикл.

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

1. По типу содержимого быстрые элементы бывают трех видов и трансформируются в одном направлении от менее общих к более общим: smi (small integer) -> double -> object. Бывают еще дырявые (holey) и непрерывные (packed). Еще бывают медленные элементы — представляются словарем.

2. Рекомендация соблюдать мономорфизм относится не к функциям, а к отдельным операциям, например, оператору умножения, оператору [] или вызову метода. Операции работают быстрее, когда они мономорфны — выполнятся над объектами одного и того же типа/скрытого класса. Как вы определяете «полиморфную функцию»?

3. V8 инлайнит функции, которые требуют переключения контекста на ia32 (Mac, Windows), но не инлайнит на x64/arm. Что касается функционального программирования, то зависит от того какие именно паттерны мы сравниваем. В большинстве случаев ООП основанное на связке constructor + prototype chain имеет больше шансов быть хорошо заоптимизированным. Можно почитать мой блог о том, какие именно проблемы возникают если опираться на замыкания: mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html

А собственно кроме узких мест ничего никогда тюнить и не надо. Все советы по оптимизации бесполезны в 99% случаев, пока вы не наткнетесь на случай попадающий в злые 1%, где надо костьми лечь но выжать все что можно.

выход заграницы arguments при чтении arguments[i] вызывает деоптимизацию, что и наблюдается.

тест кстати слегка шумный: например, непонятно зачем там создается closure на каждую итерацию цикла.

нет, это тривиальные перечислены в habrahabr.ru/post/151690/?reply_to=5153675#comment_5152882

я — Вячеслав :-)

у arguments object достаточно мутная семантика, поэтому если v8 видит, что он используется нетривиальным образом, то она отказывается оптимизировать. это проистекает из соображения, что в коде, для которого важны оптимизации, arguments чаще всего не используется или используется тривиальным способом, поэтому и реализовывать сложную поддержку нет смысла. (меньше сложностей — меньше багов).

это не совсем верно, ряд конструкций поддерживается в оптимизированном коде: arguments[i], arguments.length, func.apply(obj, arguments)

кстати проверить чистится ли WeakMap или нет на чистом JavaScriptе нельзя, он специально так задизайнен чтобы сделать сборку мусора ненаблюдаемой :-)

это не о тех mapах, это о скрытых классах, внутри они называются Map.

> в Map мусор собирается аналогично WeakMap

нет, Mapом все должно удерживаться, как вы проверяли?

Репозиторий на GitHub всего лишь зеркало.

Официальный репозиторий: code.google.com/p/v8/

Памятка для желающих поучаствовать: code.google.com/p/v8/wiki/Contributing

зарепортил баг: code.google.com/p/v8/issues/detail?id=2330

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

обратите внимание, я не пытаюсь утверждать, что V8 производит в данном конкретном случае супер код (хотя я посмотрел на него и код достаточно хороший, если не считать бага описнного внизу) или что пересечение границы JS-C++ легче перышка. я утверждаю другое: разница в десятки миллисекунд на таком коде не может быть объяснена задержками при пересечении этой границы.

более того, я даже склоняюсь ко мнению, что у автора что-то со флагами компиляции не так — из-за чего скорость С++ного кода оказалась такой странной. но для подтверждения надо посмотреть на то, что его компилятор породил в этом месте. (еще заметьте, что и время исполнения обычного С++ного варианта и CUDA-вского включают в себя время пересечения границы JS-C++, т.е. оно меньше 17ms).

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

обратите внимание, я не пытаюсь утверждать, что V8 производит в данном конкретном случае супер код (хотя я посмотрел на него и код достаточно хороший, если не считать бага описнного внизу) или что пересечение границы JS-C++ легче перышка. я утверждаю другое: разница в десятки миллисекунд на таком коде не может быть объяснена задержками при пересечении этой границы.

более того, я даже склоняюсь ко мнению, что у автора что-то со флагами компиляции не так — из-за чего скорость С++ного кода оказалась такой странной. но для подтверждения надо посмотреть на то, что его компилятор породил в этом месте. (еще заметьте, что и время исполнения обычного С++ного варианта и CUDA-вского включают в себя время пересечения границы JS-C++, т.е. оно меньше 17ms).

omega ~/src/temp/perl_vs_node ∳ git diff                                              [master@368da]
diff --git a/integral.js b/integral.js
index 7b11f22..194adb2 100755
--- a/integral.js
+++ b/integral.js
@@ -18,4 +18,5 @@ function integrateJS(x0,xN,y0,yN,iterations){
     console.log("JS time = "+(new Date().getTime() - time));
 }
 
-integrateJS(-4,4,-4,4,1024);
\ No newline at end of file
+integrateJS(-4,4,-4,4,1024);
+integrateJS(-4,4,-4,4,1024);
omega ~/src/temp/perl_vs_node ∳ node integral.js                                      [master@368da]
JS result = 127.99999736028109
JS time = 132
JS result = 127.99999736028109
JS time = 115
omega ~/src/temp/perl_vs_node ∳ node --nouse-osr integral.js                          [master@368da]
JS result = 127.99999736028109
JS time = 122
JS result = 127.99999736028109
JS time = 55

извиняюсь, коряво вставил консольный лог :-/

у меня на ноде v0.8.8 вылазит баг в V8ом выводе представлений (representation inference) из-за которого замена на стэке (on stack replacement) пораждает совершенно бредовый код, в котором он пытается привести заведомо не целое значение к целому из-за чего происходит деоптимизация… в результате код постоянно крутится в неоптимизированной версии.

если же я запрещаю OSR и вызываю integrateJS дважды, то картина с пиковой производительностью получается примерно такая:

omega ~/src/temp/perl_vs_node ∳ git diff [master@368da] diff --git a/integral.js b/integral.js index 7b11f22..194adb2 100755 --- a/integral.js +++ b/integral.js @@ -18,4 +18,5 @@ function integrateJS(x0,xN,y0,yN,iterations){ console.log("JS time = "+(new Date().getTime() - time)); } -integrateJS(-4,4,-4,4,1024); \ No newline at end of file +integrateJS(-4,4,-4,4,1024); +integrateJS(-4,4,-4,4,1024); omega ~/src/temp/perl_vs_node ∳ node integral.js [master@368da] JS result = 127.99999736028109 JS time = 132 JS result = 127.99999736028109 JS time = 115 omega ~/src/temp/perl_vs_node ∳ node --nouse-osr integral.js [master@368da] JS result = 127.99999736028109 JS time = 122 JS result = 127.99999736028109 JS time = 55

баг я зарапортую на эту тему. причина по моей прикидке в том, что начальное значение переменной result — 0 выглядит как целое число и попадая в phi-функцию на границе между нормальным потоком управления и OSR-entry блоком приводит к неправильному выводу представления для этой phi (https://github.com/v8/v8/blob/d3924c236bfca217385eaf5355a96146f0dcc60d/src/hydrogen-instructions.cc#L2567-2576 < — код увидев 0 выберет целое представление) и почему-то посказки (hint) для HUnknownOSRValue на обратной дуге не сработали.

Кстати, если заменить result = 0, на result = 0.1 баг в representation inference по понятным причинам пропадает.

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

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

а сами объекты с 9 свойствами, конечно же, помирают… просто они были меньше с словаря, который теперь свисает с каждого testedObject[i], что пораждает иллюзию их живости.

Прежде всего совет: не пытайтесь понять, что удаляется, а что не удаляется по графику потребления памяти — это гадание на кофейной гуще. Просто посмотрите на снапшот кучи.

Объяснение (по крайней мере для Хрома) очень простое: когда вы делаете delete testedObject[i].obj, V8 нормализует объект testedObject[i] — трансформирует его из быстрого компактного представления в медленное и раздутое представление на основе словаря, который еще и выделяется с запасом по размеру. При этом V8 не замечает, что после удаления в словаре будет пусто — и словарь (800 байтов) остается болтаться в воздухе. И так для каждого из ваших объектов.

это не совсем правильный вывод: бенчмарк фокусируется на производительности чистого javascript, который однопоточен по своей природе. (workerы не являются частью ECMAScript стандарта и потому в тестах не используются). поэтому основной поток исполнения бенчмарка просто не может загрузить больше одного ядра.

некоторые JavaScript рантаймы, впрочем, испольуют потоки для различных внутренних целей: например, конкурентная сборка мусора и компиляция в Chakra, параллельная фаза разметки (marking) в JavaScriptCore, фаза sweeping в SpiderMonkey. так что наличие нескольких дополнительных ядер только на пользу.

если игра использует много чисел с плавающей точкой, то результат NavierStokes все-таки имеет отношение к качеству оптимизации такого кода.

Тесты в V8 Benchmark Suite могут со стороны выглядеть совершенно случайными, но на самом деле они тестируют фундаментальные вещи. NavierStokes, например, тестирует качество оптимизаций операций над числами с плавающей точкой и скорость работы массивов содержащих числа с плавающей точкой.

Проблема с большим реальным кодом состоит в том, что в нем сразу множество факторов влияющих на производительность смешиваются, поэтому V8 Benchmark Suite пытался разложить, так сказать, различные факторы по полочкам и каждый бенчмарк был достаточно сфокусирован на фичах языка, которые V8 хотела ускорить: DeltaBlue — полиморфный объектно-ориентированный код, Crypto — побитовые операции и т.д.

Хорошее описание фокуса каждого бенчмарка: developers.google.com/octane/benchmark