Vlákno názorů k článku Souběžné a paralelně běžící úlohy naprogramované v Pythonu (2) od klokan - Poznámka k té poznámce: náročné paralelní výpočty normálně...
-
Pavel TišnovskýZlatý podporovatelVětšinou ano, ale má to háček v předávání dat tam a zpět - protože v tomto případě je mj. nutné myslet na GC Pythonu atd. Někdy je to trošku minové pole :-)
-
Pavel TišnovskýZlatý podporovatel
+ existují lidi, co by se céčka/Go/Rustu nedotkli ani klackem :-) [ale to je dobře, aspoň víc vyniknou ti ostatní]
-
Jenže to tak úplně není. Když dělám nějaký skript, tak v 90% šáhnu po Pythonu, protože ten skript spustím párkrát, ale mám ho napsaný velmi rychle. To jestli mi to běží hodinu nebo dvě mě opravdu netrápí, ale jestli to dělám 10min nebo hodinu už rozdíl je. To vůbec nemá nic společného, že bych C nebo Go nepoužil jindy, ale prostě v tom Pythonu se většinou píše o několik řádů rychleji, navíc Python má podporu skoro pro všechno narozdíl od Go a Rust. Takže u nás frčí kombinace Java pro microservices a Python pro skripty. Hlavně u HTTP requestů (REST API) jsem nikdy nedělal s ničím co by bylo tak snadné a účinné, jako je Python a requests, to samé pro MongoDB.
-
Kdyby byl Python 2x pomalejší, tak by to mohlo stát za úvahu, jenže když si vezmeme Great Language Shootout, tak nějaký numerický výpočet v Pythonu může být klidně 180x pomalejší, než v Rustu nebo C. Takže pak nejde o to, jestli stojí za to si usnadnit práci a mít pomalejší program, ale jestli je výsledný program vůbec použitelný, nebo ne.
-
“výkon díky zero-overhead abstrakcím při trošku rozumném návrhu běží jako blesk”
Ty tzv. “zero-cost” abstrakce jsou konkrétně v Rustu trochu “wishful thinking”, popis “jako blesk” bych použil možná u Fortranu, Rust je extra bezpečný, ale platí se za to ztrátou části výkonu (což je naprosto logické, člověk si musí vybrat).
-
Zero-cost je blbý termín, začal jsem používat zero-overhead, což lépe vystihuje, že použití abstrakce je stejně "drahé", jako kdyby se (principiálně) ten samý kód napsal v C nebo assembleru.
Co se týče bezpečnosti, tak podle toho, jak rozumím možnostem optimalizace kompilátoru, Rust umožňuje díky jistotě, že se některé věci nestanou, říznout do generování kódu daleko důrazněji. Overhead lze očekávat třeba u indexování vektoru, jenže tam existují možnosti z toho vyjít pomocí metod typu get_unchecked(), které se zase ale AFAIK s výhodou používají třeba v přístupech přes iterátor, jelikož ten ví, kam může sáhnout a kam už ne. Takže obecně ano, určitě existují pořád situace, kde člověk za bezpečnost platí, ale tak zásadní problém tam snad není.
-
“Rust umožňuje díky jistotě, že se některé věci nestanou […]”
To se týká každého jazyka, třeba Julia díky typovému systému také brutálně optimalizuje. U toho indexování pole má Rust pořád dost mezery (má-li být stoprocentně bezpečné), některé jazyky ho umí bez kontrol a výjimek za běhu, to chce ale silnější typový systém, tady taky Rust zaostává. Obecně jo, různé unchecked/unsafe hacky pomáhají, ostatně standardní knihovna je jich plná, ale to je dost nečisté řešení.
-
Pavel TišnovskýZlatý podporovatel
Však já to nemyslel obecně (proto jsem psal "existují"). Ale vidím to tady na několika projektech - code base horko těžko vznikla v Pythonu*, už se to "seká", ale na přepis nebo dokonce identifikaci kritických částí autoři nemají čas a asi ani znalosti. Tady to můžeme řešit masivní paralelizací (běží teď 16 podů a klidně to jde naškálovat i víc), ale obecné řešení to samozřejmě není.
* dokonce byla snaha to nějak splichtit v BASHi, ale to by byl děs a hrůza (nebyl tam ani technický důvod, jen že lidi prostě BASH znali a Python ne)
-
Pavel TišnovskýZlatý podporovatel
V podstatě tuto mašinku:
https://insights-core-tutorials.readthedocs.io/en/latest/Hlavně ta pravidla:
https://github.com/RedHatInsights/insights-core/blob/master/docs/notebooks/Diagnostic%20Walkthrough.ipynb(ono to i trošku dává smysl, protože ta pravidla, resp. jejich náznak, tvoří admini, kteří ví, co způsobilo problém. A ti to většinou získávají z Bashí CLI)
ČLÁNKY DO MAILU