Почему Firefox и другие браузеры работают противоположно при расчете, какое число больше?

Question

Два дня назад, когда я нашел jsperf.com , в котором есть множество тестов производительности JavaScript, я просмотрел несколько тестов.

Один из тестов был это , который сравнивает Math.min(a,b) против a<b?a:b. Когда я запустил этот тест в Google Chrome, оказалось, что a<b?a:b намного быстрее, чем Math.min(a,b) (в Chrome 14 первый 53,661,381 ops/s, второй 419,830,711 ops/s). Другие веб-браузеры имеют похожие результаты.

Однако в Firefox результат противоположен. Math.min(a,b) намного быстрее, чем a<b?a:b! Первый - 374,219,869 ops/s, а второй - 79,490,749 ops/s в Firefox 6.

Когда я разместил это на Facebook, кто-то сказал, что «Поскольку Firefox - это проект с открытым исходным кодом, разработчики оптимизировали Math.min, но Google Chrome - нет, поскольку Google Chrome - всего лишь модификация Chromium», но (помимо этого выше утверждение не совсем верно), что не имеет смысла, потому что это не объясняет причину, по которой Google Chrome a<b?a:b и Firefox Math.min(a,b) работает с одинаковой скоростью, а Google Chrome Math.min(a,b) и Firefox a<b?a:b работают с одинаковой скоростью потому что если Firefox быстрее, чем Google Chrome, то Google Chrome Math.min(a,b) должен быть намного медленнее, чем Firefox a<b?a:b.

Резюме:

1. В других браузерах a<b?a:b быстрее, чем Math.min(a,b).
2. Однако в Firefox Math.min(a,b) быстрее, чем a<b?a:b.
3. Поскольку скорость Math.min(a,b) в Firefox ≒ скорость a<b?a:b в Google Chrome и скорость a<b?a:b в Firefox ≒ скорость Math.min(a,b) в Google Chrome, «Firefox медленный» или «Firefox быстро "не может быть причиной.

Есть ли причина, почему (как) это происходит?

Answer 1

Здесь происходит несколько вещей.

Прежде всего, в Firefox 6 есть два разных JIT-компилятора: TraceMonkey и JaegerMonkey.Какой из них используется для данного бита кода, зависит от некоторой эвристики;эти эвристики имеют тенденцию отдавать предпочтение TraceMonkey для кода с вызовами функций.Бывает так, что для достаточно простого кода TraceMonkey почти всегда быстрее, чем JaegerMonkey;это относится к обоим фрагментам кода, представленным здесь, в частности.

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

Вы можете поэкспериментировать с этим, перейдя к about:config, поместив jit в поле фильтра и отключив один или оба из TraceMonkey (tracejit в списке) и JaegerMonkey(methodjit).Если вы сделаете это, вы увидите, что в этом конкретном тесте тринарный оператор работает быстрее, чем Math.min для каждого из компиляторов в отдельности, поэтому инверсия, которую вы видите по сравнению с другими браузерами, является просто функцией использования различных компиляторов..

Теперь о том, почему Math.min обычно медленнее, чем тринарный оператор ... прежде всего он должен выполнять больше работы;ответы, которые он возвращает, НЕ совпадают с тринарным оператором, если вы тщательно тестируете.Во-вторых, он обычно реализуется как вызов функции, откуда и происходит большая часть накладных расходов (хотя TraceMonkey на самом деле явно указывает это в сгенерированном коде, поэтому производительность двух фрагментов не так уж отличается в TraceMonkey).

Answer 2

У меня возник тот же вопрос после того, как я прочитал: Эффективный Javascript в Dev.Opera и запуск некоторых других тестов.Я думаю, что этот раздел немного вводит в заблуждение.Есть много вещей, которые замедляют Math.min, но ничто из этого не объясняет производительность в Google Chrome по сравнению с Firefox или IE9.

Вещи, которые я думаю, замедляют Math.min

• использование объекта аргументов
• должно проверить, является ли какое-либо значение NaN
• другими вещами, такими как возвращение бесконечности, если аргументы не заданы и +0> -0

Для получения более подробной информации ознакомьтесь с примером http://qfox.nl/ecma/366.

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