PyPy демонстрирует неточные результаты тестов?

Я работал над Project Euler и задавался вопросом, могу ли я ускорить решение с помощью PyPy. Тем не менее, я нашел результаты довольно разочаровывающими, поскольку для вычисления потребовалось больше времени.

d:\projeuler>pypy problem204.py 3462.08630405 mseconds d:\projeuler>python problem204.py 1823.91602542 mseconds

Поскольку вывод mseconds был рассчитан с использованием модулей time python, поэтому я снова запустил его, используя встроенные контрольные команды.

 d:\projeuler>pypy -mtimeit -s "import problem204" "problem204._main()" 10 loops, best of 3: 465 msec per loop d:\projeuler>python -mtimeit -s "import problem204" "problem204._main()" 10 loops, best of 3: 1.87 sec per loop

PyPy сообщает, что для завершения работы потребовалось около половины секунды. Тем не менее, я попытался запустить pypy problem204 несколько раз, и выходы никогда не приближались к бенчмаркингу .5 секунд. в отличие от pypy, результаты mtimeit python согласуются с результатами. Является ли pypy неточными критериями, или есть какая-то магия, которую я не понимаю?

One Solution collect form web for “PyPy демонстрирует неточные результаты тестов?”

Обратите внимание, что timeit

выполняет несколько раз (10 в вашем случае) и
делает это несколько раз (по умолчанию 3) и дает минимум, по причинам, указанным в документации .

Это зависит от вашего кода, но вполне возможно, что компилятор JIT виноват в этом запутанном результате. Накладные расходы на прогрев JIT возникают каждый раз, когда вы запускаете новый процесс pypy, но только один раз во время теста timeit (потому что один из них работает несколько раз в одном процессе). Более того, если некоторая часть вашего кода запускается так часто, что она не компилируется, когда _main запускается один раз, но только когда она запускается, скажем, три раза, последующие прогоны также будут быстрее, что дополнительно удаляет лучший результат из первого ( т.е. один для запуска pypy problem204.py один раз).

Результат timeit верен тем, что он (примерно) соответствует тому, насколько быстро код будет в лучшем случае – разогретый JIT-компилятор, редко теряющий процессор для других программ и т. Д. Ваша проблема в том, что вы хотите знать что-то другое – время, включая прогрев JIT.