Пользователь
0,0
рейтинг
18 ноября 2010 в 02:26

Избавление от «мертвого» кода в Javascript в IE9 перевод

[От переводчика: данный перевод является частью этого официального поста из блога команды IE и призван разъяснить недавнее недоразумение: IE9 — Обман при прохождении SunSpider JS? ]

Одним из изменений в нашем новом JavaScript движке, под кодовым названием Chakra, является уничтожение мертвого кода, с целью повышения производительности работы реальных сайтов. Вчера после полудня кто-то запостил вопрос у нас на коннекте — «What sorts of code does the analysis work on, other than the exact [math-cordic test] function included in SunSpider». Так как многих заинтересовал этот вопрос, то этот блог пост призван ответить на него.


Если говорить вкратце, то JavaScript движок IE9 претерпел огромное количество разнообразных изменений с целью повышения производительности реальных веб-приложений. Вы можете попробовать некоторые примеры приложений нашем сайте ietestdrive.com, а затем сравнить результаты в разных браузерах. Поведение нашего JS движка это не «специально подкрученная» оптимизация и это не баг.

В Chakra мы применили некоторых оптимизации, хорошо известные в мире компиляторов, в частности исключение «мертвого» кода. Данный вид оптимизации просматривает код программы в поисках кода, который не меняет состояние программы, затем удаляет этот код. Это приносит сразу две выгоды: уменьшение размера занимаемой программой памяти и увеличение скорости выполнения программы.

Вот очень простой примера Javascript-кода, который является хорошим кандидатом для удаления, потому что условие всегда будет ложным и движок js вполне может его удалить


function func() {
    var x = 1;
    var y = 3;
    var w = x + y;

    if (w != 4) {
        // dead code 
    }
}


Уничтожение «мертвого» кода особенно эффективно, когда код выполняется много раз, например в цикле. В следующем примере, код в цикле перезаписывает значение одной и той же переменной (в computer science это называется «мертвым» сохранением), поэтому он может сведен к одному вызову


function func(a, b) {
    var x;
    var i = 300;
    while (i--) {
        x = a + b; // dead store
    }
}


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


function sum() {
    var a = [1, 2, 3, 4, 5];
    var sum = 0.0;
    
    // dead loop elimination
    for (var i = 0; i < 5; i++) {
        sum += a[i];
    }
}


Разработчики довольно часто пишут «мертвый» код, не подозревая об этом, и могут полагаться, что компиляторы оптимизируют код. Большинство современных компиляторов сегодня производят большое количество оптимизаций по вычислению и удалению неиспользуемого кода.

Что ж, почему этот эффект проявляется в тесте math-cordic из Webkit SunSpider suite? Давайте посмотрим на внутренний код теста.


function cordicsincos() { 
     var X;  
     var Y;  
     var TargetAngle; 
     var CurrAngle;  
     var Step;   
     X = FIXED(AG_CONST);         /* AG_CONST * cos(0) */ 
     Y = 0;                       /* AG_CONST * sin(0) */ 
   
    TargetAngle = FIXED(28.027);  
    CurrAngle = 0;  
    for (Step = 0; Step < 12; Step++) { 
        var NewX; 
            if (TargetAngle > CurrAngle) { 
               NewX = X - (Y >> Step);  
               Y = (X >> Step) + Y; 
               X = NewX; 
               CurrAngle += Angles[Step];  
            } else { 
               NewX = X + (Y >> Step); 
               Y = -(X >> Step) + Y; 
               X = NewX; 
               CurrAngle -= Angles[Step]; 
            } 
    } 
} 


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

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

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

Данные оптимизации относительно новы в мире исполняющих сред JavaScript, хотя в реальных приложениях достаточно много «мертвого» кода. Данные оптимизации часто требуют значительного анализа потока выполнения кода, и если в реальных веб-приложениях тратить большое количество времени на анализ кода, то может получиться что мы снизим отзывчивость веб-страницы. Наш движок Chakra балансирует между качеством кода и временем на анализ и производит лишь наименее затратные и очевидные оптимизации «мертвого» кода. И баги, отрапортованные через Connect являются примерами того, где код не до конца оптимизирован. Мы продолжим «допиливать» наш движок до финальной версии.

Удаление данного типа «мертвого» кода одна из немногих оптимизаций, производимых Chakra для избегания выполнения бесполезной работы. В течение последующих нескольких дней мы напишем о некоторых других техниках применяемых в нашем JavaScript движке для достижения более высокой производительности.

— Dean Hachamovitch

От переводчика: вышедшую совсем недавно обновленную предварительную версию IE9 можно скачать здесь ietestdrive.com
И собственно обновленные результаты теста:image
UPD: Добавил к графикам табличку, для большей наглядности. На гарфике не видно разницы между быстрыми браузерами.
Detailed Results Average (ms)
IE8 3746
Firefox 3.6.12 753
Safari 5.0.2 328
Firefox 4.0 Pre-Release Beta7 277
Chrome 7.0 262
Opera 10.63 246
Opera 11 Alpha 242
Chrome 8.0 Beta 233
IE9 Platform Preview #7 216
Перевод: Dean Hachamovitch
@mstyura
карма
23,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (167)

  • +29
    Спасибо, но я все равно не понял, чем именно конструкции «true;», «return;» и аналогичные не подходят под понятие мертвого кода и сводят всю оптимизацию на нет?
    • +2
      Наш движок Chakra балансирует между качеством кода и временем на анализ и производит лишь наименее затратные и очевидные оптимизации «мертвого» кода.

      Наверное баланс был нарушен не в ту сторону, но в текущей версии ie9pp7, измененный и неизменненый код теста выполняются одинаково быстро — видимо допилили.
      • +4
        простите, как вы это проверяете? просто в прошлом топике тоже многие кричали, что последний ие одинаково выполняет, но оказалось, что, на самом деле, просто не туда смотрели.
        можете показать результаты?
        • +4
          Да, действительно. Я сам не туда посмотрел. Извините.
          • +1
            ничего. просто, на всякий случай, чтобы эту тему не поднимать — выложите бенчмарк (полный лог результатов)
      • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      Дело в том, что инструкция return дает понять, что функция закончила свое выполнение. Без ее присутствия интерпретатору необходимо самому «догадываться» о том, когда функция завершилась. Поэтому явное указание return; ускоряет время отработки скрипта. Этот прием работает не только с IE.

      О принципе работы true; я могу только строить догадки (например, эта инструкция ускоряет доступ к объектам через scope chain).

      Как бы там ни было:
      — заголовок желный;
      — инжерены из МС подправили код теста, зная особенности работы своего движка (сжульничали);

      Интересные выводы можно сделать из выступления www.youtube.com/watch?v=mHtdZgou0qU, в котором рассказаны способы ускорения своего кода + описание их принципов.
    • 0
      Это известный прием — прогнать много пурги ни о чем, чтобы отвлечь внимание от главного.

      Разработчики IE, в основном, из Индии (еще бы, название движка — Чакра). Принципы хардкодинга, уважаемые там известны всем читателям сайтов типа codewtf.
    • +1
      Ну как же, все просто. В первоначальном тесте все браузеры выполняют этот код, IE не выполняет, по этому на фоне остальных браузеров смотрится особняком. Когда поставили return до цикла, остальные браузеры также не выполняют код, по этому результаты выравниваются, так как остальные браузеры в том же положении, что и в ie.
  • –2
    Почему-то прочитав заголовок, я сразу подумал о всех этих JS-костылях для поддержки IE…
    • 0
      Оптимизации == костыли?
  • +1
    Осталось теперь собрать всех бобров, которые закидали homm'а (и не только) минусами в предыдущем топике и попросить извиниться хотя бы :)
    • –4
      а вы побольше слушайте менеджеров из Микрософта.
      я уж скорее репортажу по ОРТ поверю, чем им.
      • 0
        Конечно же они там все работать не умеют и врут постоянно… Понаберут студентов…
        • –16
          Даа! Как вы догадались?!
        • +1
          просто у некоторых людей по факту — работа такая — приукрашать.
          и они есть в каждой крупной компании, которая что-то продает :)
      • +7
        Попробуй верить здравому смыслу.
    • +1
      дак майкрософт этим дал ответ только на вопрос непрограммистов «о чем вообще речь?». ждем ответ для программистов.
    • +1
      По сути-то они ничего не ответили. Рассказали, что такое дед-код и все. А на тему почему строчка true сводит на нет всю оптимизацию — по прежнему непонятно.
      ПС Я никого не минусовал, если что) Просто интересно, как же тут все на самом деле.
    • +1
      За что, простите? В этом потоке слов нет ни слова о том почему так произошло. Более того, этот поток слов _можно_ понять как — вот в тесте есть кусок кода, мы на него посмотрели глазами — это же синус и косинус! (надо объясниять, что именно глазами — хотел бы я посмотреть на оптимизатор, который по подобному коду в общем виде определит, что это синус-косинус). Да и вообще, посмотрели ещё раз — он бесполезен, поэтому мы его объявили мёртвым (встроили распознавалку именно этого куска кода) и выкидываем. В таком случае абсолютно понятно почему распознавал… «оптимизатор» ломается. :)
      Почему он должен ломаться, если всё описанное работает как надо совершенно не понятно по-прежнему.
      • –1
        Да потому что лемминговый радикализм зашкаливает последнее время. Хер бы кто полез разбираться в ситуации (начиная от дальнейших экспериментов с изменением кода, заканчивая попыткой проанализировать ситуацию на низком уровне), зато шума было, мать моя женщина. Я не приверженец MS, я ненавижу IE (и не буду пользоваться даже девяткой), но при этом здравый смысл и заданная планка толерантности позволяет хотя бы задуматься перед тем как пулять налево и направо, брызгать слюной.

        Вы абсолютно грамотно говорите — «не понятно». А те кто шумели в эпик-треде были блин на 100% уверены, верняк, блябудуmsуроды и т.д.

        Я вообще зря влез со своей иронией, ломайте головы дальше. Мир настолько инвариантен, что уууух!
    • +6
      Объясните же непонятливому «бобру», каким имеено образом данная статья является опровержением предыдущей? Если выразить общий смысл каждой из статей одним предложением, то получится что-то вроде такого:

      Rob Sayre:
      — Почему при добавлении ничего не делающих («мёртвых») инструкций ИЕ выполняет тест в разы медленнее?

      Dean Hachamovitch:
      — Потому что его движок офигенно оптимизирует код и выкидывает мёртвые участки!

      Каким образом второе является ответом на первое — моя логика понимать отказывается.

      Кстати, если переставить реплики местами, то всё получится :)
      • –1
        Да хрен его знает чем все закончится, в ситуации следует детально разобраться. Просто откуда такая уверенность в ms-обмане берется? Действительно, ситуация выглядит крайне забавно с обеих сторон. Оба варианта развития, на мой взгляд, абсолютно равнозначны. Я допускаю ошибку в «менеджере мертвого кода» (допустим косяк с эвристикой или подсчетом веса блока кода), допускаю использование ряда методик заточенных под конкретно этот тест спайдера и еще с полсотню вариантов :)

        PS. Не хотел делать вброс для очередной ругани по теме предыдущего топика.
        • +2
          да потому что регулярно их за каким-нибудь обманом да замечаешь
          • –1
            Обычно сразу понимаю, что это маркетинговый ход (очередной тест сделанный в их лабораториях и т.д.) — и это их работа, пускай работают. Обманули (если только не ожидания, они часто делают это) — это уже серьезно.
  • +2
    IE обогнал хром? Вот это да!
    Если бы еще с поддержкой стандартов было все так же радужно у него.
    • 0
      Да вроде как в ИЕ9 получше. Сам уже тестирую, действительно неудобны только две вещи:
      1. есть старые конструкции типа , которые приходится расширять дополнительным условием, чтобы больше не использовались старые медленные workaround;
      2. он все еще бета и приходится все равно пилить код для совместимости с IE8/7.
    • +5
      Дык, тут всё от конфигурации зависит и «плотности» (расширения, плагины) использования. У меня, правда, Chromium 9.0.589.0 (66509), но:
      Результат такой:
      Хромиум 9 — 290,6 мс (link)
      ИЕ 9 — 296,2 мс (link)
      В V8 Benchmark, естественно, у Chromium результаты ещё мощнее:
      4304 (link)
      У IE 9
      1664 (link)
      Пискипер не юзал, но там у IE 9 результаты обычно чуть ли не хуже, чем у 3-ьего Огнелиса. Видимо, инженеры МС решили не пилить браузер под Пискипер.

      Конфа:
      Win7 HP
      IC2D — 2,26 GHz
      RAM — 2 Gb.

      У меня Chromium 9 «быстрее», но у меня эти тесты в печёнках сидят. Задолбали подгонять браузеры под какие-то тесты, а потом трындеть на весь свет, какие мы все быстрые и хорошие. Это касается не только МС, но и Мозилла. Кстати, Гугель в этом плане спокойнее стал, не став трубить о сверхскоростях, выкинув на растерзание фанатов вышеупомянутый тест v8. Мол, вы сами занимайтесь тестами и написанием восторженных блогозаписей, а мы тут делом заняты.

      Юзеров, имхо, привлекут не какие-то тесты, понятные только аудитории уровня Хабра, в которых кто-то там кого-то делает, а прикольные видюшки, типа Опера и картошка. 90% моих знакомых класть на Javascript, песочницы, sunspider'ы, chakr'ы и прочая. Им эти слова ничего не говорят.
      • 0
        > Если бы еще с поддержкой стандартов было все так же радужно у него.
        Я отвечал к этому пункту. Думаю, очевидно, что я не имел ввиду, что ИЕ9 получше Хрома)
    • –2
      через неделю после релиза ИЕ9 другие браузеры обновятся раз 100500 и вздрючат на всех членомерках
      другое дело как дела обстоят в _реальных_ условиях, а не в синтетических тестах
    • +4
      IE обогнал хром? Вот это да!

      Хром выполняет мертвый код почти так же быстро, как IE — не выполняет.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +13
      они этого и не отрицают, а просто уходят от этой темы.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Объясните как работает оптимизатор? Ментальное задание звучит красиво, а как в програмных структурах это реализуется?
        • –3
          невозможно представить себе оптимизатор, который сработает на фрагменте (1), но не сработает на (2) и (3)
          Что тут можно сказать, тренируйте воображение.
    • –1
      ещё живее:
      Step = 0;
      while(Step < 12) {

      Step++;
      }
      Глобальные переменные ни на что не влияют, rojer!
      • 0
        Step объявленна в начале ф-ции
        • –1
          Вот оно что. Ну rojer «не сказал, как тестировал».
          • +4
            я не понимаю, почему ты так стараешься выгородить Микрософт при явном фейле (даже если это не обман, то фейл оптимизатора).
            Очевидно, что приведенный пример заменяет собой for (Step = 0; Step < 12; Step++) { в исходном. И в исходном Step тоже объявленна в начале.
            • –1
              Вот именно потому, что это может быть не обман, а фейл оптимизатора. И я не стараюсь выгородить Майкрософт, у меня мозг есть и оперирую я фактами. Это может показаться удивительным, да.
              • +3
                фейл оптимизатора в том, что он работает только на тестах СанСпайдер
          • +5
            А Вы по ссылке «источник», которую дал roger, сходили, или как обычно? :)
            • –1
              Сходил, там по английски, мне его воспринимать тяжелее, я решил не читать. Вот если бы rojer упомянул, что это не отдельные куски кода, а замена в оригинальном тесте — все было бы ясно без ссылки.
              • +2
                Достаточно посмотреть на diff-ы и на циферки, приведённые после них.
                • –4
                  Увлекательнейшее занятие, смотреть diff, особенно когда перед глазами нет исходного файла. Все же по памяти помнят, где какой номер у строки. К теме это не относится, просто решил выразить восхищение подачей материала.
                  • +3
                    homm, ну это уже совсем ребячество. Скажите, зачем Вам исходный файл и уж тем более номера строки для того, чтобы понять смысл изменения

                      --- tests/sunspider-0.9.1/math-cordic.js        2010-11-17 00:55:29.000000000 -0700
                      +++ tests/sunspider-0.9.1-deadcode/math-cordic.js       2010-11-17 02:09:34.000000000 -0700
                      @@ -62,7 +62,7 @@
                    
                           TargetAngle = FIXED(28.027);
                           CurrAngle = 0;
                      -    for (Step = 0; Step < 12; Step++) {
                      +    for (Step = 12; Step > 0; Step--) {
                               var NewX;
                               if (TargetAngle > CurrAngle) {
                                   NewX = X - (Y >> Step);
                    

                    ?

                    Ладно бы если были диффы на килобайты, но тут-то простые однострочники. Несолидно, homm, ой несолидно…
    • –2
      > невозможно представить
      У Вас действительно очень плохая фантазия. А «техническая интуиция» на околонулевом уровне.

      Итак,
      1. Насколько часто конкретно Вы НА ПРАКТИКЕ используете каждый из трех вариантов?
      2. Вам кажется, что оптимизатор клиентского яваскрипта должен проводить полную глобальную оптимизацию всего кода в том числе ловить всякие трюки типа «нестандартного» направления итерации и пустые true?
      3. Чтоб проверить «натасканность» оптимизатор конкретно на санспайдер, а не на часто используемые конструкции итерации от нуля до верхнего предела, простых условий и арифметических операций нужно добавлять ИМЕННО дополнительные простые условия, итерации и арифметику.
      • +1
        нестандартное направление итерации? лично я — всегда, когда направление не имеет смысла. сравните:
        for (var i = 0, l = array.length; i < l; i++) {
        // vs
        for (var i = array.length; i--;) {
        

        Тем более, это быстрее.
        • 0
          for (var i in array)
          нэ?
          И кстати, на каком основании сделано заключение, что «это быстрее»?
          • 0
            for in — плох для итерации по массивам, так как перебирает и свойства. вообще самый правильный вариант (если не знаете, какое содержимое массива может быть):
            for (var i = 0, l = array.length; i < l; i++) if (i in array) {
            

            заключение сделано на основании личных тестов. хотя оптимизация спичечная, да.
            • –1
              То есть Вы «всегда, когда направление не имеет смысла» не знаете, чего содержится в Ваших массивах? Вообще говоря, «i < array.length» — первый кандидат на оптизацию, потому что используется повсеместно
              • +1
                нет. когда направление не имеет смысла(например, когда надо получить сумму всех чисел в массиве) — я использую
                for (var i = array.length; i--;) {
                

                когда я не знаю, что содержится в массивах (там может не быть нескольких элементов) — я(и не только я, в коде Мутулз используется такая же конструкция) использую
                for (var i = 0, l = array.length; i < l; i++) if (i in array) {
                

                Во всех остальных ситуациях (когда направление имеет смысл, но я контролирую содержимое массива) можно использовать такой код:
                for (var i = 0, l = array.length; i < l; i++)
                


                А вы специально перекрутили слова, или просто не поняли меня?
                • –1
                  Я не перекручивал слова. На вопрос насколько часто Вы используете «обратную» итерацию, Вы ответили всегда, аргументируя это бОльшей скоростью, более очевидный вариант с for in отмели из-за невозможности контроля содержимого массива в общем случае.

                  И мне все еще интересно, основывается ли использование
                  for (var i = 0, l = array.length; i < l; i++)

                  вместо не менее очевидного, чем for in
                  for (var i = 0; i < array.length; i++)

                  на каких либо реальных тестах, или исключительно на предположении, что любой яваскрипт движок будет вызывать array.length на каждой итерации даже точно зная, что массив не менялся.
                  • +2
                    ну вы опять перекрутили мои слова. точнее вырвали из контекста. ну что вы занимаетесь такими дешевыми вещами?
                    во-первых, я использую не всегда, а только когда направление не имеет значение.
                    во-вторых не только из-за скорости, но и из-за читаемости.
                    вместо не менее очевидного, чем for in

                    for (var i = 0; i < array.length; i++)
                    // имхо, менее очевиден, чем
                    for (var i = array.length; i--;)
                    // и, имхо, менее очевиден, чем 
                    for (var i in array)
                    


                    На счет последних вопросов — не знаю. Просто поверил подходу MooTools, как уважаемому мной фреймворку. Подозреваю, что они тесты ставили:
                    Array.implement({
                    	forEach: function(fn, bind){
                    		for (var i = 0, l = this.length; i < l; i++){
                    			if (i in this) fn.call(bind, this[i], i, this);
                    		}
                    	},
                    

                • 0
                  И еще вопрос, проверяли ли Вы как реагирует IE9 на
                  for (var i = 0, l = array.length; i < l; i++)
                  • +3
                    вы на меня странно нападаете… я — ничего не проверял, о чём уже заявил неоднократно. но много людей, в т.ч. сторонников IE выкладывали свои тесты. чем доказали, что IE в этом месте лажает. как на меня — аргументов достаточно, чтобы понять, в чём фейл
        • –1
          Ах, да. Раз уж взялись высказывать негодование, потрудитесь ответить и на остальные вопросы.
          • +1
            1. я не высказываю негодование по поводу вашего сообщения и не утверждал, что оно — ложное или правдивое. просто, как опытный разработчик, заметил, что обратный цикл — достаточно частое явление.
            2. пустые true могут быть также следствием ошибки. еще стоит взять весь цикл в if ( 1 ) — такой момент встречается регулярно, например есть в коде phpBB
            3. я бы с удовольствием поставил большую серию тестов, будь у меня IE9. Может, как-то, сделаю это.
            • –2
              2. Отсутствие оптимизации в результате ошибки — не такая уж большая цена.
              3. А мне бы доставило не меньшее удовольствие, если бы ВЫ перестали сначала делать выводы (вернее все «выводы», как я понимаю, давно уже сделаны), а потом искали под них «факты».
              • +1
                Извините, но без исходных кодов любых тестов будет недостаточно.
                Пока что тех фактов, что уже есть — достаточно, чтобы сделать предварительные выводы. ИЕ9 не справилась ни с одним из тестов, кроме тех, что в санспайдере по-умолчанию
                • –1
                  > ИЕ9 не справилась ни с одним из тестов
                  Мне так нравится с Вами беседовать. Вы же ТОЛЬКО ЧТО признались, что не выполняли НИ ОДНОГО теста.

                  Вот, прямо на коленке. Скажите, Вы считаете оптимизацию циклов, условий и арифметики ненужным занятием? А в свете «неизбежной замены толстых клиентов веб приложениями»?
                  • 0
                    Вы ошибаетесь. Я признался в этом давным давно
                    • +1
                      Достойный ответ, бро.
                      • 0
                        если вы меня поддернули, то как минимум в этой ветке — еще дважды:
                        habrahabr.ru/blogs/browsers/108355/#comment_3431927
                        я — ничего не проверял, о чём уже заявил неоднократно. но много людей, в т.ч. сторонников IE выкладывали свои тесты.

                        habrahabr.ru/blogs/browsers/108355/#comment_3431879
                        я бы с удовольствием поставил большую серию тестов, будь у меня IE9. Может, как-то, сделаю это.

                        И еще много, если поискать.
                        • –3
                          Нет, ты правда слабоумный? Тебе говорят факты, задают вопросы, а все что ты можешь ответить — «я признался давно, а не только что». Это да, это очень важное замечание в свете данной беседы.
                          • +2
                            homm, ты очень любишь расставлять ярлыки.
                            TimTowdy идиотом назвали, меня — слабоумным. Сразу видны аргументы сторонников Микрософта. детсад. Я ответил на первый абзац. А на второй я ответил по ссылке, что дал amirul, бро
                            • –3
                              ты очень любишь расставлять ярлыки.
                              Да вы шо?

                              вы притворяетесь слепым (евангелист)
                              Это объясняется вами и другими фанатами МС
                              с каких пор ты стал евангелистом Микрософт?
                              аргументы сторонников Микрософта
                              … написал TheShock.

                              • +1
                                вы считаете ярлыки «сторонник»,«евангелист»,«фанат» и «идиот»,«слабоумный» — одного уровня. евангелист сейчас применяется в достаточно широком смысле. и то, что вы так яро защищаете Микрософт в данном случае вполне можно назвать евангелизмом. Или вы сейчас выступаете не на стороне Микрософт? Вы не сторонники, нет?
                                • –5
                                  так яро защищаете Микрософт
                                  То, что ты слабоумен — очевидный факт. Иначе не объяснить, что наличие другого взгляда ты способен объяснить только приверженностью какому-то лагерю.
                                  • +4
                                    я так понимаю, вы — врач. скажите, а какая у меня степень слабоумия? я еще могу ходить сам в туалет и сидеть за компьютером, или мне уже помогают?

                                    сейчас вы выступаете на стороне Микрософт, потому вас вполне можно назвать «Сторонниками Микрософт в этом споре»

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

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

                                    если, кроме того, какие у меня диагнозы — вам сказать нечего, то лучше не говорите.
                                    • +3
                                      и не надо цеплятся к словам. того, что Микрософт в очередной раз всех постарались наебать и прокололись это не скроет
                                    • –6
                                      сейчас вы выступаете на стороне Микрософт
                                      У тебя последняя степень, самая высокая.

                                      на самом деле, вам нечем возразить в этом споре
                                      … сказал человек, написавший этот комментарий.
                                      • +4
                                        Тяжёлая. Повседневная деятельность настолько нарушена, что требуется постоянный надзор (например, больной не в состоянии выполнять правила личной гигиены, не понимает, что ему говорят и сам не говорит).

                                        На самом деле вы, наверное ошибаетесь. В таком случае я не смог бы с вами общаться даже через посредника.
          • +1
            и если true; или while вместо for встречаются не так часто, то пустой return можно найти в большинстве скриптов.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Специально под санспайдер? А по моему специально под циклы, условия и присвоения. Или Вам кажется, что их отимизация не нужна в принципе (как в других движках)?

          Вот простейший пример СОВСЕМ НЕ ПОХОЖИЙ на санспайдер:
          <html><body>
          <script language="Javascript">
          	var start = new Date();
          	for (var i = 0; i < 1000000; i++) {
          		if (1) {
          			for (var j = 0; j < 1000; j++)
          				var k = i + j;
          		} else {
          			for (var j = 0; j < 1000; j++)
          				var k = i - j;
          		}
          	}
          	alert(new Date() - start);
          </script>
          </body></html>
          


          IE PP7 — 30542
          Chrome 8.0.552 — 75235
          • +1
            а почему только в два раза, а не в 15, как в санспайдере? по идее то должен полностью вырезатся цикл for (var i = 0; i < 1000000; i++) {}, который не несет смысловой нагрузки.
            • –3
              Нет, Вы это серьезно? Цикл до миллиона и вложенные циклы до тысячи сравниваете с пятнадцатью прогонами цикла до двенадцати?

              Но в принципе, я уже все понял — «evil M$$$$ do evil thingz 'koz itz evil»
              Удачи в срывании покровов
              Без меня
              • +2
                А какая разница, сколько итераций? Если «code elimination optimizations look for code that has no effect on a running program, and removes the code from the program», то тест вообще должен выполниться мгновенно, т.к. весь цикл до миллиона был бы вырезан (т.к. он «has no effect on a running program»), и осталось бы только

                <html><body>
                <script language="Javascript">
                	var start = new Date();
                	alert(new Date() - start);
                </script>
                </body></html>
                

                :)
                • 0
                  Про количество итераций спросил мой многоуважаемый оппонент. В данном случае, как видно код опять же был элиминирован не полностью, что не помешало ему прийти к финишу в 2.5 быстрее беты хрома.
                  • 0
                    Насколько я вижу, Ваш оппонент как раз спросил, почему не вырезался пустой цикл с миллионом итераций.

                    Да, кстати, вот Вы выше по треду замечали
                    Чтоб проверить «натасканность» оптимизатор конкретно на санспайдер, а не на часто используемые конструкции итерации от нуля до верхнего предела, простых условий и арифметических операций нужно добавлять ИМЕННО дополнительные простые условия, итерации и арифметику.

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

                    Принимая во внимание Вами же озвученный результат «IE PP7 — 30542», какое Вы сделаете заключение: ИЕ натаскан конкретно на санспайдер или на часто используемые конструкции? ;)
                    • –1
                      Ваш оппонент как раз спросил, почему не вырезался пустой цикл с миллионом итераций
                      Ебать…
                      Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.
                      • +2
                        Ну и?

                        Ранее товарищ amirul ссылался на редко встречающиеся конструкции, на которые проверять, мол, нецелесообразно, и предлагал использовать «итерации от нуля до верхнего предела, простые условия и арифметических операции», и что, мол, оптимизатор заточен именно на них.
                        Вуаля: тест, который использует только указанные конструкции, не оптимизируется (иначе мёртвый цикл был бы вырезан и осталась бы мгновенная операция, а не 30-секундная молотилка впустую).
                    • 0
                      Этот «великолепный тест» показывает что оптимизация работает не только на санспайдере. Просто в каких то случаях шаблоны находятся лучше, в каких то хуже.

                      Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию. Выберите один из пунктов:
                      1. Оптимизатор IE9 несовершенен и не выполняет всех оптимизаций, которые можно было бы выполнить, если бы не наличие жестких ограничений на время анализа.
                      2. Оптимизатор IE9 заточен под прохождение SunSpider, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
                      • +2
                        Вернее даже так:
                        2. Оптимизатор IE9 заточен под прохождение одного из подтестов SunSpider исключительно для получения преимущества в 20-30 миллисекунд, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
                      • 0
                        Демагогия, Сужение пространства выбора
                        Достаточно распространённый приём, основанный на искусственном сведении всего набора возможных вариантов действий или рассуждений к минимальному набору альтернатив, любая из которых или наверняка будет отвергнута оппонентом, или устраивает говорящего.
                        • –2
                          Демагогия путем копипаста статьи о демагогии из вики —
                          < Придумайте определение сами >
                      • –1
                        Раз уж вы предлагаете такие категоричные пункты, то я предложу еще один:
                        Оптимизатор IE9 не просто несовершенен, а является говном, ибо может принять живой код за мёртвый, и выбросить его. Это является следствием непонимания разработчиками IE9 динамической природы языка, что в свою очередь является подтверждением общеизвестного факта, что IE пишут говнокодеры.

                        Польза от DCE в динамических языках, и в js в частности, весьма сомнительна. Что толку от браузера, который успешно проходит тесты, но не работает на реальном коде? Написать же тест, для проверки корректности DCE проблематично, т.к. невозможно предугадать все виды ошибок, которые могли допустить разработчики IE.

                        Насчёт «M$$$ всегда врёт» — нет ничего удивительного в том, что первое что пришло многим в голову, это то, что майкрософт заточил IE под тест. Предвзятое отношение к майкрософту вполне оправданно, т.к. их не раз уличали в подтасовке фактов (к примеру, таблица сравнения браузеров до сих пор висит на их сайте).
                      • +1
                        >Этот «великолепный тест» показывает что оптимизация работает не только на санспайдере.

                        Извините, я на всякий случай уточню: мы имеем тест, на котором браузер полминуты молотит впустую там, где по идее должен выкинуть мёртвый ненужный цикл (в котором нет ничего, кроме итераций от нуля до верхнего предела, простых условий и арифметики — т.е. содержит ровно те конструкции, за которые Вы так ратовали где-то наверху и давили на то, что он заточен на них, а не конкретно на санспайдер), верно? И из этого теста Вы как-то умудряетесь сделать вывод, что «этот тест показывает, что оптимизация работает не только на санспайдере» (при том, что мёртвый код явно не выкинут)?

                        >Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию.

                        Учитывая предыдущий абзац я, пожалуй, воздержусь от продолжения разговора.
                • +1
                  А, прошу прощения, неверно прочитал цифру. Мой многоуважаемый оппонент, со всей очевидностью просто уже на нашел к чему придраться поэтому начал придираться к тому что оптимизация не полная. Причем не понимая очевидного контраргумента, что раз уж «специально заточенная под санспайдер» оптимизация не работает в реальной жизни, то почему код исполнился в 2.5 раз быстрее, а не в 1.5 раза медленее, как «должно быть»?
                  • +1
                    и ответить хотется, но уже как-бы пообещали не отвечать («Удачи в срывании покровов. Без меня»), потому ответили Mezomish про меня, будто меня тут нет. Я таким не занимался уже в классе восьмом. Если не раньше. Низко, очень низко.
                    Я вам задал прямой вопрос — ответьте на него, в чем фейл?
              • +3
                чем-то завоняло. толи вы слепой, толи вы притворяетесь слепым (евангелист).
                я не спорю, что на каких-то тестах ие может быть в два раза быстрее хрома. Еще раз посмотрите результаты. Видите разницу в пятнадцать раз?
                cordic: 1.0ms ± 0.0%
                cordic-with-return: 15.4ms ± 2.4%
                cordic-with-true: 14.2ms ± 3.2%


                Это объясняется вами и другими фанатами МС, что просто цикл вырезался. И вы приводите как пример такой оптимизации то, что вы показали. Итак два вопроса

                1. Если оптимизация произошла и отрабатывающий впустую миллионный цикл был вырезан как мёртвый код (вы все это утверждаете уже второй топик подряд, так ведь?) — так какого хрена оно выполнялось так долго?
                var start = new Date(); 
                // Тут цикла нет
                alert(new Date() - start);
                


                2. Если оптимизация не произошла и цикл остался на месте снова вопрос — почему в тестах от сансайдера все вырезается, а вашем тесте — не вырезалось?

          • 0
            Кстати, на своей рабочей машине поставил pp7, запустил .../driver.html и увидел… одинаковое время выполнения у всех cordic (+- погрешность, есстественно). В шоке тыкнул Run Again и тут уже всё «как положенно» стало, обидно до ужаса стало что не сохранил ни ссылку ни скриншот. Попробовал повторить на соседней машине с записью видео — не получилось (м.б. рендер оттормозил и оптимизатор успел отработать?...). Как «сбросить» кеш оптимизатора пока не нашел.
  • 0
    интересно как сделать так чтобы поиск и удаление таких кусков не был затратнее чем выполнять этот самый мертвый код ))))))
    • –3
      На мой взгляд если Настоящие специалисты из эпл, гугл, фаерфокс и опера этим не занимаются, значит тому есть причина, сомнительно что команда разрабов ИЕ вдруг сделает с нуля что-то лучше. Хоть это и возможно но, ИМХО, крайне невероятно…
      • +1
        почему же с нуля? у них есть vcc и куча специалистов в теме. в отличие от…
        • 0
          Ну, предыдущие опыты говорят сами за себя, и я не забыл написать имхо, потому не понимаю минусующих)
          • +2
            не понимаю минусующих
            Имху вы написали, «я в домике» забыли.
        • 0
          конечно же, в microsoft кого попало берут с улицы, нет там Настоящих разработчиков.Как дети, ей богу.
          • 0
            ты к чему это?
    • –1
      Я вообще не считаю определение мертвого кода в исполняемых скриптах чем-то полезным. Да, тесты проходятся быстрее, но лучше проблему решать с другого конца.

      В средствах разработки браузера анализ на предмет мертвого кода был бы очень полезен. Это позволило бы разработчикам избавляться от него сразу, а не оставлять эту задачу браузерам пользователей.
      • 0
        это давняя история, что браузеры должны «забивать» на ошибки горепрограммистов, исправлять их и разгребать tag-soup. ведь главная основа веба — сайт может сделать любая домохозяйка
        • 0
          Возможно, вы правы.
          Но тем не менее, в любом проекте больше чем из одного *.js файла начинают появляться куски устаревшего кода, который не используется или не делает ничего полезного. Это не значит, что их нужно тут же вычищать, но было бы очень приятно, если бы браузер их показывал.
          • 0
            Не используется сейчас, но может быть использован завтра. Некоторый код написан на вырост. Некоторый ждет своего времени.

            А вот код, который ничего не делает… а у кого в реальном проекте есть такой?
            • 0
              Достаточно часто такое видел, когда проект делается несколькими людьми.
              Как обычно это происходит:
              — два человека делают разные фичи, но для реализации этих вещей нужна какая-нибудь вспомогательная функция, котрой пока нет
              — так как работа делается параллельно, появляется две почти что одинаковых функции
              — это все замечает один из программистов и переписывает код так, чтобы обе фичи использовали одну функцию. А вот другую не удаляет, так как не в курсе, используется ли она где-нибудь еще. Решает, что посмотрит потом.
              — «потом» наступает только при рефакторинге

              Согласен, это ошибка человека, но такое бывает часто, особенно на ранних этапах разработки. Если рефакторинг не проводить достаточно часто, мертвый код доживет до тех пор, когда проект уже вырастет, а то и до релиза.
  • +8
    Ну то есть они честно признались что тесты, на которых IE показал себя хорошо для сравнение производительности не подходят.
    • +8
      Шикарно! :)

      Что интересно, что вариации этого теста с разворотом счётчика for приводят к тому, что IE отрабатывает в 4 раза медленнее Хрома.
  • +1
    Данные оптимизации относительно новы в мире исполняющих сред Javascript, хотя в реальных приложениях достаточно много «мертвого» кода.
    Разработчики довольно часто пишут «мертвый» код, не подозревая об этом, и могут полагаться, что компиляторы оптимизируют код.

    специально сходил проверить так ли написано в оригинальной статье, и действительно, почти так (с той разницей что, «many examples» это не «достаточно много»)

    These optimizations are relatively new to the world of Javascript runtimes even though there are many examples of dead code in real-world Javascript on the Web.
    Developers often write dead code without knowing it and can rely on compilers to optimize the code


    Я может быть чего-то не понимаю, но какой разработчик реального приложения в здравом уме будет писать код, который ничего не делает?
    • 0
      Копипаст не забудьте.
      Плюс в реальных приложениях типа магазинов js-код часто генерируется движком магазина по шаблону, с подстановкой допустим значений переменных из базы. В итоге может получится что-то вроде
      skidka = 0;
      .... // blablabla
      if(skidka>0) ... //показать слово "СКИДКА!!!"
      • 0
        Ну тогда понятно, все усилия брошены на оптимизацию Ынтырпрайз автогенерируемого кода :)
      • –1
        Почему бы определение мертвого кода не производить по требованию из консоли? Если в IE9 при просмотре скриптов подсвечивается мертвый код — тогда они действительно делали все это нельзя.
        А вот если браузер просто оптимизирует скрипты и молчит в тряпочку — бесполезная фича.
  • –1
    IE9 еще не вышел, а костыли под него уже появляются)
    • +3
      скорее, ИЕ выходит на костылях))
  • +7
    То есть вставленная посреди метода строка «true;» добавляла методу «side-effect» и этот код переставал быть «мертвым»? Смешно, да. :-)
    • +17
      Вот что true животворящий делает!!!
    • –2
      Т.е. от float: left значение марджинга удваивается? Обоссака :))
      • –2
        с каких пор ты стал евангелистом Микрософт?
  • +3
    Насколько я понимаю они вместо оптимизатора сделали парсер, который умеет «оптимизировать» несколько конкретных видов кода, которые есть в сан спайдере.

    Какой то маразм. Майкрософт в своем репертуаре блин, только начинаешь было думать, что может быть они начнут исправляться, как… >_<
  • НЛО прилетело и опубликовало эту надпись здесь
    • +7
      Это уже эпично :)

      Мало того, что dead code optimization заточен под операции в тесте sunspider (если поменять > на <=, то это уже отменяет оптимизацию), так он вводит целый ряд новых труднообнаружимых ошибок. Это будет реальный гемор у всех разработчиков, кто любит мощь javascript в прототипировании.
    • НЛО прилетело и опубликовало эту надпись здесь
  • –2
    удаление мертвого кода или хотя бы подсветку должна делать среда разработки
    • 0
      Компиляторы это делают в элементарных случаях. Ещё бывают случаи когда надо сделать несколько одинаковых объектов, тогда делается один и копируется нужное количество раз. При этом конструктор будет выполнен один раз (первый раз), а при копировании объекта код конструктора будет «мёртвым» так как он не выполняется при копировании.
  • +4
    Я специально пересмотрел исходники недавних трех проектов и не нашел ни одного места, которое можно было бы считать «мертвым кодом». Действительно ли у многих встречается ситуация циклов, которые ничего не делают, или функций, которые выполняют операции только в локальной области видимости? Я понимаю еще на сервере можно мертвым кодом назвать код, который не участвует в данной генерации страницы, но JS…

    Оптимизация это под конкретный скрипт-тест, или хитрый оптимизатор — IE9 выполняет этот тест быстрее, потому что не выполняет его. Вряд ли это такой уж хороший результат, сомневаюсь, что в реальных условиях эта оптимизация много чего даст.
    • –1
      Мертвого кода много, например, в кривых бенчмарках. Разработчики IE9 верно решили, что если его выкинуть, можно прийти к финишу первыми. И мне не понятно, почему их за это осуждают, а кривые тесты в SunSpider, которые позволяют так делать, нет.
      • НЛО прилетело и опубликовало эту надпись здесь
        • –12
          А еще первыми к финишу можно было прийти, подсчитав заранее все ответы на калькуляторе и в тесте только выводить их на экран. Все равно от этих подсчетов никакой реальной пользы.
          Не передергивай.

          подозрительно странно ведет себя, определяя код санспайдера как «мертвый»
          Это яркий представитель мертвого кода, лежащий на виду. Он запросто мог попасть в внутренние тесты разработчиков, которые проходит анализатор.

          Ведь согласитесь, мало толку от анализатора метвого кода, если он работает только в при каких-то очень ограниченных условиях.
          Platform preview о чем нибудь говорит? Спасибо за баг репорт, ребята будут работать над анализатором дальше.
          • +2
            Багрепорт говорите?
            Поведение нашего JS движка это не «специально подкрученная» оптимизация и это не баг.

            • –4
              Можно я тоже навыдираю слов из контекста и составлю из них предложение?
              TimTowdy
              идиот


              Вот видите! Видите! Вы — идиот.
              • +3
                Заканчивай истерику. Что именно вырвано из контекста? Пост в блогах msdn — это нелепая попытка ответить, почему IE ведёт себя странно при изменении кода в sunspider. Комментарий private_face относится именно к этой ситуации. Контекст не поменялся, поэтому я ничего не выдирал.
                Более того, судя по этому посту, MS прибегает к «грязной» оптимизации — оптимизированный код работает быстро, но некорректно. На тестах эта некорректность не проявляется, в реальных же условиях — может привести к проблемам. Будет очень забавно, если в итоге МС отключит эту оптимизацию, и по тестам IE опять будет проигрывать. Вполне в стиле майкрософта — выиграть тесты с помощью грязных хаков, покричать как можно громче о своей победе, потом втихую отключить хаки, чтоб остальной код работал нормально.
                Как бы там ни было, данная ситуация — это фейл майкрософта, который ваша истерика на хабре не исправит. Раздражает ваш унылый нонкомформизм: все ругают майкрософт, а я повыпендриваюсь и вступлюсь за него.
                • 0
                  Что именно вырвано из контекста?
                  Вы приводите кусок из топика, где утверждается, что «это» не бага в ответ на мой комментарий, где я утверждаю, что «это» бага, и вроде как у читателя это должно вызвать сомнение в моей адекватности.

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

                  потом втихую отключить хаки
                  И закрыть тесты. Или уничтожить, чтобы больше никто не смог их пройти. Или как по вашему они не дадут другим ребятам провести тесты самим после релиза и получить другие результаты?
      • +2
        Не вижу ответа на главный вопрос: почему при добавлении ничего не значащего «return» или «true» код перестаёт быть мёртвым? :)
        • 0
          Хоть матом начинай ругаться. Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.
          • +2
            Блин, ну замените в моём вопросе «быть мёртвым» на «считаться мёртвым» — Вам от этого сильно полегчает? :)

            При оптимизации кода удаление ничего не значащих инструкций — это первое, что должно делаться перед тем, как начинать сколь-нибудь более глубокий анализ кода и смотреть на мёртвые условия, бессмысленные циклы и т.д. Ну вот хоть режьте меня, но при всей моей «любви» к МС я не верю, что этот оптимизатор писали настолько безграмотно. Ну, это как если бы тот же gcc не выкидывал лишние ";" или пустые строки из С++-кода. Смешно? Мне тоже. Имхо, даже студент такого не допустит.

            Не лишайте меня остатков веры в программистов из Редмонда, ну пожа-а-а-алуйста!
            • 0
              Если заменить в вашем вопросе «быть мёртвым» на «считаться мёртвым», то ответ будет таким:
              Без понятия. Скорее всего это ошибка анализатора. А вы не знали, что в программах бывают ошибки?
              • +3
                А Вы прочитали остаток моего сообщения или остановились после прочтения первой строки? :)
                • –3
                  Остановился после прочтения первой строки.
                  Вы не верите.
                  rojer не может себе представить.
                  А TheShock вообще первый канал пошел смотреть.

                  У вас у всех ахуенно УБЕДИТЕЛЬНЫЕ доводы. Вы все очень хорошо разбираетесь в конкретной реализации конкретного этого долбаного анализатора. Вы все ТОЧНО знаете, что там внутри и версии не рассматриваете. Мне нечего делать рядом со столь умными людьми.
                  • +3
                    а ты точно знаешь, что они не врут, белые и пушистые и на самом деле это просто оптимизатор через жопу написан?
                    • –1
                      Я выше написал Я НЕ ЗНАЮ ТОЧНО. Возможны варианты.
                      • +4
                        а почему отстаиваете эту позицию как единственную верную?
                        • –2
                          Да, позиция «возможны варианты» — единственно верная в данном случае, пока кто-то не спиздит сорцов и не покажет, как там на самом деле, или не проведет более детальное исследование. mace вот провел и пришел к выводу, что скорее всего это не заточка под тест.
                          • +1
                            ну он так и не сказал, как тестировал. а другое тестирование утверждает обратное.
                            • –2
                              «Еще живе» прекрасен. Глобальные переменные ни на что не влияют, TheShock.
                              • +4
                                Step объявленна в начале функции, homm
                              • +4
                                Влияет ли на что-нибудь направление прохода цикла, homm? :)
                                • –3
                                  Mezomish, вы задолбали задавать одни и теже вопросы. Цитирую:
                                  Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.


                                  Да, влияет. На поведение анализатора влияет, чер возьми.
                                  • +3
                                    Оптимизатор перестаёт определять, что это тест СанСпайдер?
                                    • 0
                                      Цитирую, опять себя:
                                      Это (данный тест СанСпайдера) яркий представитель мертвого кода, лежащий на виду. Он запросто мог попасть в внутренние тесты разработчиков, которые проходит анализатор.


                                      Никто почему-то даже не посмотрел, как ие справляется с определением мертвого кода на других примерах, никак не связанных с данным тестом (вон, Mezomish хвастает что собаку на этом съел, взял бы да проверил). Все уверены — этот тест единственный, который анализатор срезает.
                                      • 0
                                        >Никто почему-то даже не посмотрел, как ие справляется с определением мертвого кода на других примерах, никак не связанных с данным тестом

                                        А почему «связанность» вдруг может играть какую-то роль для оптимизатора? И как (и главное зачем) он определяет «связанность»?

                                        Вам не кажется, что Вы начинаете играть в свои же ворота? ;)

                                        Товарищ по ссылке (ну, по той, где очень сложные диффы) как раз и решил проверить «как ИЕ справляется с определением мёртвого кода на других примерах». Видимо, ему не пришло в голову, что у ИЕ может быть какая-то особая любовь к СанСпайдеру, и что другие примеры обязательно должны быть непохожи на СанСпайдер, а то ИЕ начинает стесняться оптимизировать у всех на виду.
                                  • +2
                                    >Mezomish, вы задолбали задавать одни и теже вопросы

                                    homm, Вы задолбали твердить одну и ту же фразу, не относящуюся к делу :)

                                    >Да, влияет. На поведение анализатора влияет, чер возьми.

                                    Спасибо, кэп! Но мы и так прекрасно видим, что на поведение данного анализатора может повлиять даже лишняя ";" не в том месте %)
                                    • +3
                                      Кстати, никто не возьмётся протестировать рандомно расставленные ";"? :)
                  • +4
                    Я очень хорошо разбираюсь в общих принципах построения анализаторов, поэтому попытка убедить меня в том, что «конкретно этот долбаный анализатор» допускает ляпы на уровне детского сада, означает одно из двух:
                    1. В анализаторе действительно всё настолько плохо.
                    2. Опровержение от Dean Hachamovitch рассчитано на домохозяек, которые согласно кивают, когда слышат умные слова, более-менее пересекающиеся с теми, которые были в изначальной претензии

                    Я в замешательстве, какой вариант предпочесть в качестве «рабочего».
                    • –2
                      Похоже разбираетесь таки не ОЧЕНЬ хорошо, раз повторяете одно и то же.
                      Несколько фактов:
                      1. Как я уже говорил раньше, для оптимизатора код делится на «совершенно точно мертвый» и «хрен его знает, но для верности будем считать живым».
                      2. Оптимизатор и непосредственно интерпретатор (хоть бы и в виде JIT-компилятора) — это совершенно разные модули с совершенно разной «глубиной понимания» кода.
                      3. Оптимизация динамических языков и яваскрипта в частности — довольно неблагодарное дело.
                      4. Причем оптимизация клиентского яваскрипта — дело, неблагодарное вдвойне, ибо глобальная полноценная оптимизация произведена быть не может (объяснять почему или «очень хорошего понимания» будет достаточно?)
                      5. Оптимизатор распознает наиболее часто встречающиеся шаблоны типа циклов от нуля до верхнего предела с инкрементом переменной, простых условий (типа сравнения переменной с константой), объявлений/присвоений переменных и пр… Любые ТРЮКИ будут сбивать оптимизатор с толку и будет производиться фоллбэк на полное исполнение.
                      • +2
                        Ну, начнём с того, что «очень хорошо» — это была калька с оригинального выражения homm-а (видимо, надо было либо взять в кавычки, либо поставить известный тег). А «повторяю одно и то же» (и, кстати, совсем не одно и то же, а перефразированно — Вам никогда не приходилось так делать?) я исключительно потому, что в некоторых ситуациях, как выясняется, одного раза недостаточно.

                        Что касается пунктов 1...5 — Вы, конечно, правы, но только если рассматривать ситуацию в целом, а не данный конкретный случай (а в данной ветке, напомню, разговор идёт о «true» и «return» в конце тела функции).
                        Разумеется, оптимизация динамических языков — минное поле с расставленными табличками «Здесь мин нет!», но в данном случае дело даже не касается семантики языка — речь ведь идёт о смешных конструкциях типа «true;» или «return;» в конце функции, которые выявляются ещё на этапе синтаксического анализа.
                      • 0
                        Ещё такое замечание: если

                      • +1
                        Да что же это за магический шорткат такой, а… =\

                        Ещё такое замечание: если эта «оптимизация» заключается в простом поиске по очень ограниченному числу шаблонов, то во-первых это опасно (да-да, именно из-за динамической природы языка), а во-вторых не тянет на
                        Dead code elimination optimizations look for code that has no effect on a running program, and removes the code from the program. This has a benefit of both reducing the size of the compiled program in memory and running the program faster.

                        Ибо подобный поиск подразумевает нечто более глубокое, чем банальный поиск шаблонных кусков кода. И если бы этот поиск действительно выполнялся, то и «true», и «return» — отличные образцы как раз того самого «code that has no effect on a running program», причём как сами по себе, так и в составе более сложной конструкции (типа цикла или мёртвого блока).
                        • +2
                          «Нечто более глубокое» будет работать только в случае если компиляция происходит у девелопера (или хотя бы на сервере). Если же пользователю придется ждать десять секунд, чтоб оптимизатор сделал кропотливую глобальную оптимизацию jquery со всеми плагинами, а потом исполнил все это дело за 10 миллисекунд вместо 100 — пользователь не оценит.
                        • +2
                          Ах да, любая оптимизация это поиск по шаблонам. Просто из-за того, что скорость, собственно, оптимизации учитывается в скорости исполнения, нужно сократить количество таких шаблонов до какого нибудь адекватного минимума.
                          • +1
                            Что же это за шаблон такой, что при вставке ничего не значащей инструкции в тело мёртвого цикла цикл перестаёт распознаваться как мёртвый?
                            • +1
                              Вы правда «очень хорошо разбираетесь»?
                              Фишка в том, что для того, чтобы код был элиминирован, нужно чтобы КАЖДАЯ инструкция в блоке 100% не давала сайдэффектов. Конкретно под «true;» шаблона не было, а return — вообще в 99% случаев генерирует сайдэффекты сам по себе и терять время на его проверку, чтоб попытаться соптимизировать тот оставшийся процент — нецелесообразно.

                              Попытка уследить за обновлениями счетчика в каждом теле while — тоже не лучшее место для расходования времени. Обратный цикл — единственное, что действительно стоит добавить, но так уж вышло, что с текущими шаблонами совпадения не произошло.
                              • +1
                                позвольте полюбопытствоваться, а чем отличается для таких целей while от for?
                                • +4
                                  Лучше спросить, чем отличается '>' от '<=' или + от * (пруф)

                                  Судя по статье по ссылке, это quick dirty dead code elimination. Сделан специально для теста. И так как такой поверхностный анализ шаблонами может генерировать гейзенбаги, если начать прототипировать в JS (пруф там же), то его область действия не стали расширять. Чем меньше будет оптимизировать, тем меньше багов сгенерирует, тем лучше. Главное чтобы в тесте работал.
                                  • +3
                                    Т.е. получаем оптимизацию, которая всё равно скорее всего будет выкинута из финального продукта из-за побочных эффектов (по крайней мере хочется надеяться, что будет выкинута), но зато какие красивые циферки в тестах!
                                    Я ничего не перепутал? :)
  • +9
    история 1 в 1 с нвидиа. Которая подменяла шейдер в 3дмарк на свой, заточенный именно под нвидию что давало ей огромное преимущество. Как бы там однозначно ясно что нвидиа сжульничали так и здесь. Мертвый код является частью теста, так-как тест направлен в том числе и на определение того сколько этот мертвый код выполняется. Как видно по таблице ие9 даже срезав половину круга и то струдом приходит первым… А по факту в очередной раз врут. Это как с таблицами поддержки стандартов где у мс 100% а по факту хорошо если 10%
    • 0
      Как бы там однозначно ясно что нвидиа сжульничали так и здесь.

      Извините, может, я не в курсе, но здесь-то причем нвидиа? )
      • НЛО прилетело и опубликовало эту надпись здесь

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