Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 190
Почему я не удивлен?
поясните для идиотовне программистов.
ух, теперь мне понятен масштаб аферы! Спасибо.
Именно так. Сам автор предполагает что IE9 использует методы нахождения мертвого кода. Тем самым отбрасывая части теста. Введение строк «true» и «return» видимо ломает эту логику.
Вообще говоря отсечение мёртвого кода — вполне легальный способ пройти тест.
Тогда добавление новых строк не должно влиять на производительность, ибо код остался мертвым, а значит отсечение неэффективное
Не пройти, а обмануть. Вам сказали, что вы должны пройти тест и пробежать три километра. Вы сели в маршрутку и проехали две трети пути. Вы прошли тест или нет? Формально — да. Фактически — нет. Веб-приложения не будут смотреть на формальные уловки, им нужна фактическая скорость.
Т.е. оптимизация по-вашему — обман? Если есть пустой цикл на 100500 итераций — вполне логично его выкинуть.
а если такой цикл выкидать только в одном определенном скрипте?
Зачем?! Членами померяться на одном единственном скрипте?
да
чтобы так утверждать, нужно иметь весомые аргументы.
пока что видно только не идеальный процесс оптимизации исполнения (никак с sunspider не связанный).
если тест заточен под sunspider, то _любые_ изменения в коде дадут падение производительности, а не именно те, что приведены в статье.
пока что видно только не идеальный процесс оптимизации исполнения (никак с sunspider не связанный).
если тест заточен под sunspider, то _любые_ изменения в коде дадут падение производительности, а не именно те, что приведены в статье.
это всё предположения
в статье приведено две разных палки, о которых ие спотыкается. вы можете взять тест и раскидать ещё палок, и выложить в сеть. тогда и увидим результаты.
в статье приведено две разных палки, о которых ие спотыкается. вы можете взять тест и раскидать ещё палок, и выложить в сеть. тогда и увидим результаты.
Ну, так делала Опера, когда первой прошла Acid2, например. на фоне падающей доли IE любой пиар на руку
А смысл? Будто этот скрипт что-то определяет кроме длины члена на конкретном скрипте.
Особенно популярность браузера, конечно, зависит от этого скрипта, а то что реальный пользователь в реальной жизни иную картину увидит, думаете, всем пофигу?
Особенно популярность браузера, конечно, зависит от этого скрипта, а то что реальный пользователь в реальной жизни иную картину увидит, думаете, всем пофигу?
habrahabr.ru/blogs/browsers/108313/#comment_3428206
если смысла нету — зачем они пишут кучу тестов, снимают кучу видео, кричат на всех углах о скорости?
если смысла нету — зачем они пишут кучу тестов, снимают кучу видео, кричат на всех углах о скорости?
Хвастаться скоростью браузера НА ЛЮБОМ ПРИЛОЖЕНИИ и бороться за нее — это полезно для популярности.
Извращаться с оптимизацией под ОДИН СКРИПТ, известный только гикам и специалистам — бесполезно.
Извращаться с оптимизацией под ОДИН СКРИПТ, известный только гикам и специалистам — бесполезно.
вот только факты нужны. а чтобы были факты нужно прохождение тестов. скорость на хабре — разницу в 20% пользователь не заметит.
а когда браузер пройдёт СанСпайдер — любой менеджер может говорить: «Наш браузер самый быстрый, это доказал тест от Мозиллы».
И наивные пользователи будут этого верить и мучаться
а когда браузер пройдёт СанСпайдер — любой менеджер может говорить: «Наш браузер самый быстрый, это доказал тест от Мозиллы».
И наивные пользователи будут этого верить и мучаться
В одном определённом — «двойная политика». Но если есть механизм определения незначащих участков выполнения — глупо включать её для какого-то одного теста и выключать для всех остальных.
Я склоняюсь к мнению, что непривычный синтаксис (даже в рамках, описанных стандартом) поломал эвристику определения dead code.
Я склоняюсь к мнению, что непривычный синтаксис (даже в рамках, описанных стандартом) поломал эвристику определения dead code.
Не совсем так. Вам сказали добраться до противоположного конца города, а вы вовремя увидели станцию метро и поняли, что незачем идпи пешком. Оптимизация скорости перемещения.
Так что это скорее не мифическая «оптимизация под тест» (зачем такой дурью страдать?), а баг в механизме оптимизации IE — не сумели проанализировать и выполнить код с добавками также хорошо, как без них.
Так что это скорее не мифическая «оптимизация под тест» (зачем такой дурью страдать?), а баг в механизме оптимизации IE — не сумели проанализировать и выполнить код с добавками также хорошо, как без них.
это крайне-крайне спорный аргумент. Вы проводите неверное сравнение и на его основе делаете выводы.
Кстати насчет мертвого кода: насколько хабрасообществу интересна тема о проблеме мертвого кода в веб приложениях? Когда то уже начинал об этом писать, сейчас мог бы продолжить, так как накопилось много нового материала
Речь идёт всего об одном тесте из набора SunSpider. Не обо всех. В этом одном тесте IE9 был быстрее всех остальных в 10 раз. Это показалось странным. Автор изменил код теста — IE9 стал работать медленнее, но всёравно быстрее FireFox(провал с треском по мнению автора топика, это когда быстрее FireFox). Кроме того, тестировался старый Preview 3, это надо учитывать.
Скорее всего в IE была хитрая оптимизация, но не под конкретный тест, а вообще. После изменения кода хитрый алгоритм не сработал.
Скорее всего в IE была хитрая оптимизация, но не под конкретный тест, а вообще. После изменения кода хитрый алгоритм не сработал.
вы так говорите, словно микрософт никогда не делал этих ихних маркетинговых штучек
Preview 6
Total: 32.7ms ± 1.5%
IE 9 Beta
Total: 35.2ms ± 0.9%
разница не большая
Total: 32.7ms ± 1.5%
IE 9 Beta
Total: 35.2ms ± 0.9%
разница не большая
Да что то и программисты требуют пояснений… подробных…
Кэп?
Кэп?
А можно пояснить 1-й diff? я не понял для чего там true; вставили.
Как, я понял, true и return ничего не значат, но уже IE9 ошибается в определении, что это sunspider и не работает оптимизация под этот тест.
Повторный виток «гонки за попугаями», раньше драйвера видеокарт под 3DMark точили, теперь браузеры под бенчмарки точат. Забавно.
А вы не знали? Большинство браузеров с фантастической легкостью проходят тесты ACID3, но вот с остальной поддержкой все не так радужно. То там не те координаты, то не с той стороны обрезается. То вообще ошибка рендеринга, и пол страницы не видно.
Это еще не ясно :)
Во-первых, не факт, что это было задумано наверху. Вполне возможно, что команда, которой поручили оптимизацию, просто забила, а когда подошёл срок сдачи, прикинула, что принимать будут по этим тестам и схитрила.
Во-вторых, фя cordicsincos() — настоящий dead code :) В исходнике она вызывается из цикла, ничего не меняет глобально, ничего не возвращает. Вполне возможно, что это не подгонка под тест, а отсечение такой пустой работы. А эти вставки просто сломали анализатор dead code.
Как линухоид говорю, без исходников трудно сказать в чём причина бага :) Можно только гадать.
Во-первых, не факт, что это было задумано наверху. Вполне возможно, что команда, которой поручили оптимизацию, просто забила, а когда подошёл срок сдачи, прикинула, что принимать будут по этим тестам и схитрила.
Во-вторых, фя cordicsincos() — настоящий dead code :) В исходнике она вызывается из цикла, ничего не меняет глобально, ничего не возвращает. Вполне возможно, что это не подгонка под тест, а отсечение такой пустой работы. А эти вставки просто сломали анализатор dead code.
Как линухоид говорю, без исходников трудно сказать в чём причина бага :) Можно только гадать.
Да и с исходниками непросто, это я как программист говорю :)
В ваших словах есть логика, но как-то очень сомнительно, что простая строка
true; может разубедить анализатор dead code'а в том, что данная функция dead code'ом не является.
ну просто разработчик оптимизатора не думал, что найдется программер, который при здравом уме и трезвой памяти вставит true как оператор
и соответственно не добавил его в таблицу
а вот почему return без значения туда не добавлен не понятно — для некоторых это стиль программирования…
так что реально в чем проблема — хз
ЗЫ я вот умудрился написать код, который быстро работает даже на ie? но жутко тормозит на мозилле
причем сам код выполняется за соизмеримое время(new Date() в начале и конце блока), а потом примерно с минуту огнелис конкретно тупит, загружая проц на 100%
пожалуй буду готовить тестовый пример и отправлять в багзилу
и соответственно не добавил его в таблицу
а вот почему return без значения туда не добавлен не понятно — для некоторых это стиль программирования…
так что реально в чем проблема — хз
ЗЫ я вот умудрился написать код, который быстро работает даже на ie? но жутко тормозит на мозилле
причем сам код выполняется за соизмеримое время(new Date() в начале и конце блока), а потом примерно с минуту огнелис конкретно тупит, загружая проц на 100%
пожалуй буду готовить тестовый пример и отправлять в багзилу
Что за код-то?
Я недавно тоже нашёл баг — если открыть окно и вызвать диалог печати (стандартное, в общем, действие), но два раза подряд, то огнелис молча помирает при закрытии этих окон в 50% случаев.
Я недавно тоже нашёл баг — если открыть окно и вызвать диалог печати (стандартное, в общем, действие), но два раза подряд, то огнелис молча помирает при закрытии этих окон в 50% случаев.
делаю модуль для отрисовки диаграммы ганта
соответственно есть сейчас три колонки с информацией. примерно 4 DIVа
если загоняю порядка трех тысяч строк и делаю для большинства из них display:none а затем display:block (типа сворачивание группы задач), то практически все браузеры отрабатывают скрыть/показать моментально — код выполняется примерно за 0.3-0.6 секунды и потом браузер рендерит гдето в районе секунды
мозилла же рендерит при скрытии гдето секунд 10, а при показе уходит в себя на минуту…
в мозиле 4бета8 это время сократилось до нескольких секунд
ЗЫ независит от линукс или винда
ЗЗЫ заметил что явасрипт в мозилле на линуксе работает несколько медленее чем на винде :(
соответственно есть сейчас три колонки с информацией. примерно 4 DIVа
если загоняю порядка трех тысяч строк и делаю для большинства из них display:none а затем display:block (типа сворачивание группы задач), то практически все браузеры отрабатывают скрыть/показать моментально — код выполняется примерно за 0.3-0.6 секунды и потом браузер рендерит гдето в районе секунды
мозилла же рендерит при скрытии гдето секунд 10, а при показе уходит в себя на минуту…
в мозиле 4бета8 это время сократилось до нескольких секунд
ЗЫ независит от линукс или винда
ЗЗЫ заметил что явасрипт в мозилле на линуксе работает несколько медленее чем на винде :(
Побуду Капитаном.
true возвратит в текущий неймспейс значение true. Только это значение ничему не будет присвоено. То есть интерпретатором JS эта строка будет молниеносно отработана, не вызывая ошибок, и интерпретатор перейдет к следующей строчке. То есть на скорость обработки такого кода эта строка не должна повлиять. Производительность падать не должна.
С return — аналогичная ситуация, return; — возвратит null. Это единственный return в этой функции. То есть функция всегда будет возвращать null. То же будет происходить, если return опустить. Функция без return будет возвращать null. return указывает интерпретатору завершить работу функции и вернуть значение (в данном случае null), а без этой комманды интерпретатор это и так сделает — завершит выполнение и возвратит null, потому что другого значения мы специально не указали.
true возвратит в текущий неймспейс значение true. Только это значение ничему не будет присвоено. То есть интерпретатором JS эта строка будет молниеносно отработана, не вызывая ошибок, и интерпретатор перейдет к следующей строчке. То есть на скорость обработки такого кода эта строка не должна повлиять. Производительность падать не должна.
С return — аналогичная ситуация, return; — возвратит null. Это единственный return в этой функции. То есть функция всегда будет возвращать null. То же будет происходить, если return опустить. Функция без return будет возвращать null. return указывает интерпретатору завершить работу функции и вернуть значение (в данном случае null), а без этой комманды интерпретатор это и так сделает — завершит выполнение и возвратит null, потому что другого значения мы специально не указали.
С return — аналогичная ситуация, return; — возвратит null.Давай поспорим?
alert(typeof (function(){return;})());
Согласен, виноват.
один фиг речь о том, анализатор мертвого кода в этом браузере мертвый, если спотыкается об очевидные вещи.
«Как Вы заставили работать Ваш код так быстро по IE9???? — Я знаю особую некро-кодовую магию.....»
«Как Вы заставили работать Ваш код так быстро по IE9???? — Я знаю особую некро-кодовую магию.....»
В актуальных версиях IE9 этого не наблюдается, автор рассматривал старый preview 3.
в актуальных версиях наблюдается. в последней бете — такая же ситуация
return; и return null; вещи разные изначально
Побуду капитаном и я, dead code elimination работает удаляя все блоки, в которых он может ДОКАЗАТЬ ОТСУТСТВИЕ сайдэффектов. Если в таблицу оптимизатора не добавлена true — она по умолчанию будет считаться имеющей сайдэффекты и не будет элиминирована. Сенсация высосана уж не знаю откуда
Если IE9 корректно определяет код, не делающий полезной работы, то виноват в этом не IE9, а тесты.
То же самое можно наблюдать при прохождении Оперой 10.6 некоторых тестов из набора Dromaeo, в которы она показывает стабильно запредельно высокие результаты, в десятки раз опережающие другие браузеры.
То же самое можно наблюдать при прохождении Оперой 10.6 некоторых тестов из набора Dromaeo, в которы она показывает стабильно запредельно высокие результаты, в десятки раз опережающие другие браузеры.
как по мне, дак «true;» в коде теста аналогичен «nop» или «mov ax,ax» в коде первых метаморфных вирусов…
добавленные true и return никак не должны были повлиять на его производительностьЭто все домыслы. Чтобы сказать наверняка, нужно провести более серьезные исследования.
Это не домыслы а знание языка.
Что? Вы знакомы с реализацией оптимизатора в IE9?
Я знаком со спецификацией яваскрипта. И вижу что все операции операции происходят над объявленными в самой функции переменным и не должны затрагивать ничего снаружи. Я вижу что возвращается undefined в обоих случаях.
Я знаком со спецификацией яваскрипта.А с реализацией оптимизатора в IE9?
И вижу что все операции операции происходят над объявленными в самой функции переменным и не должны затрагивать ничего снаружи. Я вижу что возвращается undefined в обоих случаях.Не нужно говорить очевидных вещей, с этим никто не спорит.
А ничего что код не делает полезной работы в обоих случаях?
Ничего.
Ничего, ведь вы не знаете алгоритм, по которому оптимизатор определяет бесполезность кода. Так как это в любом случае эвристический алгоритм, его может сбить все что угодно.
Принято.
Отсечение ненужного кода — не эвристический алгоритм. Существую давно известные методы, описанные ещё в 80-е годы (см, например, Dragon Book). На самом деле, определение простейших вырожденных инструкций — это первый шаг, который следует предпринимать при оптимизации, поэтому подозрения на читерство вполне обоснованны.
Подозрения вполне обоснованны, но «обман при прихождении» не доказан. Люди ошибаются, может быть как раз «определение простейших вырожденных инструкций» разработчики и не сделали. Имеющихся тестов недостаточно, чтобы сказать точно, заточка это или ошибка анализатора.
Конечно, «true;» выглядит очень странно, но «return;» волне мог сбить с толку анализатор.
Конечно, «true;» выглядит очень странно, но «return;» волне мог сбить с толку анализатор.
Странно делать тесты, код которых не делает никакой полезной работы. Тесты по определению не делают никакой полезной работы кроме как тестирования. Вычисление неких результатов и будет той полезной работой теста.
суть не в том. в ие9 была проведена оптимизация именно под тот код тестов, и добавление одной бессмысленной команды привела не к увеличению времени на какую-то долю процента, а к тому, что ие перестал «узнавать» тест, работал с ним как с обычным кодом, и проваливал его.
это примерно как если вызубрить ответы к экзаменационным билетам не понимая сути вопросов, и ориентироваться по номерам.
а непосредственно перед экзаменом номера билетов изменили (оставив те-же вопросы), и все — тест провален.
это примерно как если вызубрить ответы к экзаменационным билетам не понимая сути вопросов, и ориентироваться по номерам.
а непосредственно перед экзаменом номера билетов изменили (оставив те-же вопросы), и все — тест провален.
Если припомнить, то в и коде вебкита находили костыли для лучшего прохождения acid3.
Надо писать полиморфные тесты, только так можно избежать читерства.
Кстати идея. Полиморфная js сцена вообще существует? Может быть сделать какой-нибудь чудовищный тест с eval'ами, автогенерацией кода, замыканием всего на всё и постоянной подменой функций. Правда наверное jit на таком работать нормально скорее всего не будет. :(
как-то всё очевидно получилось
впрочем, из-за постоянного пиара ие9 мол какой он хороший и вообще чуть ли не лучше всех — баги в нём отыскивать будут с ещё большим упорством, дабы вернуть индусов с небес на место и сказать, что что ИЕ — такое же глючное и кривое rавно
впрочем, из-за постоянного пиара ие9 мол какой он хороший и вообще чуть ли не лучше всех — баги в нём отыскивать будут с ещё большим упорством, дабы вернуть индусов с небес на место и сказать, что что ИЕ — такое же глючное и кривое rавно
Очень неприятно, что создатели браузеров начали пользоваться уловками, похожими на те, которыми когда-то пользовались производители видеокарт.
Вместо того, чтобы пустить свои силы на что-то стоящее, занимаются маркетологической фигнёй.
Действительно, нужны полиморфные тесты уже. Иначе сам смысл каких-либо тестов теряется…
Вместо того, чтобы пустить свои силы на что-то стоящее, занимаются маркетологической фигнёй.
Действительно, нужны полиморфные тесты уже. Иначе сам смысл каких-либо тестов теряется…
IE9 — Обман при прихождении SunSpider JS
Желтее Виктор, еще желтее.
Желтее Виктор, еще желтее.
Клоунадой занимаемся?
но ведь так наверняка и есть!
Объясните, почему на самом деле не так?
Потрудитесь прочесть другие мои комментарии. В частности этот.
Вы утверждаете, что, вероятно, алгоритм ИЕ9 действует вопреки оптимальной логике и поэтому выводы, сделанные на основе предположения об оптимальной логике в ИЕ9 неверны?
Хм… Я готов с этим согласиться. Факт обмана не доказан, но, скорее доказано, что ИЕ9 плохо оптимизирован и его прежний высокий результат — случайность?
Принимается.
Хм… Я готов с этим согласиться. Факт обмана не доказан, но, скорее доказано, что ИЕ9 плохо оптимизирован и его прежний высокий результат — случайность?
Принимается.
Что меня всегда бесило в IE, так это километровое контекстное меню, без возможности получить ссылку на картинку.
А тесты, мне кажется, что каждый производитель браузера что-то где-то да упрощал.
А тесты, мне кажется, что каждый производитель браузера что-то где-то да упрощал.
Во первых, ваша картинка иллюстрирует что «провалился с треском» здесь как раз Firefox.
во вторых, если бы вы потрудились прочитать и понять, то поняли бы что ситуация с «повышенной проходимостью» наблюдается только в одном тесте из набора, а не во всём наборе СанСпайдер, причем автор не говорит что «ИЕ ОПЯТЬ ЗАОПТИМИЗИРОВАЛЕ!!!11 ГАЛАКТИКО ОПАСНОСТЕ!!!11», а просто уточняет этот момент, а чтобы был понятен контекст, надо…
В третьих, надо читать полностью статью чтобы было понятно, что автор говорит о том, что очень многие тесты (без относительно браузера) меряют каких-то абстрактных попугаев, а не реальную производительность, поскольку используют нереалистичные данные и нагрузки.
В четвертых, чтобы остальные могли понять суть, а не только вопить «ОПЯТЬ ЧИТЯТ!!!!1111», вот краткий перевод статьи:
Что эти тесты меряют?
Ответ на этот вопрос сложен. Бенчмарки, такие как эти, должны измерять скорость выполнения ЯваСкрипта, но они часто меряют очень нереалистичные рабочие нагрузки. Для пример, код ниже это весь код теста SunSpider bitwise-and.js:
bitwiseAndValue = 4294967296;
for (var i = 0; i < 600000; i++)
bitwiseAndValue = bitwiseAndValue & i;
Я не уверен, что измерение скорости выполнения этого цикла очень ценно, но Firefox — мировой чемпион в его выполнении.
===кусок про кеширование пропускаю, кому надо — сам прочитает===
Другая пробелема, это то, что многие бенчмарки в действительности ничего не делают, так что они очень предрасположенны к ошибкам. Бенчмарк Google V8 включает тест, названный «splay», который выболняет некоторые операции с расширяющимся деревьями (*перевод по вики). Правда, поскольку он [тест] не используется в настоящей программе, тест имеет несколько проблем. Первое, мы обнаружили, что тест проводит всё своё время [выполнения] конвертируя числа в строки. Позже, мы нашли что бенчмарк добавляет и вставляет ноды в расширяющееся дерево по нереалистичному сценарию. К чести команды V8, они в последнее время быстро исправляют эти проблемы, как только мы их находим. Но всё равно, истинная причина этих проблемм это то, что эти бенчмарки не исполняются в реальной программе.
Mozilla также виновна в написании плохих тестов. Наш набор тестов Dromaeo полон маленьких крошечных циклов и нереалистичных нагрузок.Набор Dromaeo содержал тесты на строки и regex, которые были написаны таким образом, что было лекго использовать одно-элементый кеш для некоторых тестов. (*прим. пер.: не владею контекстом, так что звиняйте)
Одна последняя проблема со слишком большой специализацией под конкретный тест. Когда я запускал вышеупомянутые тесты SunSpider, я обнаружил что ИЕ9 получает счёт который как минимум в десять раз быстрее любого другого браузера в тесте math-cordic. Это был бы впечаталяющий результат, но он не остаётся при небольших вариациях теста. Я сделал два варианта, один с дополнительным «true;» и другой с «return;» Вы можете запустить тесты вместе с оригинальным math-cordic.js тут.
Все три теста должны выдавать примерно одинаковое время, так что если у вас результаты похожи на выше приведённые — это может служить признаком какой-либо проблемы.
во вторых, если бы вы потрудились прочитать и понять, то поняли бы что ситуация с «повышенной проходимостью» наблюдается только в одном тесте из набора, а не во всём наборе СанСпайдер, причем автор не говорит что «ИЕ ОПЯТЬ ЗАОПТИМИЗИРОВАЛЕ!!!11 ГАЛАКТИКО ОПАСНОСТЕ!!!11», а просто уточняет этот момент, а чтобы был понятен контекст, надо…
В третьих, надо читать полностью статью чтобы было понятно, что автор говорит о том, что очень многие тесты (без относительно браузера) меряют каких-то абстрактных попугаев, а не реальную производительность, поскольку используют нереалистичные данные и нагрузки.
В четвертых, чтобы остальные могли понять суть, а не только вопить «ОПЯТЬ ЧИТЯТ!!!!1111», вот краткий перевод статьи:
Что эти тесты меряют?
Ответ на этот вопрос сложен. Бенчмарки, такие как эти, должны измерять скорость выполнения ЯваСкрипта, но они часто меряют очень нереалистичные рабочие нагрузки. Для пример, код ниже это весь код теста SunSpider bitwise-and.js:
bitwiseAndValue = 4294967296;
for (var i = 0; i < 600000; i++)
bitwiseAndValue = bitwiseAndValue & i;
Я не уверен, что измерение скорости выполнения этого цикла очень ценно, но Firefox — мировой чемпион в его выполнении.
===кусок про кеширование пропускаю, кому надо — сам прочитает===
Другая пробелема, это то, что многие бенчмарки в действительности ничего не делают, так что они очень предрасположенны к ошибкам. Бенчмарк Google V8 включает тест, названный «splay», который выболняет некоторые операции с расширяющимся деревьями (*перевод по вики). Правда, поскольку он [тест] не используется в настоящей программе, тест имеет несколько проблем. Первое, мы обнаружили, что тест проводит всё своё время [выполнения] конвертируя числа в строки. Позже, мы нашли что бенчмарк добавляет и вставляет ноды в расширяющееся дерево по нереалистичному сценарию. К чести команды V8, они в последнее время быстро исправляют эти проблемы, как только мы их находим. Но всё равно, истинная причина этих проблемм это то, что эти бенчмарки не исполняются в реальной программе.
Mozilla также виновна в написании плохих тестов. Наш набор тестов Dromaeo полон маленьких крошечных циклов и нереалистичных нагрузок.Набор Dromaeo содержал тесты на строки и regex, которые были написаны таким образом, что было лекго использовать одно-элементый кеш для некоторых тестов. (*прим. пер.: не владею контекстом, так что звиняйте)
Одна последняя проблема со слишком большой специализацией под конкретный тест. Когда я запускал вышеупомянутые тесты SunSpider, я обнаружил что ИЕ9 получает счёт который как минимум в десять раз быстрее любого другого браузера в тесте math-cordic. Это был бы впечаталяющий результат, но он не остаётся при небольших вариациях теста. Я сделал два варианта, один с дополнительным «true;» и другой с «return;» Вы можете запустить тесты вместе с оригинальным math-cordic.js тут.
Все три теста должны выдавать примерно одинаковое время, так что если у вас результаты похожи на выше приведённые — это может служить признаком какой-либо проблемы.
Вот и выросло поколение, которое дальше заголовка не читает.
homm, вы меня огорчаете. Вы умный человек, мне интересно читать ваши статьи и комментарии (только не к этому топику), но в этом топике вы ведёте себя не как профессионал. К чему эти over9000 комментариев? Это похоже на троллинг :((((
Если вы считаете что статья желтая и/или высосана из пальца, напишите свою статью! Многим будет интересно узнать взвешенное, альтернативное мнение. Тем более вы разбираетесь в теме.
Если вы считаете что статья желтая и/или высосана из пальца, напишите свою статью! Многим будет интересно узнать взвешенное, альтернативное мнение. Тем более вы разбираетесь в теме.
Что за бред вы вообще несете? Почему, если я не согласен с автором, я не могу написать об этом в комментариях, а мне нужно писать свою статью? Вам не нравится количество моих комментариев? Проглатите молча или закройте страницу. Вам не нравится что на троллинг я отвечаю тем же, а на нормальные вопросы нормальными доводами? Проглатите молча или закройте страницу.
Согласен с тем что тут Firefox провалился. Но главное тут, то что при измененных тестах IE9 ведет себя совсем иначе чем при тестах без изменений.
А если так себя начнёт вести FF? Это тоже будет «Обман при прохождении SunSpider JS»?
Автор, между прочим, не поленился и запостил в Connect по поводу данной баго-фичи, в весьма цинничной форме, правда, но ему можно.
Автор, между прочим, не поленился и запостил в Connect по поводу данной баго-фичи, в весьма цинничной форме, правда, но ему можно.
Откуда все решили, что они знают, как работает анализатор кода в IE9? Если еще вставка «true;» странна, то return может действительно влиять. Ну сделали оптимизацию по нахождению мертвого кода, но проверить на пустой return забыли, посчитав что раз есть return — значит функция зачем-то нужна. Причем в preview-версии.
Это ж как нужно фанатично ненавидеть IE, чтобы плыть на поводу у таких заранее желтых топиков…
Это ж как нужно фанатично ненавидеть IE, чтобы плыть на поводу у таких заранее желтых топиков…
в последней бете — такая же ситуация
Запустил я эти тесты с изменениями на своей машине:
Хром 7.0.517.44: 50.8 ms
ФФ 3.6.12: 69.6 ms
ІЕ 9 бета: 33.1 ms
ЧЯДНТ?
Хром 7.0.517.44: 50.8 ms
ФФ 3.6.12: 69.6 ms
ІЕ 9 бета: 33.1 ms
ЧЯДНТ?
Кстати, почему в результатах preview 3, если сейчас уже актуальна 6? Сдается мне, что это просто баг в одной из ранних версий IE9, который давно пофиксили.
А почему вы ие9 бету сравнивали с 7мым хромом и 3.6 фаерфоксом, когда для хрома — 8ая версия в бете, а для ФФ — 4ая(где как раз новый движок js`ный)? ;)
Я вообще безотносительно версий других браузеров интересовался. Просто попытался отрепродюсить у себя — не вышло, начал смотреть на версии и вот что очень удивило. В изначальном тесте тоже сравнивалась бета ІЕ с релизными версиями других браузеров.
Тут вопрос в том, что описанные модификации в тесте никак не влияют на текущую версию ІЕ, так что это очень похоже на баг, а не на какую-то оптимизацию.
Тут вопрос в том, что описанные модификации в тесте никак не влияют на текущую версию ІЕ, так что это очень похоже на баг, а не на какую-то оптимизацию.
Firefox JS — это с новым движкомJaegerMonkey, его в 3.6 не было. С хромом, странно что такой результат.
Мы с вами говорим о разных вещах.
Автор статьи по ссылке утверждает, что ІЕ9 оптимизирован под санспайдер. В доказательство этого он приводит один модифицированный тест из набора, на котором 3 предварительная версия браузера работает существенно медленнее, чем на оригинальном коде, хотя всем очевидно, что изменения в коде не должны никак влиять на функциональность теста. На основании этого он утверждает, что разработчики из МС применили оптимизацию под конкретный тест, чем вызывает бурю негодования пользователей Хабрахабра.
На деле же оказывается, что в текущей версии браузера этот финт ушами не работает и она отрабатывает модифицированый тест столь же быстро, сколь и оригинальный. На основании этого я утверждаю, что никакого заговора внутри МС нет и никто ничего не оптимизировал конкретно под санспайдер, а на самом деле это был обычный баг в оптимизаторе движка Javascript в браузере IE9, который, к тому же, давно исправили.
При этом я считаю, что если разработчики использовали санспайдер в качестве одной из метрик произодительности своего браузера в процессе разработки, то ничего плохого в этом нет. ИМХО ну очень глупо предполагать, что в коде IE9 есть условия вроде
Спасибо за внимание.
Автор статьи по ссылке утверждает, что ІЕ9 оптимизирован под санспайдер. В доказательство этого он приводит один модифицированный тест из набора, на котором 3 предварительная версия браузера работает существенно медленнее, чем на оригинальном коде, хотя всем очевидно, что изменения в коде не должны никак влиять на функциональность теста. На основании этого он утверждает, что разработчики из МС применили оптимизацию под конкретный тест, чем вызывает бурю негодования пользователей Хабрахабра.
На деле же оказывается, что в текущей версии браузера этот финт ушами не работает и она отрабатывает модифицированый тест столь же быстро, сколь и оригинальный. На основании этого я утверждаю, что никакого заговора внутри МС нет и никто ничего не оптимизировал конкретно под санспайдер, а на самом деле это был обычный баг в оптимизаторе движка Javascript в браузере IE9, который, к тому же, давно исправили.
При этом я считаю, что если разработчики использовали санспайдер в качестве одной из метрик произодительности своего браузера в процессе разработки, то ничего плохого в этом нет. ИМХО ну очень глупо предполагать, что в коде IE9 есть условия вроде
if(IsSunspider == true) {
// work faster
}
Спасибо за внимание.
>>Автор статьи по ссылке утверждает, что ІЕ9 оптимизирован под санспайдер
Автор по ссылке этого вовсе не утверждает, он лишь говорит что на данном тесте скорость выполнения в ИЕ9 выше в 10 раз, по сравнению с другими браузерами, но при изменении тела скрипта теста производительность падает до аналогичной другим браузерам. Никаких выводов оригинальный автор не делает.
Автор по ссылке этого вовсе не утверждает, он лишь говорит что на данном тесте скорость выполнения в ИЕ9 выше в 10 раз, по сравнению с другими браузерами, но при изменении тела скрипта теста производительность падает до аналогичной другим браузерам. Никаких выводов оригинальный автор не делает.
Ох, извините. Был сбит с толку столь солнечным заголовком этой статьи :)
Автор, кстати, запостил весьма цинничный баг на Коннект:
Performance on the SunSpider math-cordic benchmark is very fast, presumably due to some sort of dead code analysis. However, the analysis seems very fragile or narrow. Simple transformations of the benchmark code seem to prevent the analysis from being applied.
Here are two slight changes to the math-cordic code that seem to defeat the analysis in question:
people.mozilla.com/~sayrer/2010/sunspider/diff1.html
people.mozilla.com/~sayrer/2010/sunspider/diff2.html
A performance test with those two changes, in addition to the original math-cordic file, is here:
people.mozilla.com/~sayrer/2010/sunspider/math-cordic-variations/driver.html
What sorts of code does the analysis work on, other than the exact function included in SunSpider?
Так что ждём чего IE Team ответит =)
Performance on the SunSpider math-cordic benchmark is very fast, presumably due to some sort of dead code analysis. However, the analysis seems very fragile or narrow. Simple transformations of the benchmark code seem to prevent the analysis from being applied.
Here are two slight changes to the math-cordic code that seem to defeat the analysis in question:
people.mozilla.com/~sayrer/2010/sunspider/diff1.html
people.mozilla.com/~sayrer/2010/sunspider/diff2.html
A performance test with those two changes, in addition to the original math-cordic file, is here:
people.mozilla.com/~sayrer/2010/sunspider/math-cordic-variations/driver.html
What sorts of code does the analysis work on, other than the exact function included in SunSpider?
Так что ждём чего IE Team ответит =)
почему бы и нет? только не «work faster», а:
if(IsSunspider == true) {
// get from cache
}
Да, конечно. Вообще весь проект IE9 был изначально начат в МС для того, чтобы надрать всем браузерам задницу в санспайдере. Отличный способ потратить несколько десятков миллионов долларов :)
они постарались надрать всем задницу, вбухали кучу денег, а результат получился достаточно говняный. вот и затыкают дырки, рассчитывая на маркетинговые штучки.
Ага. А в IE9 бета затычку убрали, так как испугались того, что их уличат в этом. Вот только глупые-глупые разработчики не догадались, что борцы за справедливость возьмут и жестоко оттестируют preview 3 полугодичной давности, в которой затычка все еще была. Слушайте, напишите об этом Дэну Брауну — он должен написать про это книгу и обязательно, обязательно снять фильм с Томом Хэнксом в роли вас.
а вы проверяете результат до изменения и после или только один из результатов?
что ИЕ9 возвращает здесь? j.mp/bKdPsG
30.6ms ± 2.3%
а полную можно, пожалуйста?
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 118.9ms ± 5.7%
--------------------------------------------
math: 118.9ms ± 5.7%
cordic: 39.1ms ± 9.5%
cordic-with-return: 40.4ms ± 8.5%
cordic-with-true: 39.4ms ± 6.9%
Пожалуйста:
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 30.6ms ± 2.3%
--------------------------------------------
math: 30.6ms ± 2.3%
cordic: 1.0ms ± 0.0%
cordic-with-return: 15.4ms ± 2.4%
cordic-with-true: 14.2ms ± 3.2%
ВОТ! Об этом и речь! У вас тоже наблюдается такая фигня.
Посмотрите. У меня cordic, cordic-with-return и cordic-with-true выполнились за одно время. А у вас — cordic за 1 мс, а cordic-with-return и cordic-with-true за 15 мс. В 15 раз разница!
Посмотрите. У меня cordic, cordic-with-return и cordic-with-true выполнились за одно время. А у вас — cordic за 1 мс, а cordic-with-return и cordic-with-true за 15 мс. В 15 раз разница!
Гм. Любопытно. Вы одновременно и правы и нет. Все сложнее чем кажется. На первом проходе после перезапуска браузера результат у меня такой:
А на втором вот так:
Вы правы насчет кеша. Но не в том смысле что браузер кеширует результат работы функции! В IE9 есть JIT-компиляция кода, которая работает в фоне, паралельно загрузке страницы. При этом интерпретированный код заменяется откомпилированным на лету. И если он успевает заменить код — то получает результат в 1 мс, а если нет — то в 20. При этом откомпилированный код кешируется, поэтому при втором проходе результат столь сильно отличается. Видимо JIT-компилятор умеет отслеживать участки, которые по его мнению ничего не делают и убирать их из выполнения (так же как поступают, например C++ компиляторы с пустыми циклами или методами, которые работают только с локальными переменными и ничего не возвращают). Куски кода вроде true; или return; вызывают у него определенные сомнения (скорее всего это просто баг) и поэтому он не выбрасывает этот код.
Я даже не знаю, что тут сказать — с одной стороны это супер-фича, с другой — действительно не совсем адекватно оценивать производительность санспайдером, если оптимизатор компилятора может просто выбрасывать некоторые участки кода, видя, что они не меняют глобальные переменные и ничего не возвращают.
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 69.2ms ± 1.2%
--------------------------------------------
math: 69.2ms ± 1.2%
cordic: 22.8ms ± 2.0%
cordic-with-return: 23.4ms ± 2.1%
cordic-with-true: 23.0ms ± 1.5%
А на втором вот так:
============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 31.0ms ± 1.9%
--------------------------------------------
math: 31.0ms ± 1.9%
cordic: 1.0ms ± 0.0%
cordic-with-return: 15.2ms ± 2.0%
cordic-with-true: 14.8ms ± 3.8%
Вы правы насчет кеша. Но не в том смысле что браузер кеширует результат работы функции! В IE9 есть JIT-компиляция кода, которая работает в фоне, паралельно загрузке страницы. При этом интерпретированный код заменяется откомпилированным на лету. И если он успевает заменить код — то получает результат в 1 мс, а если нет — то в 20. При этом откомпилированный код кешируется, поэтому при втором проходе результат столь сильно отличается. Видимо JIT-компилятор умеет отслеживать участки, которые по его мнению ничего не делают и убирать их из выполнения (так же как поступают, например C++ компиляторы с пустыми циклами или методами, которые работают только с локальными переменными и ничего не возвращают). Куски кода вроде true; или return; вызывают у него определенные сомнения (скорее всего это просто баг) и поэтому он не выбрасывает этот код.
Я даже не знаю, что тут сказать — с одной стороны это супер-фича, с другой — действительно не совсем адекватно оценивать производительность санспайдером, если оптимизатор компилятора может просто выбрасывать некоторые участки кода, видя, что они не меняют глобальные переменные и ничего не возвращают.
вы исключаете вариант, что это целевая оптимизация определенного скрипта?
Да, исключаю, потому что это как-то глупо. IE9 — стратегический проект для МС и в общем-то едва ли не последний шанс доказать, что они что-то смыслят в разработке браузеров. Очень глупо завязыватся на один тест.
Я попытался сильно отредактировать его, поменял имена файлов, функций, переменных, но эффект остался. Кроме того, я думаю, что это вполне можно доказать на других примерах. Я постараюсь подумать об этом и возможно даже написать статью на Хабр.
Я попытался сильно отредактировать его, поменял имена файлов, функций, переменных, но эффект остался. Кроме того, я думаю, что это вполне можно доказать на других примерах. Я постараюсь подумать об этом и возможно даже написать статью на Хабр.
какой эффект остался? простите, не понял
Метод без true; или return; отрабатывает за 1 мс, даже если он называется совсем по-другому, в нем используются другие имена переменных и т.п.
вполне возможно, что имена методов игнорируются. что, если несущественно поменять код?
скажем
или даже лучше
В последнем на одно вычисление больше, но оно должно повлиять на результат соврешенно незначительно, но не в 15 раз. NewX потом все равно перезаписывается, потому на сам код такое не повлияет
скажем
for (Step = 0; Step < 12; Step++) {
// =>
for (Step = 12; Step--;) {
или даже лучше
for (Step = 0; Step < 12; Step++) {
// =>
for (i = 12; i--;) {
var NewX = i;
Step = 12 - i;
В последнем на одно вычисление больше, но оно должно повлиять на результат соврешенно незначительно, но не в 15 раз. NewX потом все равно перезаписывается, потому на сам код такое не повлияет
В IE9 есть JIT-компиляция кода, которая работает в фоне
Она есть не только там. И я очень сомневаюсь, что разница в 21мс это «минус время инициализации и парсинга».
Я бы попробовал сделать принципиально другой пример этого теста, т.е. тестировать этот же функционал, но скрипте с другим кодом. Если там эта оптимизация не проявится, то все встанет на свои места.
Она есть не только там. И я очень сомневаюсь, что разница в 21мс это «минус время инициализации и парсинга».
Я бы попробовал сделать принципиально другой пример этого теста, т.е. тестировать этот же функционал, но скрипте с другим кодом. Если там эта оптимизация не проявится, то все встанет на свои места.
Вы невнимательно прочитали. Я писал о том, что браузер возможно вообще выбрасывает функции, если видит, что они никак не взаимодействуют с внешним миром.
Проверьте это. Да и если вы даже и правы, то «true;» никак на это не может повлиять.
Надо читать стандарт Ecmascript. Вполне возможно, что true — это глобальный обьект и компилятор расценивает эту строку как обращение к этому обьекту.
Может не к месту, но
Opera 10.62 показывает одинаковые результаты даже после нескольких повторов.
============================================
RESULTS (means and 95% confidence intervals)
— Total: 27.7ms ± 12.5%
— math: 27.7ms ± 12.5%
cordic: 8.7ms ± 10.3%
cordic-with-return: 10.4ms ± 33.9%
cordic-with-true: 8.6ms ± 5.8%
Opera 10.62 показывает одинаковые результаты даже после нескольких повторов.
============================================
RESULTS (means and 95% confidence intervals)
— Total: 27.7ms ± 12.5%
— math: 27.7ms ± 12.5%
cordic: 8.7ms ± 10.3%
cordic-with-return: 10.4ms ± 33.9%
cordic-with-true: 8.6ms ± 5.8%
А вы думаете они довольны тем, что им приходится предлагать всем установку браузера на выбор? Или довольны падением популярности и доверия к Internet Explorer даже среди крупных корпораций?
Сейчас мера измерения браузера это скорость, если новый IE9 будет не самым быстрым, то все больше и больше людей будут переходить на другие браузеры, поскольку этот фактор в приоритете. Я бы не удивился, если бы они пошли даже на оптимизацию под тест, опера делала такое даже в продакшне под некоторые большие сайты (в browser.js).
Я бы проверил в IE9 скрипт без модификации и скрипт с модификацией и сравнил время, потом попробовал бы вводить другие модификации, не true, а проименовал бы цикл, например. И посмотрел бы на результаты. Если любая модификация увеличивает время выполнения до одного и того же значения, то тут все ясно.
Сейчас мера измерения браузера это скорость, если новый IE9 будет не самым быстрым, то все больше и больше людей будут переходить на другие браузеры, поскольку этот фактор в приоритете. Я бы не удивился, если бы они пошли даже на оптимизацию под тест, опера делала такое даже в продакшне под некоторые большие сайты (в browser.js).
Я бы проверил в IE9 скрипт без модификации и скрипт с модификацией и сравнил время, потом попробовал бы вводить другие модификации, не true, а проименовал бы цикл, например. И посмотрел бы на результаты. Если любая модификация увеличивает время выполнения до одного и того же значения, то тут все ясно.
Preview 6
Total: 32.7ms ± 1.5%
Total: 32.7ms ± 1.5%
опочки, оптимизация оказывается вне закона, срочно нужно исключить оптимизацию в компиляторах, пусть всё работает медленнее, зато чЭсно. тем более понятно же написано, что результат благодаря сильному приросту в одной функции, которая написана неоптимальным образом.
оптимизация вообще и оптимизация под конкретный тест — это разные вещи
Какие ваши доказательства, что это оптимизация под конкретный текст?
Заголовок топика на хабре?
Заголовок топика на хабре?
Ок. Это просто хитрая оптимизация, которая работает, если где-нибудь кто-нибудь не поставит return; или true;. Это сразу рушит хитрый алгоритм определения SunSpider эвристического анализа скрипта.
true — это удивительно, а для return вполне объяснимо.
Дожили… меряются пиТестами какими то, с не понятными для обыкновенных юзеров показателями. Прям как раньше с видео картами… но не суть, лучше бы над совместимостью работали и выработкой общих стандартов, один фиг все эти браузеры бесплатные.
Ну прошёл по ссылке с изменённым тестом. IE9 beta (9.0.7930.16406): 30ms, Fx3.6.12: 51ms. Core i5 750. В чём подвох-то?
Ну как понял чем короче тем и лучше :) то есть чем меньше мс. И получается что на мозиловском тесте мозилу обошли.
Перейдите по j.mp/bKdPsG. Посмотрите разницу выполнения cordic, cordic-with-return и cordic-with-true.
Когда в функции есть шум — она выпонляется вомногократ медленнее
Когда в функции есть шум — она выпонляется вомногократ медленнее
Мне кажется, все тесты фигня… Вот выйдет IE9, попробуют его в деле и каждый сам решит, нормуль или нет… Достаточно 1 досадного глюка с любимым сайтом, чтобы испортить отношение с браузером… в бывает, что может и хуже чем-то, но нравится (раньше у меня такое было с Оперой, понимал, что Фаерфокс как-то получше, расширений больше, но всё равно сидел на Опере… ну, пока Хром не появился)…
Сейчас ситуация уже не как раньше — так или иначе все браузеры работают быстро и разница не очень заметна (какие-то 10% никто не заметит). Каких-то страшных глюков в IE8 нет, в IE9 тем более… Да, вряд ли кто-то его будет особо хвалить, потому как отставание сохраняется, но отворачивать нос и говорить: «Фуу!!!» тоже не стоит.
Сейчас ситуация уже не как раньше — так или иначе все браузеры работают быстро и разница не очень заметна (какие-то 10% никто не заметит). Каких-то страшных глюков в IE8 нет, в IE9 тем более… Да, вряд ли кто-то его будет особо хвалить, потому как отставание сохраняется, но отворачивать нос и говорить: «Фуу!!!» тоже не стоит.
Не все смогут попробовать IE9
А почему?
Так или иначе Windows 7 есть у многих (дома/на работе/на ноуте/дома у друзей), мне кажется, рано или поздно увидят где-нибудь и если будет большой интерес — попробуют, даже если сами всегда привыкли пользоваться, например, Убунтой или вообще Маком с Мак ОС (где по техническим причинам не смогут нормально пользоваться ИЕ) :-)
Мне кажется, тут зависит скорее от желание пробовать что-то новое, это желание есть не у всех… Я не думаю, что многие из нас пересядут с любимого Хрома/Фаерфокса/Оперы на ИЕ9, но уверен, что многим из нас будет любопытно пару раз взглянуть на новый браузер от Майкрософт…
Для тех людей, чья профессиональная деятельность не связана с интернетом, спор вида «какой браузер лучше?» сейчас скорее носит холиварный характер, хотя раньше это действительно было важно уйти с IE6.
Так или иначе Windows 7 есть у многих (дома/на работе/на ноуте/дома у друзей), мне кажется, рано или поздно увидят где-нибудь и если будет большой интерес — попробуют, даже если сами всегда привыкли пользоваться, например, Убунтой или вообще Маком с Мак ОС (где по техническим причинам не смогут нормально пользоваться ИЕ) :-)
Мне кажется, тут зависит скорее от желание пробовать что-то новое, это желание есть не у всех… Я не думаю, что многие из нас пересядут с любимого Хрома/Фаерфокса/Оперы на ИЕ9, но уверен, что многим из нас будет любопытно пару раз взглянуть на новый браузер от Майкрософт…
Для тех людей, чья профессиональная деятельность не связана с интернетом, спор вида «какой браузер лучше?» сейчас скорее носит холиварный характер, хотя раньше это действительно было важно уйти с IE6.
Интересно, чтобы значило true; посреди кода и return из функции ничего??? ф-ия вообще ничего полезного не делает, все переменные локальной видимости… и что хотел сказать автор? что он не разбирается в яваскриптах?
На рисунке написано «lower is better», то есть фаерфокс, судя по иллюстрации, соснул у эксплорера и всех остальных.
Да, кстати. Автор оригинала имел ввиду, что «As you can see, Firefox is making rapid progress here.» то есть по сравнению более старыми версиями, Firefox 4 делает значительные успехи. Если не одно НО… :)
А Майкры по ходу выпустили 7 превьюху windowsteamblog.com/ie/b/ie/archive/2010/11/17/ie-9-platform-preview-7-making-your-web-sites-faster.aspx, и там сказано что и Хром 8 дернули в SunSpider.
пишу в эпичном треде…
Ох уж эти желтые заголовки.
Берем текст приведенного теста.
Сохраняем в файл и скармливаем его гугловскому Closure Compiler
java -jar gcc-20100917.jar --js test.js --js_output_file test.packed.js --formatting PRETTY_PRINT
Получаем код:
Компилятор бы мог сделать большее если бы знал, что функции FIXED, FLOAT, DEG2RAD локальные и больше нигде не используются. Поможем ему и сделаем их локальными для теста, для этого все обернем в функцию:
Опять отдаем компилятору и получаем на выходе:
И это все только безопасные оптимизации. Ежу понятно, что даже то что осталось — это мертвый код. Однако это не однозначно: здесь есть обращение вида c[a], то есть обращение к свойству объекта (обращение к элементу массива, это тоже операция обращения к свойству объекта). На свойстве может быть getter, который мог быть объявлен до или будет объявлен после для прототипа Array (или инстанса), и делать что-то такое, что будет влиять на другие объекты/переменные. Поэтому обращение c[a] просто так (без гарантий) не убрать.
Последний вариант кода, это то что видит (или в идеале должен видеть) интерпретатор при «компиляции» кода. Его он и выполняет. Оптимизаторы стараются минимизировать код, но не всегда это делают правильно.
В случае с IE9, он видимо ошибочно произвел небезопасные оптимизации. При изменении кода часть оптимизаций не срабатывать. Баг видимо содержится в первой части, то есть IE9 старается делать оптимизации там где их не должно быть.
По самому тесту — он написан не верно. В большей степени он должен показывать способность браузера к оптимизации кода. Как видим IE9 с этим справляется не плохо.
Если запустить тест в его конечном виде (пропущенный через оптимизатор), то у меня получилось что на этом тесте IE9 PP7 быстрее Chrome 7 в 2 раза. А если добавить в конец «return b», то всего процентов на 10-15% (в хроме время почти не меняется). Все таки мне верится, что оптимизации в IE производятся исходя из предложенного кода.
Берем текст приведенного теста.
var AG_CONST = 0.6072529350;
function FIXED(X)
{
return X * 65536.0;
}
function FLOAT(X)
{
return X/65536.0;
}
function DEG2RAD(X)
{
return 0.017453 * (X);
}
var Angles = [
FIXED(45.0), FIXED(26.565), FIXED(14.0362), FIXED(7.12502),
FIXED(3.57633), FIXED(1.78991), FIXED(0.895174), FIXED(0.447614),
FIXED(0.223811), FIXED(0.111906), FIXED(0.055953),
FIXED(0.027977)
];
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];
}
}
return;
}
Сохраняем в файл и скармливаем его гугловскому Closure Compiler
java -jar gcc-20100917.jar --js test.js --js_output_file test.packed.js --formatting PRETTY_PRINT
Получаем код:
var AG_CONST = 0.607252935;
function FIXED(a) {
return a * 65536
}
function FLOAT(a) {
return a / 65536
}
function DEG2RAD(a) {
return 0.017453 * a
}
var Angles = [FIXED(45), FIXED(26.565), FIXED(14.0362), FIXED(7.12502), FIXED(3.57633), FIXED(1.78991), FIXED(0.895174), FIXED(0.447614), FIXED(0.223811), FIXED(0.111906), FIXED(0.055953), FIXED(0.027977)];
function cordicsincos() {
var a, c, b;
FIXED(AG_CONST);
a = FIXED(28.027);
for(b = c = 0;b < 12;b++) {
if(a > c) {
c += Angles[b]
}else {
c -= Angles[b]
}
}
}
;
Компилятор бы мог сделать большее если бы знал, что функции FIXED, FLOAT, DEG2RAD локальные и больше нигде не используются. Поможем ему и сделаем их локальными для теста, для этого все обернем в функцию:
var cordicsincos = (function(){
...
return funtion(){
// текст функции cordicsincos
}
})();
Опять отдаем компилятору и получаем на выходе:
var cordicsincos = function() {
var c = [2949120, 1740963.84, 919876.4032, 466945.31072, 234378.36288, 117303.54176, 58666.123264, 29334.831104, 14667.677696, 7333.871616, 3666.935808, 1833.500672];
return function() {
var b, a;
for(a = b = 0;a < 12;a++) {
if(1836777.472 > b) {
b += c[a]
}else {
b -= c[a]
}
}
}
}();
И это все только безопасные оптимизации. Ежу понятно, что даже то что осталось — это мертвый код. Однако это не однозначно: здесь есть обращение вида c[a], то есть обращение к свойству объекта (обращение к элементу массива, это тоже операция обращения к свойству объекта). На свойстве может быть getter, который мог быть объявлен до или будет объявлен после для прототипа Array (или инстанса), и делать что-то такое, что будет влиять на другие объекты/переменные. Поэтому обращение c[a] просто так (без гарантий) не убрать.
Последний вариант кода, это то что видит (или в идеале должен видеть) интерпретатор при «компиляции» кода. Его он и выполняет. Оптимизаторы стараются минимизировать код, но не всегда это делают правильно.
В случае с IE9, он видимо ошибочно произвел небезопасные оптимизации. При изменении кода часть оптимизаций не срабатывать. Баг видимо содержится в первой части, то есть IE9 старается делать оптимизации там где их не должно быть.
По самому тесту — он написан не верно. В большей степени он должен показывать способность браузера к оптимизации кода. Как видим IE9 с этим справляется не плохо.
Если запустить тест в его конечном виде (пропущенный через оптимизатор), то у меня получилось что на этом тесте IE9 PP7 быстрее Chrome 7 в 2 раза. А если добавить в конец «return b», то всего процентов на 10-15% (в хроме время почти не меняется). Все таки мне верится, что оптимизации в IE производятся исходя из предложенного кода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IE9 — Обман при прохождении SunSpider JS?