Własnie, zależy co tam Testujesz, jak robiłem kiedyś proste benchmarki: https://lion137.blogspot.co.uk/2016/11/few-benchmarks.html , to pypy trzymało sie nieźle:)
Bo tam testowałeś implementację bignumów, a nie jakości JITa.
Powody dla który bignumy w Pythonie mogą być szybsze niż w Javie są co najmniej dwa:
- bignumy w Pythonie są napisane w czystym C: https://github.com/python-git/python/blob/master/Objects/longobject.c a bignumy w Javie są napisane w czystej Javie
- operacje na BigIntegerach w Javie mają kiepską złożoność, np mnożenie ma zawsze złożoność O(n*n) chociaż można np użyć algorytmu Karatsuby (moja implementacja tutaj ) i mieć szybsze mnożenie dla dużych liczb (> 2000 bitów); analogicznie trzeba by postąpić z innymi operacjami
Bardzo często mikrobenchmarki testują wydajność takich rzeczy jak:
- bignumy
- struktury danych typu hasz mapy
- regexpy
- inne wbudowane operacje
W takich przypadkach jakość JITa czy szybkości interpretowania schodzi na dalszy plan jeżeli powyższe elementy są zaimplementowane w czystym C. Biblioteka standardowa Javy jest napisana w całości w czystej Javie, a więc włączając w to bignumy, hasz mapy, regexpy, sortowanie, itp itd.
Ja swego czasu popełniłem benchmark, w którym praktycznie nie wykorzystuję żadnych wbudowanych algorytmów. Ten benchmark to program do kompresji danych z autorskim algorytmem kompresji (więc o wbudowanego gzipa czy czegoś podobnego nawet nie zahacza).
Program wraz z różnymi implementacjami i porównaniem wydajności jest tutaj: https://github.com/tarsa/TarsaLZP
Encoding speed on [enwik8] 1 (command line interface implementations) - revision [53a85ed] 2:
Language |
Real time |
User time |
Sys time |
Execution environment |
Notes |
C |
7.473s |
7.165s |
0.276s |
GNU GCC 4.6.3 |
Three runs average, SSE optimizations (vectors and prefetching) |
C |
12.734s |
12.437s |
0.279s |
GNU GCC 4.6.3 |
Three runs average, no SSE optimizations |
Java |
20.587s |
20.326s |
0.280s |
Oracle JDK 7 update 15 |
Three runs average |
Python |
60.346s |
59.907s |
0.367s |
ShedSkin 0.9.3 + GNU GCC 4.6.3 |
Three runs average |
Python |
139.983s |
132.384s |
6.339s |
PyPy 1.9.0 |
Three runs average |
Python |
1806.230s |
1804.573s |
0.436s |
CPython 2.7.3 |
Single run, -OO |
PyPy jak widać radzi sobie dobrze w porównaniu do CPythona, aczkolwiek do Javy dalej sporo brakuje, mimo że program jest prosty.