1. Vždy mě velice zajímalo, jakým způsobem se dají psát programy, které využijí HW daného počítače opravdu na maximum.
2. Jde v návaznosti na velkou rychlost kódu dělat ty programy úsporně, tzn. ve výsledku s malým obsazením operační paměti? Osobně se mi moc nelíbí dnešní trend kdy aplikace podobného nebo stejného účelu jako před 10 lety má mnohdy o dost vyšší paměťové nároky. Tím zde nemyslím třeba fyzikální simulace, kde se např. pracuje s velkými číselnými maticemi apod.
3. Může dojít díky velice rychlému kódu dokonce i k přehřátí procesoru?
4. 1-2 roky nazpět zde bylo téma, jehož název si bohužel nepamatuju, ale něco podobného na způsob rychlosti aplikací se tam řešilo. Byla tam myslím i řeč k některých matematických knihovnách typu LAPACK a někdo tam dával odkaz na projekt, myslím že to bylo nějaké americké univerzity, kde výsledkem byla asi knihovna na provádění matematických operací, která snad způsobovala, že daný program (nebo jen určité části kódu) donutily využívat CPU pouze registry po určitou delší dobu a nepřistupovat do operační paměti, čímž se radikálním způsobem zrychlil běh daného programu (výpočtu). Já jen, kdyby někdo náhodou tušil název toho vlákna.
Předpokládám, že ti co dokážou psát velice rychlý a paměťově úsporný kód, jsou prostě profíci z praxe. Nicméně byly by nějaké rady pro začátečníka ohledně třeba programovacích technik či způsobů jak se k těmto dovednostem také dopracovat?
1. Jako strojaři vám doporučím příměr k automobilu. Využít HW počítače naplno je jako využít výkon auta naplno. Za určitých podmínek to lze, ale je to nepraktické a nebezpečné. Dokud byla auta slabá, tak se dala využít naplno tím, že jste prostě najel na silnici, sešlápl plyn až na podlahu a se smrtí v očích jste vyrazil rychlostí 40km/h. Na víc ten motor neměl. V zatáčkách jste ani nemusel brzdit, motor při sebemenším pohybu volantu ztrácel výkon sám o sobě. První počítače (a i dnes ty velmi slabé) na tom byly stejně. Dal jste tomu program a ony ho chroustaly vším svým výkonem. Ony to tak dělají dodnes, ale co dříve trvalo 5 minut mají dnes za 3 sekundy. A pak je to jak s auty - sice máte pod kapotou více než 100 koní a motor utáhne i 230km/h, ale vy tak rychle nejedete a ten výkon využijete jen na pár sekund při rozjezdu na křižovatce. Po zbytek doby nevyužijete výkon ani počítače, ani auta.
Tak a stejně jako existují závodní auta, tak existují i "závodní počítače". Ty jsou nasazovány pro úlohy, které využijí maximum výkonu po delší dobu. Přičemž i u těch počítačů jde vlastně o rychlost. Tedy za jak dlouho zpracuje zadanou úlohu.
2. Tady je to zase jak Lego. Dnes se programy staví z prefabrikátů, pomocí nástrojů, které vytváří unifikované "kostky". Jako Lego. Dříve (a i dnes ve specializovaných případech) se spíše používala technologie "vstřikování plastů". Výsledek byl mnohem lepší, úspornější, ale dražší a zdlouhavější. A zatímco z Lega vám něco poskládá i 10leté dítě, tak navrhnout, vyrobit a použít formu pro vstřikolis chce odborníka s praxí. A pokud zjistíte, že tam máte něco špatně, tak to Lego upravíte snáze než výlisek.
Máte pravdu v tom, že programy lze psát úsporně. Není důvod, aby jednoduchá věc musela dělat obrovskou binárku a pak zabrat desítky nebo stovky MB v paměti. Řada programů se tak dodnes píše. Jenže ono je jednodušší použít už předpřipravené kusy programů (knihovny), které bývají univerzální včetně všech negativních důsledků (prostě ssebou všude nosíte kompletní 900 stránkové Strojnické tabulky, když ve skutečnosti v nich čtete jen třídy nástrojové oceli. No a vytrhnout jen těch pár stránek nejde). Tím, jak se vyvíjí a rozšiřují tyhle knihovny, tak roste i prostorová a paměťová náročnost. Ale i dnes se dá najít dost "lightweight" knihoven na kde co, které dělají jen malou množinu věcí a neplácají tak zbytečně místo něčím, co nepotřebujete. Na webu jsou celkem v oblibě, ale v případě "větších programů" se spíš setkáte s těmi obrovskými knihovnami, programem co má 250MB a ihned po spuštění zabere 400MB paměti aniž by vlastně vůbec začal něco dělat.
3. To je jak se stroji :-) Počítačový HW je stroj jako každý jiný. Místo pohyblivých částí generujících teplo třením obsahuje miliardy součástek, kde vzniká teplo průchodem proudu a přechodovými jevy. Samotný průchod proudu nebývá problém, protože to jsou velmi malé proudy. Jenže přechodové jevy už jsou docela potvora. Nábojové pumpy, impedance a podobné legrace generují teplo kdykoliv se nabíjí/vybíjí nebo se v nich mění velikost proudu. Bývají to poměrně krátké pulsy, takže to také není samo o sobě problém. Jenže když těch pulsů začne být více, tak to teplo vzniká častěji. Obecně platí, že čím vyšší frekvence, tím více tepla vzniká. A to se musí odvádět. U obvodů s malou spotřebou (=nízké proudy) a malou frekvencí úplně stačí chlazení pouzdrem. Pokud jsou ale proudy větší, nebo roste frekvence, tak už je potřeba nějaký větší chladič, případně aktivní chlazení. Výrobce součástek měří vznikající teplo a dává doporučení na montáž i chlazení. Jednodušší součástky snesou montáž jakoukoliv, složitější už třebas vyžadují několik cm nad povrchem poudra volných, jiné proudící vzduch, jiné vyžadují chladič atd.
A rozuzlení otázky pak spočívá v dodržení doporučení výrobce součástky a pokročilými technologiemi správy spotřeby. Když dodržíte doporučení výrobce na chlazení, tak součástku neupečete. Bohužel řada výrobců HW toto nedodrží (šetří na chladiči nebo na místě, případně nezvládnou údržbu a chladící kanály se ucpou atd.) A pak záleží na těch technologiích správy spotřeby. Řada složitějších obvodů, kam patří třebas mikroprocesory, dokáží nějakým způsobem analyzovat zátěž a dokáží na to reagovat. Měří třebas "wait stavy" (kdy nebyly instrukce ke zpracování) a podle toho snižuje frekvenci. Nebo rovnou odpojuje části obvodů, jako jsou dodatečná jádra apod. To je na jednu stranu fajn, ale je to vražedná kombinace s "poddimenzovaným chlazením". Protože vám taková součástka v daném zařízení může měsíce i roky pracovat bez problémů, ale pak přijde najednou úloha, která té součástce "sedne" a ta začne aktivovat všechny části obvodu a zvyšovat frekvenci na nominální. A najednou zjistíte, že to ten chladič neuchladí a máte problém. Naštěstí v mikroprocesorech bývá senzor teploty, který ho odpojí. Ale nemusí fungovat včas nebo dobře. Například se vám přehřeje a spálí část, která je daleko od senzoru, případně se přehřála rychleji, než to senzor odpojil.
Takže ano, pokud je zařízení špatně zkonstruováno, tak můžete "vhodně napsaným programem" způsobit přehřátí a nějakou část zařízení poškodit. Je to ale důsledek chyby konstrukce, kdy chladič nedokáže uchladit "špičkový ztrátový výkon". Ten je výrobcem součástek specifikován a přes něj se programově nedostanete. Čili vhodně napsaným programem se k tomuto mezníku můžete přiblížit, ale přes něj to nejde, protože procesor už víc nezrychlí a ani nemá nic dalšího co zapnout. A tady ještě zmíním "overclocking". To dělají lidé, kteří chtějí zvýšit výkon zařízení tím, že nějak donutí ho pracovat na vyšší než nominální frekvenci. Procesory a základní desky na to dnes běžně nabízejí podporu. Zvednou tím "maximální možnou rychlost", ale v důsledku toho i "generované teplo". A jsme zpátky u toho, zda to zvládnou uchladit. Proto běžně kupují lepší chladiče, chladí vodou, kupují větší počítačové skříně s dodatečnými větráky atd. U procesorů, pamětí apod. "naštěstí" platí, že přestanou fungovat dříve, než shoří. Prostě když se procesor přehřeje, tak se počítač zasekne nebo sám restartuje. Po ochlazení zase začnou fungovat. Pokud to ale někdo hodně přežene, případně si pomůže zvýšením napětí, tak to pořád spálit může. Pokud se přidá porucha chlazení, tak je to riziko dost velké.
4. Tak o tomhle konkrétně nevím.
Technik jak psát rychlé programy je mraky. Není žádný jeden univerzální návod. A ani přístup není jednotný. Pro některé typy úloh je vhodné jít na nejnižší úroveň a psát přímo v assembleru (minimum ztrát zbytečnostmi), jindy je vhodné použít knihovnu někoho "chytrého" (správně napsaný komplexní algoritmus, třebas pro řazení nebo složité matematické operace). Ve většině případů je to ale jedno, protože úloha je provedena v tak krátké době, že to zrychlení nestojí za to. Jestli se vám stránka načítá 235ms nebo 17ms vás až tak trápit nebude, přestože je to rozdíl ve výkonu o celý řád. Na složitější úlohy jsou lepší již hotové knihovny. Kupříkladu napsat si správně merge sort dalo práci a i tak jsem byl pomalejší než knihovna, protože její autor použil i pár triků, o kterých jsem dříve neslyšel (ale fakt, že moje verze byla bez ohledu na velikost dat vždy jen cca 3x pomalejší mě potěšil, protože to byl důkaz, že v zásadě jsem to měl správně). Pokud programujete něco, co není algoritmicky složité, ale máte omezené prostředky (slabý HW nebo málo času), tak se vyplatí jít do něčeho na nižší úrovni (nemusí to být nutně assembler). Ale nic z toho co jsem napsal není zcela univerzálně platné. Vždy je to o zvážení možností a priorit. Ale s tím se jako strojař setkáváte často. Titan je sice fajn materiál, ale někdy kvůli ceně, jindy zase kvůli náročnosti na opracování, prostě použijete ocel. A pak po pár letech zjistíte, že jste ten titan nepoužil nikdy, ačkoliv z hlediska vlastnostní byl skoro vždy ideální.
47 Odpovědí
12171 Zhlédnutí