Почему Jython ведет себя непоследовательно при тестировании с PyStone?

Question

Я недавно играл с Jython и решил сделать несколько быстрых и грязных сравнений с pystone. Чтобы получить ссылку, я сначала протестировал cPython 2.6 с увеличивающимся числом циклов (я подумал, что это может быть актуально, поскольку Jython должен начать получать прибыль от JIT только через некоторое время).

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 
Pystone(1.1) time for 50000 passes = 1.04
This machine benchmarks at 48076.9 pystones/second

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 500000 
Pystone(1.1) time for 500000 passes = 10.33
This machine benchmarks at 48402.7 pystones/second

(richard garibaldi):/usr/local/src/pybench% python ~/tmp/pystone.py 1000000 
Pystone(1.1) time for 1000000 passes = 19.6
This machine benchmarks at 51020.4 pystones/second

Как видите, cPython ведет себя согласованно: время, необходимое для завершения теста, увеличивается линейно до количества циклов. Зная это, я начал тестировать Jython.

(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 
Pystone(1.1) time for 50000 passes = 2.29807
This machine benchmarks at 21757.4 pystones/second

(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 500000 
Pystone(1.1) time for 500000 passes = 10.931
This machine benchmarks at 45741.4 pystones/second


(richard garibaldi):/usr/local/src/pybench% jython ~/tmp/pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 107.183
This machine benchmarks at 9329.86 pystones/second

Во время первого запуска Jython работает довольно вяло по сравнению со своим братом C. Когда число циклов увеличилось, он начал чувствовать себя лучше, приближаясь к cPython, как и предсказывала моя первоначальная гипотеза. Обратите внимание, что количество циклов увеличилось в 10 раз, но Jython потребовалось всего лишь в 5 раз больше времени для их завершения. Итак, как вы представляете, я ожидал, что Jython действительно будет потрясающим в финальном тесте. Однако, к моему большому разочарованию, все получилось очень плохо: более чем в два раза медленнее, чем при первом запуске.

Каковы ваши гипотезы: почему Jython ведет себя таким противоречивым образом? Может ли быть так, что GC включается в какой-то момент и отнимает много времени? Я посмотрел на код PyStone, и сборка мусора, кажется, не отключена, но я ожидаю, что GC Java будет, по крайней мере, таким же хорошим, как Python ... Как вы думаете, это замедление является постоянным, или оно исчезнет? в какой-то момент после увеличения числа петель? Как должен вести себя Jython в действительно длительных процессах?

РЕДАКТИРОВАТЬ: к сожалению, я получаю java.lang.OutOfMemoryError, если я увеличу количество циклов до 2 миллионов ...

(Конечно, Jython по-прежнему является бета-версией, поэтому в финальной версии он должен стать лучше.)

Я использую Jython 2.5b1 (транк: 5903: 5905, 9 января 2009, 16:01:29), среду выполнения Java (TM) SE (сборка 1.6.0_07-b06-153) и Java HotSpot (TM) 64-разрядная серверная виртуальная машина (сборка 1.6.0_07-b06-57, смешанный режим) на MacOS X 10.5.

Спасибо за ваши ответы.

Answer 1

Сравнительный анализ среды выполнения, такой сложной, как JVM, сложен. Даже за исключением JIT и GC, вы получаете большую кучу, структуру памяти и вариации кэша между запусками.

Одна вещь, которая помогает в Jython, - это просто запустить тестирование более одного раза за один сеанс виртуальной машины: один раз для прогрева JIT и один или несколько раз, когда вы измеряете по отдельности. Я провел много тестов в Jython, и, к сожалению, часто требуется 10-50 попыток, чтобы достичь разумного времени

Вы можете использовать некоторые флаги JVM для наблюдения за поведением GC и JIT, чтобы получить представление о том, как долго должен длиться период прогрева, хотя, очевидно, вы не должны сравнивать при включенных флагах отладки. Например:

% ./jython -J-XX:+PrintCompilation -J-verbose:gc
  1       java.lang.String::hashCode (60 bytes)
  2       java.lang.String::charAt (33 bytes)
  3       java.lang.String::lastIndexOf (156 bytes)
  4       java.lang.String::indexOf (151 bytes)
[GC 1984K->286K(7616K), 0.0031513 secs]

Если вы сделаете все это и используете виртуальную машину HotSpot Server, вы обнаружите, что Jython немного быстрее, чем CPython на pystone, но это никоим образом не отражает производительность Jython в целом. Разработчики Jython уделяют гораздо больше внимания правильности, чем производительности версии 2.5; в течение следующего года или около того с выпуском 2.6 / 2.7 / 3.0 производительность будет более подчеркнута. Вы можете увидеть некоторые из болевых точек, посмотрев на некоторые микробенчмарки (первоначально полученные из PyPy), которые я запускаю.

Answer 2

Те же результаты, что и на моем ноутбуке с Ubuntu Jaunty, с JRE 1.6.0_12-b04:

nathell@breeze:/usr/lib/python2.5/test$ python pystone.py 500000
Pystone(1.1) time for 500000 passes = 12.98
This machine benchmarks at 38520.8 pystones/second

nathell@breeze:/usr/lib/python2.5/test$ python pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 26.05
This machine benchmarks at 38387.7 pystones/second

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py
Pystone(1.1) time for 50000 passes = 2.47788
This machine benchmarks at 20178.6 pystones/second

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py 500000
Pystone(1.1) time for 500000 passes = 19.7294
This machine benchmarks at 25342.9 pystones/second

nathell@breeze:/usr/lib/python2.5/test$ ~/jython/jython pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 38.9272
This machine benchmarks at 25689 pystones/second

Так что, возможно, это связано с версией JRE, а не с версией Jython. Проблемы, с которыми сталкивался проект Armed Bear Common Lisp с ранними версиями JRE 1.6, также могут указывать на это.

Answer 3

Это может быть ошибка в jython 2.5b1. Вы должны рассмотреть возможность сообщить об этом команде Jython. Я только что запустил тест Pystone на своем MacBook с текущей стабильной версией Jython (2.2.1), и я получаю медленные, но стабильные результаты:

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 50000
Pystone(1.1) time for 50000 passes = 2.365
This machine benchmarks at 21141.6 pystones/second

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 500000
Pystone(1.1) time for 500000 passes = 22.246
This machine benchmarks at 22476 pystones/second

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 43.94
This machine benchmarks at 22758.3 pystones/second

mo$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot(TM) Client VM (build 1.5.0_16-132, mixed mode, sharing)

Результаты cPython для меня более или менее одинаковы. Я перезапускаю каждый тест три раза и все время получал очень похожие результаты.

Я также пытался дать java большую начальную и максимальную кучу (-Xms256m -Xmx512m) без примечательного результата

Однако установка JVM на -server (медленный запуск, лучшая производительность при длительной работе, не очень хорошая для «интерактивной» работы) немного изменила картину:

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 50000
Pystone(1.1) time for 50000 passes = 1.848
This machine benchmarks at 27056.3 pystones/second

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 500000
Pystone(1.1) time for 500000 passes = 9.998
This machine benchmarks at 50010 pystones/second

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 1000000
Pystone(1.1) time for 1000000 passes = 19.9
This machine benchmarks at 50251.3 pystones/second

Я сделал один последний запуск с (-server -Xms256m -Xmx512m):

mo$ ~/Coding/Jython/jython2.2.1/jython pystone.py 5000000
Pystone(1.1) time for 5000000 passes = 108.664
This machine benchmarks at 46013.4 pystones/second

Я полагаю, что медленный первый запуск происходит из-за того, что запуск / JIT виртуальной машины еще не вступили в действие. Результаты более длинных запусков более или менее согласованы и показывают влияние горячей точки / JIT

Может быть, вы могли бы повторить свой последний тест с большей кучей? Чтобы изменить переключатели JVM, просто отредактируйте файл jython в вашей установке Jython.

Answer 4

моя скамья на XP_Win32_PC:

C:\jython\jython2.5b1>bench "50000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "50000"
Pystone(1.1) time for 50000 passes = 1.73489
This machine benchmarks at 28820.2 pystones/second

C:\jython\jython2.5b1>bench "100000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "100000"
Pystone(1.1) time for 100000 passes = 3.36223
This machine benchmarks at 29742.2 pystones/second

C:\jython\jython2.5b1>bench "500000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "500000"
Pystone(1.1) time for 500000 passes = 15.8116
This machine benchmarks at 31622.3 pystones/second

C:\jython\jython2.5b1>bench "1000000"

C:\jython\jython2.5b1>jython Lib\test\pystone.py "1000000"
Pystone(1.1) time for 1000000 passes = 30.9763
This machine benchmarks at 32282.8 pystones/second

C:\jython\jython2.5b1>jython
Jython 2.5b1 (trunk:5903:5905, Jan 9 2009, 16:01:29)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.5.0_17

Это не так быстро, но ...

нет "спецэффектов"

Это проблема java-vm?

Добавьте комментарий, если хотите получить дополнительную информацию для моего теста на этом старом Win32-PC

Answer 5

Я почти уверен, что результаты могут быть улучшены путем настройки конфигурации JVM (для этого JRuby использует немало интересных флагов), и я также уверен, что сборка мусора может быть настроена. Если вы очень заинтересованы в этом тесте, вот хороший ресурс для настройки вашей виртуальной машины: Настройка сборки мусора . Я также взглянул бы на конфигурацию JRuby.

. / Alex