PyPy, szybkość działania

0

Nie wiem czy coś robię źle, ale mierzyłem sobie szybkość działania pypy, pypy z jit off i python 2.7

No i tak python osiągnął najniższy czas, pypy z jit off 2x dłuższy, a pypy 3x dłuższy względem czasu pythona.

Wie ktoś jak tego pypy używać?

I jakie czasy wychodzą u was?
Wydaje mi się, że powinno to działać szybciej albo chociaż na równym poziomie.

0

A co konkretnie uruchamiasz? Bo to nie jest tak ze pypy zawsze i wszędzie działa szybciej. Wszystko zależy od tego co ty dokładnie robisz w tym swoim kodzie. Jeśli np. milion razy wołasz jakąś funkcję która jest w CPythonie skompilowana w C i ładowana przez pythona to "szybciej nie będzie".

1

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:)

0

PyPy trzyma sie dobrze jeśli masz tam dużo kodu w pythonie, szczególnie jakiegoś powtarzanego wielokrotnie.

3
lion137 napisał(a):

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1