Názory k článku Nové vlastnosti Pythonu 3.14 v praxi: rychlost a paměťové nároky aplikací využívajících více souběžných úloh

ty interprety tedy moc dobře nevychází, asi je nejlepší pořád zůstat u běžného multithreadingu ne? Navíc bez GILu to může být nejlepší řešení.

Proc byl vlastne pridan "ve svem interpreteru" mod? Chapu to jako takovou silenejsi verzi k javovskym classlaoderum...

spíš je to na situace, kdy by se hodila "izolovaná vlákna" a přitom forkování více procesů bude moc (paměťově) drahé.

Já tam vidím, že jsou v obou případech rychlejší než thready (16. Změřené výsledky). Na co teda narážíš?

ono to nakonec nevypadá špatně. Schválně jsem sice na začátek dal benchmarky na spuštění interpretru, to je relativně pomalé, ale jinak je to fajn řešení na pomezí vlákna-procesy. Asi se nehodí spouštět novej interpret například pro každý REST API call, ale mít připravený pool workerů a přes fronty ten response generovat - proč ne?

Jasně, rozumím. Spor byl o ten startup time, což je opravdu nevýhoda.

Vysledky vypadaji neuveritelne.

Asi by by bylo lepsi se bavit o "cpu seconds" (user time) a "wall clock" (real time). K tomu jeste nove oba s "thread free". Myslim, ze async v python dela "concurrency" ale ne "paralelism" takze 1 nebo 100 tasku by melo trvat stejne dlouho. Thready je to jedine kde by mel byt rozdil v "thread free". Procesy a interpretery by meli bezet paralelne, ale brat meritelne vic pameti. Mozna i trochu vic cpu.

A pamet? Chapu to dobre, ze Vzit RSS jednoho threadu a rict ze je to cela spotreba pameti? Taky bych si dal 10 piv v hospode za 60 Kc celkem. Nebo rvnou 100?

Zvolit paralelismus 100 je take zajimave. Bezite to na stroji se sto nebo vice jadry? Protoze pak je to vlastne zase jen o frontach (schedulingu a latencich).

BTW: "git push"? :)

Co na nich nejde uvěřit?

Ad cpu seconds/wall clock:
Měřil se vlastně wall clock, to je pro porovnání užitečnější hodnota. Ale teď mi vlastně došlo, jak myslíš ten CPU time, ano mělo by to smysl (nebude úplně stejnej kvůli věcem okolo handlingu úloh a zámkům).

Ad async:
přesně tak, proto jsem to do měření zařadil, aby se uviděl rozdíl ve chvíli, kdy skutečně je něco zapotřebí vypočítat paralelně (a ne jen čekat na I/O). Samozřejmě pro I/O-heavy úlohy bude při async celková doba menší, než bez něj.

Ad interpretry:
Jinak interpretry běží tak napůl mezi multithreadingem a skutečně paralelně.

RSS:
Jak by se měla měřit paměť, než RSS toho procesu (ne threadu)? Jako ano, můžeme se bavit, jestli je RSS lepší než VirtM, ale RSS je asi nejblíž "skutečné" spotřebě paměti toho procesu s více vlákny.

Jinak běžím buď na 8 nebo na 48 jádrech (podle stroje), ale to je asi jedno. Prostě to chtělo víc úloh než jader.

10. 11. 2025, 22:09 editováno autorem komentáře

Ok, podival jsem se na to znovu a detailneji. Asi to neni tak hrozne, ale urcite by to dalo vylepsit...

V prvni rade bych doporucil "git push". Mohli jsme od zacatku lepe pochopit o cem se bavime :)

Pri detailnejsim zkoumani jsem si vsimnul, ze je v sekci 9 sleep. V async kodu u konci clanku zadny sleep neni. Clanek je dlouhy, necetl jsem kazde slovo. Pardon :)

Kazdopadne sekce 8 se mohla jmenovat proste "overhead" spusteni 100 uloh. Sekce 9 "io" imitace. Sekce 9 a 10 smazat. Zkolabovat do jedne radky: "Spusteni interpreteru trva mem stroji 0.04s a deje se sekvencne." Alespon tak ty data chapu.

Tabulka ze sekce 16 je snad to co bych ocekaval z nadpisu clanku.

BTW: Nejsem zvykly na technicke veci v cestine. "Celkový čas vykonání" mi zni spis jako "cpu seconds" nez "wall clock". Tabulky mohli v klidu mit hlavicku treba "Doba [s]".

Pamet merit je na linuxu tezke. Smaps si tu ted vysvetlovat nebudeme. "/usr/bin/time --verbose" nefunguje na podprocesy. Nejlepsi a nejjednodussi je spustit to v cgroups:
systemd-run --scope --user --unit=mybench uvx python@3.14 bench.py
a podivat se na
cat /sys/fs/cgrou­p/user.slice/u­ser-1000.slice/user@1000­.service/app.sli­ce/mybench.sco­pe/memory.peak