Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 167
Наш движок Chakra балансирует между качеством кода и временем на анализ и производит лишь наименее затратные и очевидные оптимизации «мертвого» кода.
Наверное баланс был нарушен не в ту сторону, но в текущей версии ie9pp7, измененный и неизменненый код теста выполняются одинаково быстро — видимо допилили.
Дело в том, что инструкция return дает понять, что функция закончила свое выполнение. Без ее присутствия интерпретатору необходимо самому «догадываться» о том, когда функция завершилась. Поэтому явное указание return; ускоряет время отработки скрипта. Этот прием работает не только с IE.
О принципе работы true; я могу только строить догадки (например, эта инструкция ускоряет доступ к объектам через scope chain).
Как бы там ни было:
— заголовок желный;
— инжерены из МС подправили код теста, зная особенности работы своего движка (сжульничали);
Интересные выводы можно сделать из выступления www.youtube.com/watch?v=mHtdZgou0qU, в котором рассказаны способы ускорения своего кода + описание их принципов.
О принципе работы true; я могу только строить догадки (например, эта инструкция ускоряет доступ к объектам через scope chain).
Как бы там ни было:
— заголовок желный;
— инжерены из МС подправили код теста, зная особенности работы своего движка (сжульничали);
Интересные выводы можно сделать из выступления www.youtube.com/watch?v=mHtdZgou0qU, в котором рассказаны способы ускорения своего кода + описание их принципов.
Это известный прием — прогнать много пурги ни о чем, чтобы отвлечь внимание от главного.
Разработчики IE, в основном, из Индии (еще бы, название движка — Чакра). Принципы хардкодинга, уважаемые там известны всем читателям сайтов типа codewtf.
Разработчики IE, в основном, из Индии (еще бы, название движка — Чакра). Принципы хардкодинга, уважаемые там известны всем читателям сайтов типа codewtf.
Ну как же, все просто. В первоначальном тесте все браузеры выполняют этот код, IE не выполняет, по этому на фоне остальных браузеров смотрится особняком. Когда поставили return до цикла, остальные браузеры также не выполняют код, по этому результаты выравниваются, так как остальные браузеры в том же положении, что и в ie.
Почему-то прочитав заголовок, я сразу подумал о всех этих JS-костылях для поддержки IE…
Осталось теперь собрать всех бобров, которые закидали homm'а (и не только) минусами в предыдущем топике и попросить извиниться хотя бы :)
а вы побольше слушайте менеджеров из Микрософта.
я уж скорее репортажу по ОРТ поверю, чем им.
я уж скорее репортажу по ОРТ поверю, чем им.
дак майкрософт этим дал ответ только на вопрос непрограммистов «о чем вообще речь?». ждем ответ для программистов.
По сути-то они ничего не ответили. Рассказали, что такое дед-код и все. А на тему почему строчка true сводит на нет всю оптимизацию — по прежнему непонятно.
ПС Я никого не минусовал, если что) Просто интересно, как же тут все на самом деле.
ПС Я никого не минусовал, если что) Просто интересно, как же тут все на самом деле.
За что, простите? В этом потоке слов нет ни слова о том почему так произошло. Более того, этот поток слов _можно_ понять как — вот в тесте есть кусок кода, мы на него посмотрели глазами — это же синус и косинус! (надо объясниять, что именно глазами — хотел бы я посмотреть на оптимизатор, который по подобному коду в общем виде определит, что это синус-косинус). Да и вообще, посмотрели ещё раз — он бесполезен, поэтому мы его объявили мёртвым (встроили распознавалку именно этого куска кода) и выкидываем. В таком случае абсолютно понятно почему распознавал… «оптимизатор» ломается. :)
Почему он должен ломаться, если всё описанное работает как надо совершенно не понятно по-прежнему.
Почему он должен ломаться, если всё описанное работает как надо совершенно не понятно по-прежнему.
Да потому что лемминговый радикализм зашкаливает последнее время. Хер бы кто полез разбираться в ситуации (начиная от дальнейших экспериментов с изменением кода, заканчивая попыткой проанализировать ситуацию на низком уровне), зато шума было, мать моя женщина. Я не приверженец MS, я ненавижу IE (и не буду пользоваться даже девяткой), но при этом здравый смысл и заданная планка толерантности позволяет хотя бы задуматься перед тем как пулять налево и направо, брызгать слюной.
Вы абсолютно грамотно говорите — «не понятно». А те кто шумели в эпик-треде были блин на 100% уверены, верняк, блябудуmsуроды и т.д.
Я вообще зря влез со своей иронией, ломайте головы дальше. Мир настолько инвариантен, что уууух!
Вы абсолютно грамотно говорите — «не понятно». А те кто шумели в эпик-треде были блин на 100% уверены, верняк, блябудуmsуроды и т.д.
Я вообще зря влез со своей иронией, ломайте головы дальше. Мир настолько инвариантен, что уууух!
Объясните же непонятливому «бобру», каким имеено образом данная статья является опровержением предыдущей? Если выразить общий смысл каждой из статей одним предложением, то получится что-то вроде такого:
Rob Sayre:
Dean Hachamovitch:
Каким образом второе является ответом на первое — моя логика понимать отказывается.
Кстати, если переставить реплики местами, то всё получится :)
Rob Sayre:
— Почему при добавлении ничего не делающих («мёртвых») инструкций ИЕ выполняет тест в разы медленнее?
Dean Hachamovitch:
— Потому что его движок офигенно оптимизирует код и выкидывает мёртвые участки!
Каким образом второе является ответом на первое — моя логика понимать отказывается.
Кстати, если переставить реплики местами, то всё получится :)
Да хрен его знает чем все закончится, в ситуации следует детально разобраться. Просто откуда такая уверенность в ms-обмане берется? Действительно, ситуация выглядит крайне забавно с обеих сторон. Оба варианта развития, на мой взгляд, абсолютно равнозначны. Я допускаю ошибку в «менеджере мертвого кода» (допустим косяк с эвристикой или подсчетом веса блока кода), допускаю использование ряда методик заточенных под конкретно этот тест спайдера и еще с полсотню вариантов :)
PS. Не хотел делать вброс для очередной ругани по теме предыдущего топика.
PS. Не хотел делать вброс для очередной ругани по теме предыдущего топика.
IE обогнал хром? Вот это да!
Если бы еще с поддержкой стандартов было все так же радужно у него.
Если бы еще с поддержкой стандартов было все так же радужно у него.
Дык, тут всё от конфигурации зависит и «плотности» (расширения, плагины) использования. У меня, правда, 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'ы и прочая. Им эти слова ничего не говорят.
Результат такой:
Хромиум 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'ы и прочая. Им эти слова ничего не говорят.
через неделю после релиза ИЕ9 другие браузеры обновятся раз 100500 и вздрючат на всех членомерках
другое дело как дела обстоят в _реальных_ условиях, а не в синтетических тестах
другое дело как дела обстоят в _реальных_ условиях, а не в синтетических тестах
IE обогнал хром? Вот это да!
Хром выполняет мертвый код почти так же быстро, как IE — не выполняет.
интересно работает этот анализатор мёртвого кода.
мёртвый код:
живой код:
ещё живее:
источник.
возможно, какой-то анализатор мёртвого кода в IE9 и встроен, но есть впечатление, что ему слегка «помогли» сработать именно на sun spider.
мёртвый код:
for (Step = 0; Step < 12; Step++) {
...
}
живой код:
for (Step = 12; Step > 0; Step--) {
...
}
ещё живее:
Step = 0;
while(Step < 12) {
...
Step++;
}
источник.
возможно, какой-то анализатор мёртвого кода в IE9 и встроен, но есть впечатление, что ему слегка «помогли» сработать именно на sun spider.
невозможно представить себе оптимизатор, который сработает на фрагменте (1), но не сработает на (2) и (3). все признаки же остаются: локальные переменные, не используемые и не влияющие на глобальное состояние. мне каежется, кому-то в мс очень хотелось написать такой оптимизатор, и видимо они даже что-то написали, т.е. в каких-то случаях код они выкидывать умеют, но, к сожалению, цели — соптимизировать sunspider — он не достиг и ему пришлось «помочь» распознать именно этот, самый важный для пиара, фрагмент.
по мне так — попались, голубчики.
по мне так — попались, голубчики.
ещё живее:Глобальные переменные ни на что не влияют, rojer!
Step = 0;
while(Step < 12) {
…
Step++;
}
Step объявленна в начале ф-ции
Вот оно что. Ну rojer «не сказал, как тестировал».
я не понимаю, почему ты так стараешься выгородить Микрософт при явном фейле (даже если это не обман, то фейл оптимизатора).
Очевидно, что приведенный пример заменяет собой
Очевидно, что приведенный пример заменяет собой
for (Step = 0; Step < 12; Step++) { в исходном. И в исходном Step тоже объявленна в начале.А Вы по ссылке «источник», которую дал roger, сходили, или как обычно? :)
Сходил, там по английски, мне его воспринимать тяжелее, я решил не читать. Вот если бы rojer упомянул, что это не отдельные куски кода, а замена в оригинальном тесте — все было бы ясно без ссылки.
Достаточно посмотреть на diff-ы и на циферки, приведённые после них.
Увлекательнейшее занятие, смотреть diff, особенно когда перед глазами нет исходного файла. Все же по памяти помнят, где какой номер у строки. К теме это не относится, просто решил выразить восхищение подачей материала.
homm, ну это уже совсем ребячество. Скажите, зачем Вам исходный файл и уж тем более номера строки для того, чтобы понять смысл изменения
?
Ладно бы если были диффы на килобайты, но тут-то простые однострочники. Несолидно, 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, ой несолидно…
> невозможно представить
У Вас действительно очень плохая фантазия. А «техническая интуиция» на околонулевом уровне.
Итак,
1. Насколько часто конкретно Вы НА ПРАКТИКЕ используете каждый из трех вариантов?
2. Вам кажется, что оптимизатор клиентского яваскрипта должен проводить полную глобальную оптимизацию всего кода в том числе ловить всякие трюки типа «нестандартного» направления итерации и пустые true?
3. Чтоб проверить «натасканность» оптимизатор конкретно на санспайдер, а не на часто используемые конструкции итерации от нуля до верхнего предела, простых условий и арифметических операций нужно добавлять ИМЕННО дополнительные простые условия, итерации и арифметику.
У Вас действительно очень плохая фантазия. А «техническая интуиция» на околонулевом уровне.
Итак,
1. Насколько часто конкретно Вы НА ПРАКТИКЕ используете каждый из трех вариантов?
2. Вам кажется, что оптимизатор клиентского яваскрипта должен проводить полную глобальную оптимизацию всего кода в том числе ловить всякие трюки типа «нестандартного» направления итерации и пустые true?
3. Чтоб проверить «натасканность» оптимизатор конкретно на санспайдер, а не на часто используемые конструкции итерации от нуля до верхнего предела, простых условий и арифметических операций нужно добавлять ИМЕННО дополнительные простые условия, итерации и арифметику.
нестандартное направление итерации? лично я — всегда, когда направление не имеет смысла. сравните:
Тем более, это быстрее.
for (var i = 0, l = array.length; i < l; i++) {
// vs
for (var i = array.length; i--;) {
Тем более, это быстрее.
for (var i in array)И кстати, на каком основании сделано заключение, что «это быстрее»?
for in — плох для итерации по массивам, так как перебирает и свойства. вообще самый правильный вариант (если не знаете, какое содержимое массива может быть):
заключение сделано на основании личных тестов. хотя оптимизация спичечная, да.
for (var i = 0, l = array.length; i < l; i++) if (i in array) {
заключение сделано на основании личных тестов. хотя оптимизация спичечная, да.
То есть Вы «всегда, когда направление не имеет смысла» не знаете, чего содержится в Ваших массивах? Вообще говоря, «i < array.length» — первый кандидат на оптизацию, потому что используется повсеместно
нет. когда направление не имеет смысла(например, когда надо получить сумму всех чисел в массиве) — я использую
когда я не знаю, что содержится в массивах (там может не быть нескольких элементов) — я(и не только я, в коде Мутулз используется такая же конструкция) использую
Во всех остальных ситуациях (когда направление имеет смысл, но я контролирую содержимое массива) можно использовать такой код:
А вы специально перекрутили слова, или просто не поняли меня?
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++)
А вы специально перекрутили слова, или просто не поняли меня?
Я не перекручивал слова. На вопрос насколько часто Вы используете «обратную» итерацию, Вы ответили всегда, аргументируя это бОльшей скоростью, более очевидный вариант с for in отмели из-за невозможности контроля содержимого массива в общем случае.
И мне все еще интересно, основывается ли использование
вместо не менее очевидного, чем for in
на каких либо реальных тестах, или исключительно на предположении, что любой яваскрипт движок будет вызывать array.length на каждой итерации даже точно зная, что массив не менялся.
И мне все еще интересно, основывается ли использование
for (var i = 0, l = array.length; i < l; i++)вместо не менее очевидного, чем for in
for (var i = 0; i < array.length; i++)на каких либо реальных тестах, или исключительно на предположении, что любой яваскрипт движок будет вызывать array.length на каждой итерации даже точно зная, что массив не менялся.
ну вы опять перекрутили мои слова. точнее вырвали из контекста. ну что вы занимаетесь такими дешевыми вещами?
во-первых, я использую не всегда, а только когда направление не имеет значение.
во-вторых не только из-за скорости, но и из-за читаемости.
На счет последних вопросов — не знаю. Просто поверил подходу MooTools, как уважаемому мной фреймворку. Подозреваю, что они тесты ставили:
во-первых, я использую не всегда, а только когда направление не имеет значение.
во-вторых не только из-за скорости, но и из-за читаемости.
вместо не менее очевидного, чем 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);
}
},
И еще вопрос, проверяли ли Вы как реагирует IE9 на
for (var i = 0, l = array.length; i < l; i++)Ах, да. Раз уж взялись высказывать негодование, потрудитесь ответить и на остальные вопросы.
1. я не высказываю негодование по поводу вашего сообщения и не утверждал, что оно — ложное или правдивое. просто, как опытный разработчик, заметил, что обратный цикл — достаточно частое явление.
2. пустые true могут быть также следствием ошибки. еще стоит взять весь цикл в
3. я бы с удовольствием поставил большую серию тестов, будь у меня IE9. Может, как-то, сделаю это.
2. пустые true могут быть также следствием ошибки. еще стоит взять весь цикл в
if ( 1 ) — такой момент встречается регулярно, например есть в коде phpBB3. я бы с удовольствием поставил большую серию тестов, будь у меня IE9. Может, как-то, сделаю это.
2. Отсутствие оптимизации в результате ошибки — не такая уж большая цена.
3. А мне бы доставило не меньшее удовольствие, если бы ВЫ перестали сначала делать выводы (вернее все «выводы», как я понимаю, давно уже сделаны), а потом искали под них «факты».
3. А мне бы доставило не меньшее удовольствие, если бы ВЫ перестали сначала делать выводы (вернее все «выводы», как я понимаю, давно уже сделаны), а потом искали под них «факты».
Извините, но без исходных кодов любых тестов будет недостаточно.
Пока что тех фактов, что уже есть — достаточно, чтобы сделать предварительные выводы. ИЕ9 не справилась ни с одним из тестов, кроме тех, что в санспайдере по-умолчанию
Пока что тех фактов, что уже есть — достаточно, чтобы сделать предварительные выводы. ИЕ9 не справилась ни с одним из тестов, кроме тех, что в санспайдере по-умолчанию
> ИЕ9 не справилась ни с одним из тестов
Мне так нравится с Вами беседовать. Вы же ТОЛЬКО ЧТО признались, что не выполняли НИ ОДНОГО теста.
Вот, прямо на коленке. Скажите, Вы считаете оптимизацию циклов, условий и арифметики ненужным занятием? А в свете «неизбежной замены толстых клиентов веб приложениями»?
Мне так нравится с Вами беседовать. Вы же ТОЛЬКО ЧТО признались, что не выполняли НИ ОДНОГО теста.
Вот, прямо на коленке. Скажите, Вы считаете оптимизацию циклов, условий и арифметики ненужным занятием? А в свете «неизбежной замены толстых клиентов веб приложениями»?
Вы ошибаетесь. Я признался в этом давным давно
Достойный ответ, бро.
если вы меня поддернули, то как минимум в этой ветке — еще дважды:
habrahabr.ru/blogs/browsers/108355/#comment_3431927
habrahabr.ru/blogs/browsers/108355/#comment_3431879
И еще много, если поискать.
habrahabr.ru/blogs/browsers/108355/#comment_3431927
я — ничего не проверял, о чём уже заявил неоднократно. но много людей, в т.ч. сторонников IE выкладывали свои тесты.
habrahabr.ru/blogs/browsers/108355/#comment_3431879
я бы с удовольствием поставил большую серию тестов, будь у меня IE9. Может, как-то, сделаю это.
И еще много, если поискать.
Нет, ты правда слабоумный? Тебе говорят факты, задают вопросы, а все что ты можешь ответить — «я признался давно, а не только что». Это да, это очень важное замечание в свете данной беседы.
homm, ты очень любишь расставлять ярлыки.
TimTowdy идиотом назвали, меня — слабоумным. Сразу видны аргументы сторонников Микрософта. детсад. Я ответил на первый абзац. А на второй я ответил по ссылке, что дал amirul, бро
TimTowdy идиотом назвали, меня — слабоумным. Сразу видны аргументы сторонников Микрософта. детсад. Я ответил на первый абзац. А на второй я ответил по ссылке, что дал amirul, бро
ты очень любишь расставлять ярлыки.Да вы шо?
вы притворяетесь слепым (евангелист)… написал TheShock.
Это объясняется вами и другими фанатами МС
с каких пор ты стал евангелистом Микрософт?
аргументы сторонников Микрософта
вы считаете ярлыки «сторонник»,«евангелист»,«фанат» и «идиот»,«слабоумный» — одного уровня. евангелист сейчас применяется в достаточно широком смысле. и то, что вы так яро защищаете Микрософт в данном случае вполне можно назвать евангелизмом. Или вы сейчас выступаете не на стороне Микрософт? Вы не сторонники, нет?
так яро защищаете МикрософтТо, что ты слабоумен — очевидный факт. Иначе не объяснить, что наличие другого взгляда ты способен объяснить только приверженностью какому-то лагерю.
я так понимаю, вы — врач. скажите, а какая у меня степень слабоумия? я еще могу ходить сам в туалет и сидеть за компьютером, или мне уже помогают?
сейчас вы выступаете на стороне Микрософт, потому вас вполне можно назвать «Сторонниками Микрософт в этом споре»
то, какое лютое бешенство я вызываю у тебя и у amirul еще раз подтверждает то, как вас задели мои аргументы и что, на самом деле, вам нечем возразить в этом споре.
вы можете и дальше стараться оскорблять меня. умнее от этого вы не станете. и крепости ваши позиции не наберут.
если, кроме того, какие у меня диагнозы — вам сказать нечего, то лучше не говорите.
сейчас вы выступаете на стороне Микрософт, потому вас вполне можно назвать «Сторонниками Микрософт в этом споре»
то, какое лютое бешенство я вызываю у тебя и у amirul еще раз подтверждает то, как вас задели мои аргументы и что, на самом деле, вам нечем возразить в этом споре.
вы можете и дальше стараться оскорблять меня. умнее от этого вы не станете. и крепости ваши позиции не наберут.
если, кроме того, какие у меня диагнозы — вам сказать нечего, то лучше не говорите.
и не надо цеплятся к словам. того, что Микрософт в очередной раз всех постарались наебать и прокололись это не скроет
сейчас вы выступаете на стороне МикрософтУ тебя последняя степень, самая высокая.
на самом деле, вам нечем возразить в этом споре… сказал человек, написавший этот комментарий.
Тяжёлая. Повседневная деятельность настолько нарушена, что требуется постоянный надзор (например, больной не в состоянии выполнять правила личной гигиены, не понимает, что ему говорят и сам не говорит).
На самом деле вы, наверное ошибаетесь. В таком случае я не смог бы с вами общаться даже через посредника.
и если true; или while вместо for встречаются не так часто, то пустой return можно найти в большинстве скриптов.
то есть, вы говорите — майкрософт не подстраивал оптимизатор специально под sun spider, просто они написали такой специальный оптимизатор циклов for, считающих в положительном направлении? это не делает им чести ни разу.
оптимизировать тривильные true, кстати, оптимизатор должен просто по опредлению.
оптимизировать тривильные true, кстати, оптимизатор должен просто по опредлению.
Специально под санспайдер? А по моему специально под циклы, условия и присвоения. Или Вам кажется, что их отимизация не нужна в принципе (как в других движках)?
Вот простейший пример СОВСЕМ НЕ ПОХОЖИЙ на санспайдер:
IE PP7 — 30542
Chrome 8.0.552 — 75235
Вот простейший пример СОВСЕМ НЕ ПОХОЖИЙ на санспайдер:
<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
а почему только в два раза, а не в 15, как в санспайдере? по идее то должен полностью вырезатся цикл
for (var i = 0; i < 1000000; i++) {}, который не несет смысловой нагрузки.Нет, Вы это серьезно? Цикл до миллиона и вложенные циклы до тысячи сравниваете с пятнадцатью прогонами цикла до двенадцати?
Но в принципе, я уже все понял — «evil M$$$$ do evil thingz 'koz itz evil»
Удачи в срывании покровов
Без меня
Но в принципе, я уже все понял — «evil M$$$$ do evil thingz 'koz itz evil»
Удачи в срывании покровов
Без меня
А какая разница, сколько итераций? Если «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>
:)
Про количество итераций спросил мой многоуважаемый оппонент. В данном случае, как видно код опять же был элиминирован не полностью, что не помешало ему прийти к финишу в 2.5 быстрее беты хрома.
Насколько я вижу, Ваш оппонент как раз спросил, почему не вырезался пустой цикл с миллионом итераций.
Да, кстати, вот Вы выше по треду замечали
После этого Вы привели великолепный тест, в котором как раз присутствуют только итерации от нуля до верхнего предела, дополнительные простые условия и арифметика.
Принимая во внимание Вами же озвученный результат «IE PP7 — 30542», какое Вы сделаете заключение: ИЕ натаскан конкретно на санспайдер или на часто используемые конструкции? ;)
Да, кстати, вот Вы выше по треду замечали
Чтоб проверить «натасканность» оптимизатор конкретно на санспайдер, а не на часто используемые конструкции итерации от нуля до верхнего предела, простых условий и арифметических операций нужно добавлять ИМЕННО дополнительные простые условия, итерации и арифметику.
После этого Вы привели великолепный тест, в котором как раз присутствуют только итерации от нуля до верхнего предела, дополнительные простые условия и арифметика.
Принимая во внимание Вами же озвученный результат «IE PP7 — 30542», какое Вы сделаете заключение: ИЕ натаскан конкретно на санспайдер или на часто используемые конструкции? ;)
Ваш оппонент как раз спросил, почему не вырезался пустой цикл с миллионом итерацийЕбать…
Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.
Ну и?
Ранее товарищ amirul ссылался на редко встречающиеся конструкции, на которые проверять, мол, нецелесообразно, и предлагал использовать «итерации от нуля до верхнего предела, простые условия и арифметических операции», и что, мол, оптимизатор заточен именно на них.
Вуаля: тест, который использует только указанные конструкции, не оптимизируется (иначе мёртвый цикл был бы вырезан и осталась бы мгновенная операция, а не 30-секундная молотилка впустую).
Ранее товарищ amirul ссылался на редко встречающиеся конструкции, на которые проверять, мол, нецелесообразно, и предлагал использовать «итерации от нуля до верхнего предела, простые условия и арифметических операции», и что, мол, оптимизатор заточен именно на них.
Вуаля: тест, который использует только указанные конструкции, не оптимизируется (иначе мёртвый цикл был бы вырезан и осталась бы мгновенная операция, а не 30-секундная молотилка впустую).
Этот «великолепный тест» показывает что оптимизация работает не только на санспайдере. Просто в каких то случаях шаблоны находятся лучше, в каких то хуже.
Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию. Выберите один из пунктов:
1. Оптимизатор IE9 несовершенен и не выполняет всех оптимизаций, которые можно было бы выполнить, если бы не наличие жестких ограничений на время анализа.
2. Оптимизатор IE9 заточен под прохождение SunSpider, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию. Выберите один из пунктов:
1. Оптимизатор IE9 несовершенен и не выполняет всех оптимизаций, которые можно было бы выполнить, если бы не наличие жестких ограничений на время анализа.
2. Оптимизатор IE9 заточен под прохождение SunSpider, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
Вернее даже так:
2. Оптимизатор IE9 заточен под прохождение одного из подтестов SunSpider исключительно для получения преимущества в 20-30 миллисекунд, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
2. Оптимизатор IE9 заточен под прохождение одного из подтестов SunSpider исключительно для получения преимущества в 20-30 миллисекунд, ни на чем больше не срабатывает и является ярким подтверждением общеизвестного факта, что M$$$ всегда врет.
Демагогия, Сужение пространства выбора
Достаточно распространённый приём, основанный на искусственном сведении всего набора возможных вариантов действий или рассуждений к минимальному набору альтернатив, любая из которых или наверняка будет отвергнута оппонентом, или устраивает говорящего.
Раз уж вы предлагаете такие категоричные пункты, то я предложу еще один:
Оптимизатор IE9 не просто несовершенен, а является говном, ибо может принять живой код за мёртвый, и выбросить его. Это является следствием непонимания разработчиками IE9 динамической природы языка, что в свою очередь является подтверждением общеизвестного факта, что IE пишут говнокодеры.
Польза от DCE в динамических языках, и в js в частности, весьма сомнительна. Что толку от браузера, который успешно проходит тесты, но не работает на реальном коде? Написать же тест, для проверки корректности DCE проблематично, т.к. невозможно предугадать все виды ошибок, которые могли допустить разработчики IE.
Насчёт «M$$$ всегда врёт» — нет ничего удивительного в том, что первое что пришло многим в голову, это то, что майкрософт заточил IE под тест. Предвзятое отношение к майкрософту вполне оправданно, т.к. их не раз уличали в подтасовке фактов (к примеру, таблица сравнения браузеров до сих пор висит на их сайте).
Оптимизатор IE9 не просто несовершенен, а является говном, ибо может принять живой код за мёртвый, и выбросить его. Это является следствием непонимания разработчиками IE9 динамической природы языка, что в свою очередь является подтверждением общеизвестного факта, что IE пишут говнокодеры.
Польза от DCE в динамических языках, и в js в частности, весьма сомнительна. Что толку от браузера, который успешно проходит тесты, но не работает на реальном коде? Написать же тест, для проверки корректности DCE проблематично, т.к. невозможно предугадать все виды ошибок, которые могли допустить разработчики IE.
Насчёт «M$$$ всегда врёт» — нет ничего удивительного в том, что первое что пришло многим в голову, это то, что майкрософт заточил IE под тест. Предвзятое отношение к майкрософту вполне оправданно, т.к. их не раз уличали в подтасовке фактов (к примеру, таблица сравнения браузеров до сих пор висит на их сайте).
>Этот «великолепный тест» показывает что оптимизация работает не только на санспайдере.
Извините, я на всякий случай уточню: мы имеем тест, на котором браузер полминуты молотит впустую там, где по идее должен выкинуть мёртвый ненужный цикл (в котором нет ничего, кроме итераций от нуля до верхнего предела, простых условий и арифметики — т.е. содержит ровно те конструкции, за которые Вы так ратовали где-то наверху и давили на то, что он заточен на них, а не конкретно на санспайдер), верно? И из этого теста Вы как-то умудряетесь сделать вывод, что «этот тест показывает, что оптимизация работает не только на санспайдере» (при том, что мёртвый код явно не выкинут)?
>Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию.
Учитывая предыдущий абзац я, пожалуй, воздержусь от продолжения разговора.
Извините, я на всякий случай уточню: мы имеем тест, на котором браузер полминуты молотит впустую там, где по идее должен выкинуть мёртвый ненужный цикл (в котором нет ничего, кроме итераций от нуля до верхнего предела, простых условий и арифметики — т.е. содержит ровно те конструкции, за которые Вы так ратовали где-то наверху и давили на то, что он заточен на них, а не конкретно на санспайдер), верно? И из этого теста Вы как-то умудряетесь сделать вывод, что «этот тест показывает, что оптимизация работает не только на санспайдере» (при том, что мёртвый код явно не выкинут)?
>Прежде чем продолжать разговор, я бы все же хотел уточнить Вашу позицию.
Учитывая предыдущий абзац я, пожалуй, воздержусь от продолжения разговора.
А, прошу прощения, неверно прочитал цифру. Мой многоуважаемый оппонент, со всей очевидностью просто уже на нашел к чему придраться поэтому начал придираться к тому что оптимизация не полная. Причем не понимая очевидного контраргумента, что раз уж «специально заточенная под санспайдер» оптимизация не работает в реальной жизни, то почему код исполнился в 2.5 раз быстрее, а не в 1.5 раза медленее, как «должно быть»?
чем-то завоняло. толи вы слепой, толи вы притворяетесь слепым (евангелист).
я не спорю, что на каких-то тестах ие может быть в два раза быстрее хрома. Еще раз посмотрите результаты. Видите разницу в пятнадцать раз?
Это объясняется вами и другими фанатами МС, что просто цикл вырезался. И вы приводите как пример такой оптимизации то, что вы показали. Итак два вопроса
1. Если оптимизация произошла и отрабатывающий впустую миллионный цикл был вырезан как мёртвый код (вы все это утверждаете уже второй топик подряд, так ведь?) — так какого хрена оно выполнялось так долго?
2. Если оптимизация не произошла и цикл остался на месте снова вопрос — почему в тестах от сансайдера все вырезается, а вашем тесте — не вырезалось?
я не спорю, что на каких-то тестах ие может быть в два раза быстрее хрома. Еще раз посмотрите результаты. Видите разницу в пятнадцать раз?
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. Если оптимизация не произошла и цикл остался на месте снова вопрос — почему в тестах от сансайдера все вырезается, а вашем тесте — не вырезалось?
Кстати, на своей рабочей машине поставил pp7, запустил .../driver.html и увидел… одинаковое время выполнения у всех cordic (+- погрешность, есстественно). В шоке тыкнул Run Again и тут уже всё «как положенно» стало, обидно до ужаса стало что не сохранил ни ссылку ни скриншот. Попробовал повторить на соседней машине с записью видео — не получилось (м.б. рендер оттормозил и оптимизатор успел отработать?...). Как «сбросить» кеш оптимизатора пока не нашел.
интересно как сделать так чтобы поиск и удаление таких кусков не был затратнее чем выполнять этот самый мертвый код ))))))
На мой взгляд если Настоящие специалисты из эпл, гугл, фаерфокс и опера этим не занимаются, значит тому есть причина, сомнительно что команда разрабов ИЕ вдруг сделает с нуля что-то лучше. Хоть это и возможно но, ИМХО, крайне невероятно…
Я вообще не считаю определение мертвого кода в исполняемых скриптах чем-то полезным. Да, тесты проходятся быстрее, но лучше проблему решать с другого конца.
В средствах разработки браузера анализ на предмет мертвого кода был бы очень полезен. Это позволило бы разработчикам избавляться от него сразу, а не оставлять эту задачу браузерам пользователей.
В средствах разработки браузера анализ на предмет мертвого кода был бы очень полезен. Это позволило бы разработчикам избавляться от него сразу, а не оставлять эту задачу браузерам пользователей.
это давняя история, что браузеры должны «забивать» на ошибки горепрограммистов, исправлять их и разгребать tag-soup. ведь главная основа веба — сайт может сделать любая домохозяйка
Возможно, вы правы.
Но тем не менее, в любом проекте больше чем из одного *.js файла начинают появляться куски устаревшего кода, который не используется или не делает ничего полезного. Это не значит, что их нужно тут же вычищать, но было бы очень приятно, если бы браузер их показывал.
Но тем не менее, в любом проекте больше чем из одного *.js файла начинают появляться куски устаревшего кода, который не используется или не делает ничего полезного. Это не значит, что их нужно тут же вычищать, но было бы очень приятно, если бы браузер их показывал.
Не используется сейчас, но может быть использован завтра. Некоторый код написан на вырост. Некоторый ждет своего времени.
А вот код, который ничего не делает… а у кого в реальном проекте есть такой?
А вот код, который ничего не делает… а у кого в реальном проекте есть такой?
Достаточно часто такое видел, когда проект делается несколькими людьми.
Как обычно это происходит:
— два человека делают разные фичи, но для реализации этих вещей нужна какая-нибудь вспомогательная функция, котрой пока нет
— так как работа делается параллельно, появляется две почти что одинаковых функции
— это все замечает один из программистов и переписывает код так, чтобы обе фичи использовали одну функцию. А вот другую не удаляет, так как не в курсе, используется ли она где-нибудь еще. Решает, что посмотрит потом.
— «потом» наступает только при рефакторинге
Согласен, это ошибка человека, но такое бывает часто, особенно на ранних этапах разработки. Если рефакторинг не проводить достаточно часто, мертвый код доживет до тех пор, когда проект уже вырастет, а то и до релиза.
Как обычно это происходит:
— два человека делают разные фичи, но для реализации этих вещей нужна какая-нибудь вспомогательная функция, котрой пока нет
— так как работа делается параллельно, появляется две почти что одинаковых функции
— это все замечает один из программистов и переписывает код так, чтобы обе фичи использовали одну функцию. А вот другую не удаляет, так как не в курсе, используется ли она где-нибудь еще. Решает, что посмотрит потом.
— «потом» наступает только при рефакторинге
Согласен, это ошибка человека, но такое бывает часто, особенно на ранних этапах разработки. Если рефакторинг не проводить достаточно часто, мертвый код доживет до тех пор, когда проект уже вырастет, а то и до релиза.
Ну то есть они честно признались что тесты, на которых IE показал себя хорошо для сравнение производительности не подходят.
Копипаст не забудьте.
Плюс в реальных приложениях типа магазинов js-код часто генерируется движком магазина по шаблону, с подстановкой допустим значений переменных из базы. В итоге может получится что-то вроде
Плюс в реальных приложениях типа магазинов js-код часто генерируется движком магазина по шаблону, с подстановкой допустим значений переменных из базы. В итоге может получится что-то вроде
skidka = 0;
.... // blablabla
if(skidka>0) ... //показать слово "СКИДКА!!!"
Почему бы определение мертвого кода не производить по требованию из консоли? Если в IE9 при просмотре скриптов подсвечивается мертвый код — тогда они действительно делали все это нельзя.
А вот если браузер просто оптимизирует скрипты и молчит в тряпочку — бесполезная фича.
А вот если браузер просто оптимизирует скрипты и молчит в тряпочку — бесполезная фича.
IE9 еще не вышел, а костыли под него уже появляются)
То есть вставленная посреди метода строка «true;» добавляла методу «side-effect» и этот код переставал быть «мертвым»? Смешно, да. :-)
Насколько я понимаю они вместо оптимизатора сделали парсер, который умеет «оптимизировать» несколько конкретных видов кода, которые есть в сан спайдере.
Какой то маразм. Майкрософт в своем репертуаре блин, только начинаешь было думать, что может быть они начнут исправляться, как… >_<
Какой то маразм. Майкрософт в своем репертуаре блин, только начинаешь было думать, что может быть они начнут исправляться, как… >_<
Это уже эпично :)
Мало того, что dead code optimization заточен под операции в тесте sunspider (если поменять > на <=, то это уже отменяет оптимизацию), так он вводит целый ряд новых труднообнаружимых ошибок. Это будет реальный гемор у всех разработчиков, кто любит мощь javascript в прототипировании.
Мало того, что dead code optimization заточен под операции в тесте sunspider (если поменять > на <=, то это уже отменяет оптимизацию), так он вводит целый ряд новых труднообнаружимых ошибок. Это будет реальный гемор у всех разработчиков, кто любит мощь javascript в прототипировании.
удаление мертвого кода или хотя бы подсветку должна делать среда разработки
Компиляторы это делают в элементарных случаях. Ещё бывают случаи когда надо сделать несколько одинаковых объектов, тогда делается один и копируется нужное количество раз. При этом конструктор будет выполнен один раз (первый раз), а при копировании объекта код конструктора будет «мёртвым» так как он не выполняется при копировании.
Я специально пересмотрел исходники недавних трех проектов и не нашел ни одного места, которое можно было бы считать «мертвым кодом». Действительно ли у многих встречается ситуация циклов, которые ничего не делают, или функций, которые выполняют операции только в локальной области видимости? Я понимаю еще на сервере можно мертвым кодом назвать код, который не участвует в данной генерации страницы, но JS…
Оптимизация это под конкретный скрипт-тест, или хитрый оптимизатор — IE9 выполняет этот тест быстрее, потому что не выполняет его. Вряд ли это такой уж хороший результат, сомневаюсь, что в реальных условиях эта оптимизация много чего даст.
Оптимизация это под конкретный скрипт-тест, или хитрый оптимизатор — IE9 выполняет этот тест быстрее, потому что не выполняет его. Вряд ли это такой уж хороший результат, сомневаюсь, что в реальных условиях эта оптимизация много чего даст.
Мертвого кода много, например, в кривых бенчмарках. Разработчики IE9 верно решили, что если его выкинуть, можно прийти к финишу первыми. И мне не понятно, почему их за это осуждают, а кривые тесты в SunSpider, которые позволяют так делать, нет.
А еще первыми к финишу можно было прийти, подсчитав заранее все ответы на калькуляторе и в тесте только выводить их на экран. Все равно от этих подсчетов никакой реальной пользы.Не передергивай.
подозрительно странно ведет себя, определяя код санспайдера как «мертвый»Это яркий представитель мертвого кода, лежащий на виду. Он запросто мог попасть в внутренние тесты разработчиков, которые проходит анализатор.
Ведь согласитесь, мало толку от анализатора метвого кода, если он работает только в при каких-то очень ограниченных условиях.Platform preview о чем нибудь говорит? Спасибо за баг репорт, ребята будут работать над анализатором дальше.
Багрепорт говорите?
Поведение нашего JS движка это не «специально подкрученная» оптимизация и это не баг.
Можно я тоже навыдираю слов из контекста и составлю из них предложение?
Вот видите! Видите! Вы — идиот.
TimTowdy
идиот
Вот видите! Видите! Вы — идиот.
Заканчивай истерику. Что именно вырвано из контекста? Пост в блогах msdn — это нелепая попытка ответить, почему IE ведёт себя странно при изменении кода в sunspider. Комментарий private_face относится именно к этой ситуации. Контекст не поменялся, поэтому я ничего не выдирал.
Более того, судя по этому посту, MS прибегает к «грязной» оптимизации — оптимизированный код работает быстро, но некорректно. На тестах эта некорректность не проявляется, в реальных же условиях — может привести к проблемам. Будет очень забавно, если в итоге МС отключит эту оптимизацию, и по тестам IE опять будет проигрывать. Вполне в стиле майкрософта — выиграть тесты с помощью грязных хаков, покричать как можно громче о своей победе, потом втихую отключить хаки, чтоб остальной код работал нормально.
Как бы там ни было, данная ситуация — это фейл майкрософта, который ваша истерика на хабре не исправит. Раздражает ваш унылый нонкомформизм: все ругают майкрософт, а я повыпендриваюсь и вступлюсь за него.
Более того, судя по этому посту, MS прибегает к «грязной» оптимизации — оптимизированный код работает быстро, но некорректно. На тестах эта некорректность не проявляется, в реальных же условиях — может привести к проблемам. Будет очень забавно, если в итоге МС отключит эту оптимизацию, и по тестам IE опять будет проигрывать. Вполне в стиле майкрософта — выиграть тесты с помощью грязных хаков, покричать как можно громче о своей победе, потом втихую отключить хаки, чтоб остальной код работал нормально.
Как бы там ни было, данная ситуация — это фейл майкрософта, который ваша истерика на хабре не исправит. Раздражает ваш унылый нонкомформизм: все ругают майкрософт, а я повыпендриваюсь и вступлюсь за него.
Что именно вырвано из контекста?Вы приводите кусок из топика, где утверждается, что «это» не бага в ответ на мой комментарий, где я утверждаю, что «это» бага, и вроде как у читателя это должно вызвать сомнение в моей адекватности.
До только я говорю об изменении поведения анализатора мертвого кода, а разработчики о самом его существовании. Чтобы это не заметить, нудно быть идиотом.
потом втихую отключить хакиИ закрыть тесты. Или уничтожить, чтобы больше никто не смог их пройти. Или как по вашему они не дадут другим ребятам провести тесты самим после релиза и получить другие результаты?
Не вижу ответа на главный вопрос: почему при добавлении ничего не значащего «return» или «true» код перестаёт быть мёртвым? :)
Хоть матом начинай ругаться. Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.
Блин, ну замените в моём вопросе «быть мёртвым» на «считаться мёртвым» — Вам от этого сильно полегчает? :)
При оптимизации кода удаление ничего не значащих инструкций — это первое, что должно делаться перед тем, как начинать сколь-нибудь более глубокий анализ кода и смотреть на мёртвые условия, бессмысленные циклы и т.д. Ну вот хоть режьте меня, но при всей моей «любви» к МС я не верю, что этот оптимизатор писали настолько безграмотно. Ну, это как если бы тот же gcc не выкидывал лишние ";" или пустые строки из С++-кода. Смешно? Мне тоже. Имхо, даже студент такого не допустит.
Не лишайте меня остатков веры в программистов из Редмонда, ну пожа-а-а-алуйста!
При оптимизации кода удаление ничего не значащих инструкций — это первое, что должно делаться перед тем, как начинать сколь-нибудь более глубокий анализ кода и смотреть на мёртвые условия, бессмысленные циклы и т.д. Ну вот хоть режьте меня, но при всей моей «любви» к МС я не верю, что этот оптимизатор писали настолько безграмотно. Ну, это как если бы тот же gcc не выкидывал лишние ";" или пустые строки из С++-кода. Смешно? Мне тоже. Имхо, даже студент такого не допустит.
Не лишайте меня остатков веры в программистов из Редмонда, ну пожа-а-а-алуйста!
Если заменить в вашем вопросе «быть мёртвым» на «считаться мёртвым», то ответ будет таким:
Без понятия. Скорее всего это ошибка анализатора. А вы не знали, что в программах бывают ошибки?
Без понятия. Скорее всего это ошибка анализатора. А вы не знали, что в программах бывают ошибки?
А Вы прочитали остаток моего сообщения или остановились после прочтения первой строки? :)
Остановился после прочтения первой строки.
Вы не верите.
rojer не может себе представить.
А TheShock вообще первый канал пошел смотреть.
У вас у всех ахуенно УБЕДИТЕЛЬНЫЕ доводы. Вы все очень хорошо разбираетесь в конкретной реализации конкретного этого долбаного анализатора. Вы все ТОЧНО знаете, что там внутри и версии не рассматриваете. Мне нечего делать рядом со столь умными людьми.
Вы не верите.
rojer не может себе представить.
А TheShock вообще первый канал пошел смотреть.
У вас у всех ахуенно УБЕДИТЕЛЬНЫЕ доводы. Вы все очень хорошо разбираетесь в конкретной реализации конкретного этого долбаного анализатора. Вы все ТОЧНО знаете, что там внутри и версии не рассматриваете. Мне нечего делать рядом со столь умными людьми.
а ты точно знаешь, что они не врут, белые и пушистые и на самом деле это просто оптимизатор через жопу написан?
Я выше написал Я НЕ ЗНАЮ ТОЧНО. Возможны варианты.
а почему отстаиваете эту позицию как единственную верную?
Да, позиция «возможны варианты» — единственно верная в данном случае, пока кто-то не спиздит сорцов и не покажет, как там на самом деле, или не проведет более детальное исследование. mace вот провел и пришел к выводу, что скорее всего это не заточка под тест.
ну он так и не сказал, как тестировал. а другое тестирование утверждает обратное.
«Еще живе» прекрасен. Глобальные переменные ни на что не влияют, TheShock.
Step объявленна в начале функции, homm
Влияет ли на что-нибудь направление прохода цикла, homm? :)
Mezomish, вы задолбали задавать одни и теже вопросы. Цитирую:
Да, влияет. На поведение анализатора влияет, чер возьми.
Код не перестает быть мертвым, IE9 по каким-то неизвестным причинам перестает его таковым считать.
Да, влияет. На поведение анализатора влияет, чер возьми.
Оптимизатор перестаёт определять, что это тест СанСпайдер?
Цитирую, опять себя:
Никто почему-то даже не посмотрел, как ие справляется с определением мертвого кода на других примерах, никак не связанных с данным тестом (вон, Mezomish хвастает что собаку на этом съел, взял бы да проверил). Все уверены — этот тест единственный, который анализатор срезает.
Это (данный тест СанСпайдера) яркий представитель мертвого кода, лежащий на виду. Он запросто мог попасть в внутренние тесты разработчиков, которые проходит анализатор.
Никто почему-то даже не посмотрел, как ие справляется с определением мертвого кода на других примерах, никак не связанных с данным тестом (вон, Mezomish хвастает что собаку на этом съел, взял бы да проверил). Все уверены — этот тест единственный, который анализатор срезает.
>Никто почему-то даже не посмотрел, как ие справляется с определением мертвого кода на других примерах, никак не связанных с данным тестом
А почему «связанность» вдруг может играть какую-то роль для оптимизатора? И как (и главное зачем) он определяет «связанность»?
Вам не кажется, что Вы начинаете играть в свои же ворота? ;)
Товарищ по ссылке (ну, по той, где очень сложные диффы) как раз и решил проверить «как ИЕ справляется с определением мёртвого кода на других примерах». Видимо, ему не пришло в голову, что у ИЕ может быть какая-то особая любовь к СанСпайдеру, и что другие примеры обязательно должны быть непохожи на СанСпайдер, а то ИЕ начинает стесняться оптимизировать у всех на виду.
А почему «связанность» вдруг может играть какую-то роль для оптимизатора? И как (и главное зачем) он определяет «связанность»?
Вам не кажется, что Вы начинаете играть в свои же ворота? ;)
Товарищ по ссылке (ну, по той, где очень сложные диффы) как раз и решил проверить «как ИЕ справляется с определением мёртвого кода на других примерах». Видимо, ему не пришло в голову, что у ИЕ может быть какая-то особая любовь к СанСпайдеру, и что другие примеры обязательно должны быть непохожи на СанСпайдер, а то ИЕ начинает стесняться оптимизировать у всех на виду.
>Mezomish, вы задолбали задавать одни и теже вопросы
homm, Вы задолбали твердить одну и ту же фразу, не относящуюся к делу :)
>Да, влияет. На поведение анализатора влияет, чер возьми.
Спасибо, кэп! Но мы и так прекрасно видим, что на поведение данного анализатора может повлиять даже лишняя ";" не в том месте %)
homm, Вы задолбали твердить одну и ту же фразу, не относящуюся к делу :)
>Да, влияет. На поведение анализатора влияет, чер возьми.
Спасибо, кэп! Но мы и так прекрасно видим, что на поведение данного анализатора может повлиять даже лишняя ";" не в том месте %)
Я очень хорошо разбираюсь в общих принципах построения анализаторов, поэтому попытка убедить меня в том, что «конкретно этот долбаный анализатор» допускает ляпы на уровне детского сада, означает одно из двух:
1. В анализаторе действительно всё настолько плохо.
2. Опровержение от Dean Hachamovitch рассчитано на домохозяек, которые согласно кивают, когда слышат умные слова, более-менее пересекающиеся с теми, которые были в изначальной претензии
Я в замешательстве, какой вариант предпочесть в качестве «рабочего».
1. В анализаторе действительно всё настолько плохо.
2. Опровержение от Dean Hachamovitch рассчитано на домохозяек, которые согласно кивают, когда слышат умные слова, более-менее пересекающиеся с теми, которые были в изначальной претензии
Я в замешательстве, какой вариант предпочесть в качестве «рабочего».
Похоже разбираетесь таки не ОЧЕНЬ хорошо, раз повторяете одно и то же.
Несколько фактов:
1. Как я уже говорил раньше, для оптимизатора код делится на «совершенно точно мертвый» и «хрен его знает, но для верности будем считать живым».
2. Оптимизатор и непосредственно интерпретатор (хоть бы и в виде JIT-компилятора) — это совершенно разные модули с совершенно разной «глубиной понимания» кода.
3. Оптимизация динамических языков и яваскрипта в частности — довольно неблагодарное дело.
4. Причем оптимизация клиентского яваскрипта — дело, неблагодарное вдвойне, ибо глобальная полноценная оптимизация произведена быть не может (объяснять почему или «очень хорошего понимания» будет достаточно?)
5. Оптимизатор распознает наиболее часто встречающиеся шаблоны типа циклов от нуля до верхнего предела с инкрементом переменной, простых условий (типа сравнения переменной с константой), объявлений/присвоений переменных и пр… Любые ТРЮКИ будут сбивать оптимизатор с толку и будет производиться фоллбэк на полное исполнение.
Несколько фактов:
1. Как я уже говорил раньше, для оптимизатора код делится на «совершенно точно мертвый» и «хрен его знает, но для верности будем считать живым».
2. Оптимизатор и непосредственно интерпретатор (хоть бы и в виде JIT-компилятора) — это совершенно разные модули с совершенно разной «глубиной понимания» кода.
3. Оптимизация динамических языков и яваскрипта в частности — довольно неблагодарное дело.
4. Причем оптимизация клиентского яваскрипта — дело, неблагодарное вдвойне, ибо глобальная полноценная оптимизация произведена быть не может (объяснять почему или «очень хорошего понимания» будет достаточно?)
5. Оптимизатор распознает наиболее часто встречающиеся шаблоны типа циклов от нуля до верхнего предела с инкрементом переменной, простых условий (типа сравнения переменной с константой), объявлений/присвоений переменных и пр… Любые ТРЮКИ будут сбивать оптимизатор с толку и будет производиться фоллбэк на полное исполнение.
Ну, начнём с того, что «очень хорошо» — это была калька с оригинального выражения homm-а (видимо, надо было либо взять в кавычки, либо поставить известный тег). А «повторяю одно и то же» (и, кстати, совсем не одно и то же, а перефразированно — Вам никогда не приходилось так делать?) я исключительно потому, что в некоторых ситуациях, как выясняется, одного раза недостаточно.
Что касается пунктов 1...5 — Вы, конечно, правы, но только если рассматривать ситуацию в целом, а не данный конкретный случай (а в данной ветке, напомню, разговор идёт о «true» и «return» в конце тела функции).
Разумеется, оптимизация динамических языков — минное поле с расставленными табличками «Здесь мин нет!», но в данном случае дело даже не касается семантики языка — речь ведь идёт о смешных конструкциях типа «true;» или «return;» в конце функции, которые выявляются ещё на этапе синтаксического анализа.
Что касается пунктов 1...5 — Вы, конечно, правы, но только если рассматривать ситуацию в целом, а не данный конкретный случай (а в данной ветке, напомню, разговор идёт о «true» и «return» в конце тела функции).
Разумеется, оптимизация динамических языков — минное поле с расставленными табличками «Здесь мин нет!», но в данном случае дело даже не касается семантики языка — речь ведь идёт о смешных конструкциях типа «true;» или «return;» в конце функции, которые выявляются ещё на этапе синтаксического анализа.
Ещё такое замечание: если
Да что же это за магический шорткат такой, а… =\
Ещё такое замечание: если эта «оптимизация» заключается в простом поиске по очень ограниченному числу шаблонов, то во-первых это опасно (да-да, именно из-за динамической природы языка), а во-вторых не тянет на
Ибо подобный поиск подразумевает нечто более глубокое, чем банальный поиск шаблонных кусков кода. И если бы этот поиск действительно выполнялся, то и «true», и «return» — отличные образцы как раз того самого «code that has no effect on a running program», причём как сами по себе, так и в составе более сложной конструкции (типа цикла или мёртвого блока).
Ещё такое замечание: если эта «оптимизация» заключается в простом поиске по очень ограниченному числу шаблонов, то во-первых это опасно (да-да, именно из-за динамической природы языка), а во-вторых не тянет на
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», причём как сами по себе, так и в составе более сложной конструкции (типа цикла или мёртвого блока).
«Нечто более глубокое» будет работать только в случае если компиляция происходит у девелопера (или хотя бы на сервере). Если же пользователю придется ждать десять секунд, чтоб оптимизатор сделал кропотливую глобальную оптимизацию jquery со всеми плагинами, а потом исполнил все это дело за 10 миллисекунд вместо 100 — пользователь не оценит.
Ах да, любая оптимизация это поиск по шаблонам. Просто из-за того, что скорость, собственно, оптимизации учитывается в скорости исполнения, нужно сократить количество таких шаблонов до какого нибудь адекватного минимума.
Что же это за шаблон такой, что при вставке ничего не значащей инструкции в тело мёртвого цикла цикл перестаёт распознаваться как мёртвый?
Вы правда «очень хорошо разбираетесь»?
Фишка в том, что для того, чтобы код был элиминирован, нужно чтобы КАЖДАЯ инструкция в блоке 100% не давала сайдэффектов. Конкретно под «true;» шаблона не было, а return — вообще в 99% случаев генерирует сайдэффекты сам по себе и терять время на его проверку, чтоб попытаться соптимизировать тот оставшийся процент — нецелесообразно.
Попытка уследить за обновлениями счетчика в каждом теле while — тоже не лучшее место для расходования времени. Обратный цикл — единственное, что действительно стоит добавить, но так уж вышло, что с текущими шаблонами совпадения не произошло.
Фишка в том, что для того, чтобы код был элиминирован, нужно чтобы КАЖДАЯ инструкция в блоке 100% не давала сайдэффектов. Конкретно под «true;» шаблона не было, а return — вообще в 99% случаев генерирует сайдэффекты сам по себе и терять время на его проверку, чтоб попытаться соптимизировать тот оставшийся процент — нецелесообразно.
Попытка уследить за обновлениями счетчика в каждом теле while — тоже не лучшее место для расходования времени. Обратный цикл — единственное, что действительно стоит добавить, но так уж вышло, что с текущими шаблонами совпадения не произошло.
позвольте полюбопытствоваться, а чем отличается для таких целей while от for?
Лучше спросить, чем отличается '>' от '<=' или + от * (пруф)
Судя по статье по ссылке, это quick dirty dead code elimination. Сделан специально для теста. И так как такой поверхностный анализ шаблонами может генерировать гейзенбаги, если начать прототипировать в JS (пруф там же), то его область действия не стали расширять. Чем меньше будет оптимизировать, тем меньше багов сгенерирует, тем лучше. Главное чтобы в тесте работал.
Судя по статье по ссылке, это quick dirty dead code elimination. Сделан специально для теста. И так как такой поверхностный анализ шаблонами может генерировать гейзенбаги, если начать прототипировать в JS (пруф там же), то его область действия не стали расширять. Чем меньше будет оптимизировать, тем меньше багов сгенерирует, тем лучше. Главное чтобы в тесте работал.
история 1 в 1 с нвидиа. Которая подменяла шейдер в 3дмарк на свой, заточенный именно под нвидию что давало ей огромное преимущество. Как бы там однозначно ясно что нвидиа сжульничали так и здесь. Мертвый код является частью теста, так-как тест направлен в том числе и на определение того сколько этот мертвый код выполняется. Как видно по таблице ие9 даже срезав половину круга и то струдом приходит первым… А по факту в очередной раз врут. Это как с таблицами поддержки стандартов где у мс 100% а по факту хорошо если 10%
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Избавление от «мертвого» кода в Javascript в IE9