Optimalizace
Programy málokdy dosahují svého teoretického maxima rychlosti. Nalezení takového bodu je disciplínou poměrně těžkou, neboť vyžaduje jak znalosti matematiky, tak mnohdy detailní znalosti dané oblasti v kombinaci s konkrétním problémem. Co je dobré pro jeden program, nemusí být kvůli odlišným datům ideální pro jiný.
Za svou praxi jsem se setkával se čtyřmi základními body, které se objevovaly jako slabina jak v produkčních aplikacích velkých společností, tak ve výzkumech vědeckých týmů.
Časová složitost
Představte si, že chcete utřídit 1000 položek. Například jména zaměstnanců podle abecedy. Můžeme to udělat jednoduše. Všechny zaměstnance projdeme, najdeme si toho, který je ze všech první a dáme ho na začátek. Potom ze zbylých 999 najdeme druhého a tak dále. Na konci máme utřízený seznam. Jenže při důkladnější analýze zjistíme, že zabral 10002 operací, tedy jeden milion. Tento algoritmus má totiž takzvanou kvadratickou složitost. Při 10000 zaměstatních se už dostáváme na 100 milionů. U milionu na celý jeden bilion. Jde o záležitost zcela neudržitelnou.
Optimální algoritmus už není tak zřejmý. Stojí na tom, že se zaměstnanec na začátku vybere náhodně a zbylých 999 se odloží na kupu doleva, pokud jsou v abecedě před ním, respektive doprava, pokud za ním. Na těchto dvou kupách se proces opakuje tak dlouho, dokud nemáme 1000 kup setřízených v takzvaném binárním stromu. Výsledná složitost je pouze n * log2n. Tedy 10000 operací pro 1000 zaměstnanců místo milionu a pouze 20 milionů operací pro milion zaměstnanců, místo 1 bilionu.
Jde jen o úvodní úlohu z disciplíny počítačových věd. Dnes se analýza časové složitosti v praxi mnohdy přehlíží, protože většina knihoven, které pracují nad daty, už v sobě optimální algoritmus obsahují. Přesto se v kódech zejména méně zkušených programátorů stále ještě setkávám s bloky, kde si autor setřizuje data triviálním, nejméně optimálním algoritmem, bez použití knihovny třetí strany. Na jeho počítači s 10 testovacími daty kód funguje parádně. Než se to pustí do produkce.
Procesor je pomalý
Tento problém vídám hlavně v prostředí cloudu. Program běží na levném masově vyráběném, málo výkonném procesoru, který byl zvolen ve snaze ušetřit za provoz cloud jednotky, nebo nechtěně vybraném jakožto defaultní hodnotou. Lepší procesní jednotka mi nedávno urychlila jednu kritickou službu v jádru architektury na trojnásobek.
Aby však byl upgrade procesoru efektivní, je třeba se ujistit, že je daná služba v prostředí Cloud Runu nebo Kubernetes brzděna právě jím. Některé služby mají totiž úzké hrdlo v paměti, disku nebo síti. Služby, kde takové urychlení uplatníte, jsou například zpracování zvuku a obrazu, preprocessing neuronových sítí nebo i průchod jí samotnou (ale tady možná pomůže až další odstavec).
Běh neuronové sítě je pomalý
I při využívání modelů 3. stran bych se ujistil, že běží na správném hardwaru a má například pro Vás vhodné nastavení kvantizace, tedy přesnosti sítě. Při analýzách dávám GPU odhad 40 násobného zvýšení rychlosti oproti provozu na CPU, ale při cenách 20000,- měsíčně je zcela nevhodné takto provozovat malé sítě na rozpoznávání koček od psů. Zde je třeba zvážit trojúhelník ceny, rychlosti a přesnosti, kdy je třeba mít na paměti, že aplikace téměř jistě nedosáhne vysoké přesnosti a rychlosti za velmi malou cenu provozu. Jde tak o hledání optimálního bodu uvnitř tohoto trojúhelníku.
Nepoužívání vektorizace
Tým programátorů dostane skvělý model na předpověď cen. Data posílá po jednom produktu na každý jeden den. Vyhodnocování se dělá 6 hodin, tak přichází s různými automatizovanými úlohami, které po nocích všechno přepočítávají. Zkušený ML engineer pak pustí předpověď nad všemi produkty najednou s posuvným časovým oknem a výsledky dostane za 2 minuty.
Popravdě jde možná o nejčastější problém, se kterým se setkávám. Numpy má skvělé nástroje, jak mnoho problémů světa redukovat na pouhé násobení matic, které má pak už zvládnuté skvěle. Takto se mi povedlo jeden hotový program zrychlit dokonce tisícinásobně. Proč toho nevyužít?
Závěr
Řešením těchto bodů můžete výrazně zvýšit výkon a efektivitu vašich programů, ať už v produkčním nebo výzkumném prostředí. Pokud potřebujete pomoc s optimalizací kódu nebo infrastruktury, jsem k dispozici.