Server Phoronix dnes otestoval výkon Pythonu 3.11 Beta 1, který vyšel minulý měsíc. Python 3.11 by již měl zahrnovat zrychlení z projektu „Faster CPython Project“. Podle oficiálního testu pyperformance je 3.11 o 25 % rychlejší než 3.10. Ale podle druhu zátěže lze očekávat zrychlení v rozmezí 10–60 %.
Podle testů vybraných serverem Phoronix byl Python 3.11 v průměru o 40 % rychlejší než Python 3.10 na AMD Ryzen 9 5950X. Ostrý Python 3.11.0 by měl vyjít letos v říjnu.
(zdroj: phoronix)
Jak v čem. Hodně overheadu zmizelo, výrazně se optimalizovalo, C struktury se líp zarovnaly, ale proti tomu např. přechod z hardwarových integerů na softwarové BigInty výrazně zpomalil aritmetiku, takže různé bitwise operace, kryptografie atd. zpomalily na polovinu (což je OK protože pure python implementace tohoto nikdo nepoužívá).
Myslím že to "if Python is too slow for you you're using it wrong" platí dál. Chápu to jako runtime kterým interaguju s uživatelem, natahám si data, naparsuju XML a JSONě, ale na samotné zpracování to pošlu do nativního modulu.
Když nám CPython v základu zrychlí, tak fajn, nicméně potřeba "rychlého" Pythonu je IMHO na tom zhruba podobně, jako potřeba lidí jezdit autem 250 km/h.
Jako, bylo by to pěkné mít možnost se rychleji přesunout z bodu A o bodu B, v realitě ale narazíte na zácpy na silnicích (čekání na data z externích zdrojů). A pokud vás skutečně bude brzdit něco v interpretaci kódu, tak spíš nevhodný návrh aplikace než pomalost Pythonu.
A pokud patříte mezi to <1% šťastlivců a skutečně děláte něco, kde vás rychlost Pythonu trápí, tak pak si, po diskuzi s profilerem, můžete dát tu práci odskočit si do C nebo třeba Rustu.
8. 6. 2022, 14:08 editováno autorem komentáře
Přesně tak. Ale. V jednom místě je surová rychlost pythonu důležitá, a tou je doba jeho spouštění, hlavně importy. Kdy musí co nejrychleji projet inicializace všeho, než se dostane k užitečné práci.
Dnes je běžné mít i často volané programy implementované v Pythonu, běžně vídám v kontejnerech různé odesílače telemetrie které se volají "cronem" třeba jednou za 10 sekund. Ušetřit každou minutu půl sekundy CPU času (benchmark níže) může představovat pro server s tisícem instancí měřitelný pokles zátěže/spotřeby.
$ hyperfine "python3.10 -c \"import requests; print('Hello world')\"" "python3.11 -c \"import requests; print('Hello world')\""
Benchmark 1: python3.10 -c "import requests; print('Hello world')"
Time (mean ± σ): 325.4 ms ± 22.7 ms [User: 297.4 ms, System: 25.3 ms]
Range (min … max): 295.9 ms … 365.4 ms 10 runs
Benchmark 2: python3.11 -c "import requests; print('Hello world')"
Time (mean ± σ): 249.3 ms ± 15.7 ms [User: 216.3 ms, System: 31.1 ms]
Range (min … max): 227.6 ms … 270.8 ms 12 runs
Summary
'python3.11 -c "import requests; print('Hello world')"' ran
1.31 ± 0.12 times faster than 'python3.10 -c "import requests; print('Hello world')"'
Requests patří k nejpoužívanějším a zároveň nejdražším (co do CPU času v importu) knihovnám, obě verze cpythonu startují okolo 20 ms, to zrychlení je v import requests.
Však tohle právě ukazuje, že interpret se spouští pořád tak nějak stejně rychle, ale inicializace toho modulu se výrazně zrychlila :-)
V producer/consumer pipeline taky budete s každým spuštěním tasku parsovat, reimportovat, inicializovat.
Pro srovnání jen python:
$ hyperfine "python3.10 -c \"print('Hello world')\"" "python3.11 -c \"print('Hello world')\""
Benchmark 1: python3.10 -c "print('Hello world')"
Time (mean ± σ): 18.2 ms ± 6.9 ms [User: 15.1 ms, System: 3.6 ms]
Range (min … max): 12.3 ms … 42.5 ms 158 runs
Benchmark 2: python3.11 -c "print('Hello world')"
Time (mean ± σ): 17.8 ms ± 4.8 ms [User: 14.2 ms, System: 3.5 ms]
Range (min … max): 12.3 ms … 40.1 ms 170 runs
ČLÁNKY DO MAILU