• Часто задаваемые вопросы про asm.js
    0
    Мне вот интересно, для чего бы вы его использовали? Руками такой код писать удовольствия мало.
  • Dart: веб-компоненты в действии
    0
    Привязка данных в Dart вдохновлена MDV (Model Driven Views), который действительно не является частью вебкомпонентов. Однако, части необходимые для MDV постепенно проникают в платформу:

    groups.google.com/d/msg/mdv-discuss/I6oiK8z0LdI/H3i4MlszsFcJ
  • Почему eval — это не всегда плохо
    +2
    Никакой произведенный evalом код не оптимизируется. Но new Function — не eval, поэтому произведенный им код оптимизируется.
  • Почему eval — это не всегда плохо
    +5
    скрытые классы всегда используются. словарное представление тоже имеет скрытый класс, который собственно и говорит что поля представлены словарем.

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

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

    ну и eval'а на V8 нужно избегать как огня — произведенный им код не оптимизируется. хотя в данном конкретном случае это и не важно, потому что основное время тратится в клонировании object literal boilerplate, которое выполняется большей частью в стабе.
  • Оптимизируем производительность JavaScript для V8
    0
    ничто не мешает, просто не реализованна нормальная протяжка констант. а без протяжки констант на одном локальном type feedback тут далеко не уедешь из-за полиморфизма точки вызова внутри цикла, который внутри forEach.
  • Первый стабильный SDK для Dart
    0
    Меня интересует язык и что делает его «облегченной версией явы».

    Библиотека имеет некоторое сходство с Java, но также и имеет и сходство с JavaScript. К тому же она в активной переработке.
  • Первый стабильный SDK для Dart
    0
    что, кроме пары ключевых слов общего с Java?
  • Оптимизируем производительность JavaScript для V8
    0
    ну по сравнению с циклом for если зарядить на длинном массиве, много-много раз пустую функцию то будет видна цена вызова.
  • Оптимизируем производительность JavaScript для V8
    0
    следует определить понятие быстро :-)

    над каждым элементом функция честно вызывается. в зависимости от того, что функция делает цена этого вызова может быть заметна, а может быть амортизированна и не очень заметна.
  • Оптимизируем производительность JavaScript для V8
    0
    как это только хром? постоянно гоняем тесты dart2js на FF, Safari, IE: build.chromium.org/p/client.dart/console
  • Оптимизируем производительность JavaScript для V8
    0
    эта функция не заинлайнится из-за array literal даже если будет в глобальном scope: code.google.com/p/v8/issues/detail?id=1322

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

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

    прежде всего 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 же, который удаляет и сдвигает элементы не оставляет после себя дырок, поэтому безобиден в данном отношении. Следует, впрочем, всегда помнить, что он имеет линейную сложность по количеству сдвигаемых элементов.
  • Оптимизируем производительность JavaScript для V8
    0
    Все зависит от конкретной задачи, на самом деле. Каждый код очень индивидуален.
  • Оптимизируем производительность JavaScript для V8
    +1
    > Вы давно видели 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

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

    Если вы набросаете примеры кода, то можно будет обсудить почему что-то не инлайнится и какая будет польза от инлайна :-)
  • Оптимизируем производительность JavaScript для V8
    +1
    я бы сказал, что это спорная рекомендация и они совсем не эквивалентны. все конечно же зависит от конкретного кода, splice, например, линейная операция по количеству сдвигаемых элементов. в каких-то случаях может лучше arr[i] = null; делать (хоть оно и не эквивалентно delete)
  • Оптимизируем производительность JavaScript для V8
    0
    --trace-deopt действительно выпилили.

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

  • Оптимизируем производительность JavaScript для V8
    +1
    когда говорится, что лучше не удалять элементы, имеется ввиду удаление многих элементво из середины оператором delete.
  • Оптимизируем производительность JavaScript для V8
    +2
    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%, где надо костьми лечь но выжать все что можно.
  • ECMAScript Harmony и Node.js
    0
    выход заграницы arguments при чтении arguments[i] вызывает деоптимизацию, что и наблюдается.

    тест кстати слегка шумный: например, непонятно зачем там создается closure на каждую итерацию цикла.
  • ECMAScript Harmony и Node.js
    0
    нет, это тривиальные перечислены в habrahabr.ru/post/151690/?reply_to=5153675#comment_5152882
  • ECMAScript Harmony и Node.js
    +1
    я — Вячеслав :-)
  • ECMAScript Harmony и Node.js
    +2
    у arguments object достаточно мутная семантика, поэтому если v8 видит, что он используется нетривиальным образом, то она отказывается оптимизировать. это проистекает из соображения, что в коде, для которого важны оптимизации, arguments чаще всего не используется или используется тривиальным способом, поэтому и реализовывать сложную поддержку нет смысла. (меньше сложностей — меньше багов).
  • ECMAScript Harmony и Node.js
    +1
    это не совсем верно, ряд конструкций поддерживается в оптимизированном коде: arguments[i], arguments.length, func.apply(obj, arguments)

  • ECMAScript Harmony и Node.js
    0
    кстати проверить чистится ли WeakMap или нет на чистом JavaScriptе нельзя, он специально так задизайнен чтобы сделать сборку мусора ненаблюдаемой :-)
  • ECMAScript Harmony и Node.js
    0
    это не о тех mapах, это о скрытых классах, внутри они называются Map.
  • ECMAScript Harmony и Node.js
    0
    > в Map мусор собирается аналогично WeakMap

    нет, Mapом все должно удерживаться, как вы проверяли?
  • ECMAScript Harmony и Node.js
    0
    Репозиторий на GitHub всего лишь зеркало.

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

    Памятка для желающих поучаствовать: code.google.com/p/v8/wiki/Contributing
  • Ускоряем node.js: нативные модули и CUDA
    0
    зарепортил баг: code.google.com/p/v8/issues/detail?id=2330
  • Ускоряем node.js: нативные модули и CUDA
    +1
    какой факт? что замеры производительности С++ кода на разных машинах, компиляторах и флагах сборки дали разные результаты? это действительно факт.

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

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

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

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

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

  • Ускоряем node.js: нативные модули и CUDA
    +1
    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
    


    извиняюсь, коряво вставил консольный лог :-/
  • Ускоряем node.js: нативные модули и CUDA
    0
    у меня на ноде 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 по понятным причинам пропадает.
  • Ускоряем node.js: нативные модули и CUDA
    0
    функция вызывается один раз и выполняется сотни миллисекунд. в таком случае накладные расходы на пересечение границы просто незаметны. они ведь отнюдь не десятками миллисекунд измеряются, а совсем даже долями миллисекунды.
  • JavaScript: оператор delete создает утечку!?
    +2
    утечка — это когда память болтается непонятно где, не используется и не может быть переиспользована. а здесь не эффективное использование памяти, потому что это память никуда не пропала и занята объектом, на который есть валидные ссылки из другого объекта.
  • JavaScript: оператор delete создает утечку!?
    +3
    а сами объекты с 9 свойствами, конечно же, помирают… просто они были меньше с словаря, который теперь свисает с каждого testedObject[i], что пораждает иллюзию их живости.
  • JavaScript: оператор delete создает утечку!?
    +8
    Прежде всего совет: не пытайтесь понять, что удаляется, а что не удаляется по графику потребления памяти — это гадание на кофейной гуще. Просто посмотрите на снапшот кучи.

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

    некоторые JavaScript рантаймы, впрочем, испольуют потоки для различных внутренних целей: например, конкурентная сборка мусора и компиляция в Chakra, параллельная фаза разметки (marking) в JavaScriptCore, фаза sweeping в SpiderMonkey. так что наличие нескольких дополнительных ядер только на пользу.
  • Google представила новый бенчмарк — Octane
    +1
    если игра использует много чисел с плавающей точкой, то результат NavierStokes все-таки имеет отношение к качеству оптимизации такого кода.
  • Google представила новый бенчмарк — Octane
    +1
    Тесты в V8 Benchmark Suite могут со стороны выглядеть совершенно случайными, но на самом деле они тестируют фундаментальные вещи. NavierStokes, например, тестирует качество оптимизаций операций над числами с плавающей точкой и скорость работы массивов содержащих числа с плавающей точкой.

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

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