Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Magirus 17. 12. 2014, 01:09:07
-
Fórum na rootu navštěvuji už delší dobu pouze pasivně a jsem si vědom toho, že je tu mnoho profíků z praxe. Proto se předem omlouvám za své, poněkud amatérské otázky, jelikož nejsem programátor, ale studuji VŠ strojního zaměření. Nicméně počítače mě vždy hodně zajímaly a chtěl bych do programování proniknout.
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. Nicméně jakými způsoby se toho dá docílit. V případě výpočtových aplikací (simulací) to je zřejmě optimalizace daného matematického výpočtu a v případě klasických uživatelských aplikací vůbec netuším.
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. Pouzivas treba specialni instrukce procesoru (ktere vykonaji rychleji casto pouzivane matematicke operace pouzivane treba u zpracovani signalu) nebo k vypoctum pouzijes grafickou kartu (napr. nVidia CUDA)
2. To neni pravidlo, jestli pouzijes nejaky graficky toolkit treba Qt, vypada to hezky, je s tim malo prace ale je to narocne... naopak kdyz napises jednoduchou textovou aplikaci, nebo treba pouzijes ncurses (grafika v terminalu), narocnost nebude tak velka. A dnesni pocitace maji vice RAM nez predtim, tak proc to nevyuzit.
3. Rychly kod? Asi myslis vypocetne intenzivni ulohu... Dneska asi tezko, procesor ma ochranu a pri vysoke teplote se vypne.
4. Tu knihovnu neznam, ale treba v C lze rict ze dana promenna bude v registru. Ale ne vzdy to kompilator tak udela, protoze to nemusi byt vzdy rychlejsi.
Velice rychly kod dneska za tebe udela kompilator, ktery dokaze delat optimalizace na ktery bezny smrtelni neprijde. Jestli chces radu, nauc se C a assembler a hraj si stim, podivej jak kompilator kompiluje, zkus si napsat program za pouziti specialnich instrukci a pak bez nich a porovnej rychlosti apod.
-
Dneska asi tezko, procesor ma ochranu a pri vysoke teplote se vypne.
Tady sem se trochu ukvapil, ptal ses jestli se muze prehrat - muze, kdyz nebude stihat chlazeni (napr. zaneseny chladic prachem), ale neznici se, protoze se diky ochrane vypne.
-
1. Dříve se takové programy nebo části programů psaly v assembleru, dneska už jsou optimalizující překladače jazyků jako C apod. často "chytřejší" než programátor (nebo by to programátorovi trvalo tak dobře trvalo příliš dlouho, protože se píší pořád rozsáhlejší aplikace). Dnešní procesory mají většinou více jader, takže je třeba paralelizovat. Používání grafických nebo jiných speciálních čipů zejména pro paralelní "stejnorodé" zpracování většího množství dat.
2. Záleží na řešeném problému a algoritmu. Tím jsi limitovaný. A pak můžeš omezit balast v podobě nějakých neefektivních knihoven, běhových prostředí, operačních systémů apod. - samozřejmě ale zaplatíš ztrátou pohodlí při programování, protože ty knihovny tě odstíní od řady problémů a zjednoduší ti práci.
3. Záleží na HW. U dnešních procesorů pro PC těžko, procesory v případě počátku přehřívání automaticky zpomalí (vkládání prázdných cyklů apod.). Pokud rychlým kódem myslíš efektivní kód, tak ten ani nemusí způsobovat nějaké
4. Třeba Intel prodává různé knihovny, které řeší určité typické základní problémy a má je napsané tak, aby na jeho procesorech byly vysoce efektivní.
Z. Potřebuješ mít rozhled základní rozhled v HW (jak to obecně funguje - procesoru, paměti, instrukce apod.), algoritmech, nějaký nižší programovací jazyk - zejména C, hodí se alespoň pasivně Assembler (když to bude ladit a hledat možnosti zrychlení) atd. Obecně je dnes ale výkon počítačů poměrně levný (oproti ceně programátora), takže snažit se psát všechno efektivně nedává smysl. Optimalizovat dává smysl typicky jen nějaké malé části programu, které spotřebovávají většinu zdrojů (CPU, RAM apod.).
-
Rychlost kódu dnes závisí také na délce vývoje. V komerční sféře málokdo zaplatí peníze za superoptimalizovaný kód, protože koupit lepší HW, který to utáhne je prostě většinou levnější než platit člověka, který to vytuní. Optimalizují se pouze věci, kde se to vyplatí a je to poznat - dlouhotrvající, výpočtově náročné nebo časté operace + na slabý HW jako jsou mobily, kde se navíc počítá s výdrží na baterii (rychlejší kód tolik nežere).
Větší aplikace (ne akademická dema) se obvykle píší v nějakém vyšším programovacím jazyce (např. Java) nebo frameworku a pro kritické věci se část napíše v C++ nebo assembleru (ten už dnes moc ne). Často je důležitější spolehlivost a udržovatelnost (čitelnost) kódu než nějaké lowlevel optimalizace.
Vyšší paměťová náročnost často může přinést i zrychlení programu, existují techniky např. na ukládání mezivýpočtů, cachování apod.
Příklady optimalizací?
- úprava složitosti algoritmu, tím se obvykle získá nejvíc a nezávisí to na použitém jazyce (akademický příklad - místo pomalého bubble sortu se použije quick sort)
- využití SSE/AVX instrukcí - dnes jsou kompilátory dost chytré, a aby člověk vymyslel rychlejší kód, tak většinou musí vědět co dělá, výsledek může být i pomalejší
- kompilace pro x64 - má význam pouze pokud se počítá s velkými čísly (tam je téměř 100% výkonu nahoru), u obyčejných aplikací je výkon +- stejný, někdy i nepatrně nižší. Výhodou je spíše možnost využít více ram (32bit aplikace má tuším max 2GB/proces a <4GB/systém)
- vícevláknový kód - pro výpočet se použije více procesorů, což výrazně zrychlí výpočty a využije dostupný výkon, ale ne každý algoritmus jde takto rozdělit (problém je, když jsou na sobě výpočty závislé, a také je zde větší náchylost k chybám)
- výpočet přes GPU, podobný problém jako u vícevláknového kódu (GPU si lze představit jako hodně (50-3000 dle typu) malých pomaých procesorů), když se kód správně rozloží, může být výpočet mnohonásobně rychlejší. Na serverech ale kromě vysoce specializovaných úloh GPU nebývá. Zatím se to využívá např. k akceleraci dekódování videa nebo výpočtům fyziky v hrách. Jako framework se používá Cuda (nvidia only) a Opencl (multiplatformní).
- u hrátek typu uložím si data do procesorové cache je třeba brát v úvahu, jak jsou ty cache velké, rozdílné parametry procesorů atd. Obecně platí nějaké hierarchie od nejrychlejšího k nejpomalejšímu přístupu - L1-L2..-RAM-HDD-NETWORK. Výkon se tím sice získat dá, ale kompilátor to obvykle řeší dostatečně dobře, že kromě speciálních matematických knihoven takové optimalizace v reálu nemají smysl.
-
Ad 1) Využijete co nejvíc vlastností daného hardware, které jde použít pro urychlení kódu. Např. pokud má procesor speciální instrukce pro nějaké výpočty, použijete je - často se o to postará správně nastavený kompilátor. Pokud můžete využít výpočet na grafické kartě, využijete ho. Pokud má procesor více jader nebo systém více procesorů, napíšete kód paralelně, aby mohl běžet ve více vláknech. Pokud máte vícevláknový kód, minimalizujete případy, kdy na sebe vlákna musejí čekat. Dále má dnešní hardware spoustu optimalizací kvůli rychlosti, takže je potřeba kód napsat tak, aby tyhle optimalizace fungovaly správně. Například predikce skoků v procesoru, nebo ukládání dat v cache procesoru (data, která bude procesor používat, umístit v paměti k sobě tak, aby se vešla do řádky cache nemusela se načítat z pomalé hlavní paměti). A tak dále.
V případě uživatelských aplikací nezáleží tolik na tom, jak je aplikace fakticky rychlá, ale na tom, jaký má z jejího používání uživatel pocit. Základní věc je to, že náročné operace se nedělají ve vláknu, které obsluhuje uživatelské rozhraní. Takže při takové operaci nemá uživatel pocit, že aplikace zamrzla, ale reaguje na jeho podněty (v takové situaci toho uživatel zpravidla stejně nemůže moc udělat, ale aspoň třeba může přerušit tu déletrvající akci). Dál už záleží na tom, co ta aplikace dělá, ale hrubý výkon málokdy hraje roli. Možná ještě u her nebo přehrávání videa. Ale jinak je často mnohem důležitější to, jak aplikace pracuje s daty - pokud pracuje se soubory na disku, zda dokáže načítat data dopředu, pokud s databází, zda používá takové dotazy, které se vyhodnotí rychle atd. A podstatné je i to, jak je navrženo ovládání aplikace - pokud se musí uživatel někam složitě proklikávat, bude aplikace nakonec pomalá, i když by byl kód velmi rychlý.
Ad 2) Nejjednodušší pravidlo je, že mezi rychlostí a použitou pamětí je nepřímá úměra - máte na výběr, zda si program nějakou hodnotu zapamatuje, nebo zda ji vypočítá. Samozřejmě z pak existuje spousta případů, kdy tohle neplatí - když se zaplní paměť nesmysly, kód to nijak neurychlí, naopak správa velkého objemu paměti má větší režii.
Ad 3) Nemělo by, procesor by měl být chlazený tak, aby zvládl pracovat i na nejvyšší výkon. Dnešní počítačové procesory mají navíc ochrany, které v případě překročení teploty umí procesor zpomalit (např. vkládáním méně náročných prázdných instrukcí).
Ad 4) Ano, to je jedna z věcí, o kterých jsem psal v 1) - uspořádat data tak, aby měl procesor co nejvíc potřebných dat co nejblíž a nemusel čekat na data z hlavní paměti nebo na zámek od jiného procesoru.
-
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.
C/C++ a v tom kusy ASM nebo intrinsics. Ruční psaní kódu s SSE, AVX apod.
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?
Paměti program spotřebuje tolik, kolik programátor uzná za vhodné. Většinou paměť žerou nenažrané multiplatformní GUI knihovny.
3. Může dojít díky velice rychlému kódu dokonce i k přehřátí procesoru?
S předepsaným chladičem naprosto vyloučeno.
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?
Nastudovat si to tady zde:
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Celkově počítej s tím, že v tom strávíš tak rok času a jen těžko ti za tyto schopnosti dneska někdo zaplatí.
- využití SSE/AVX instrukcí - dnes jsou kompilátory dost chytré, a aby člověk vymyslel rychlejší kód, tak většinou musí vědět co dělá, výsledek může být i pomalejší
- kompilace pro x64 - má význam pouze pokud se počítá s velkými čísly (tam je téměř 100% výkonu nahoru), u obyčejných aplikací je výkon +- stejný, někdy i nepatrně nižší. Výhodou je spíše možnost využít více ram (32bit aplikace má tuším max 2GB/proces a <4GB/systém)
Využití SSE/AVX automaticky kompilátory je v plenkách.
x64 má k dispozici 2x tolik registrů než x86, když se to umí využít, tak je to znát očividně.
-
... jelikož nejsem programátor, ale studuji VŠ strojního zaměření...
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. Nicméně jakými způsoby se toho dá docílit. V případě výpočtových aplikací (simulací) to je zřejmě optimalizace daného matematického výpočtu a v případě klasických uživatelských aplikací vůbec netuším.
Se strojním zaměřením doporučuji Matlab, jeho free alternativu Octave nebo Fortran. Céčko ani assembler nedoporučuji, Fortran se na strojírenské výpočty hodí mnohem lépe.
[/quote]
-
S rychlostí kódu dnes nebývá problém, překladače C/C++ používají sofistikované optimalizace a JIT v jazycích jako Java nebo C# (resp. cokoliv v .NET) generuje velmi rychlý kód. Assembler se v obecném případě nepoužívá, už déle platí, že překladač generuje lepší strojový kód než člověk, a dnes je navíc mnohdy žádoucí překládat stejný kód pro Intel (32 a 64-bitový) a ARM, takže těch "asemblerů" je několik (ARM pomalu prosazuje i svou 64-bitovou architekturu, takže celkem to jsou nejméně čtyři různé platformy).
Co se týče paměti, zde jde o to, jestli se použije (plnohodnotný) GC. GC má totiž řádově vyšší nároky na paměť ("high water mark") a jakmile paměť začne docházet, řádově se zpomalí. Proto se často používá "automatic reference counting" (Apple ho má všude a Microsoft ve WinRT), jež zajistí automatickou správu paměti bez nevýhod GC. Navíc v C++ využívá dobrý kód možnost alokace na zásobníku, což je ještě úspornější.
Nejlepší praktická rada tedy je zaměřit se na C++ a pochopit, jak v něm funguje správa paměti. Rychlost výsledného nativního kódu bych neřešil, překladače vesměs generují nejlepší možný kód,
-
už déle platí, že překladač generuje lepší strojový kód než člověk
Na to rychle zapomeňte, zkušený assemblerista porazí kompilátor vždy a to až o dva řády. Ve hře jsou pro vyšší jazyky zcela neznámé možnosti, jako vykonávání až 5 instrukcí jednoho vlákna paralelně v jednom čase, 2-3 paralelní přístupy jednoho vlákna do paměti v jednom čase, přímá kontrola cacheování, přednačítání dat a podobné věci. Průměrný programátor C#/Java nemá kognitivní aparát si tyto věci vůbec představit.
To nijak neovlivňuje skutečnost, že poptávka po takových lidech není a asi nemá moc smysl se tím zabývat.
-
už déle platí, že překladač generuje lepší strojový kód než člověk
Na to rychle zapomeňte, zkušený assemblerista porazí kompilátor vždy a to až o dva řády. Ve hře jsou pro vyšší jazyky zcela neznámé možnosti, jako vykonávání až 5 instrukcí jednoho vlákna paralelně v jednom čase, 2-3 paralelní přístupy jednoho vlákna do paměti v jednom čase, přímá kontrola cacheování, přednačítání dat a podobné věci. Průměrný programátor C#/Java nemá kognitivní aparát si tyto věci vůbec představit.
To nijak neovlivňuje skutečnost, že poptávka po takových lidech není a asi nemá moc smysl se tím zabývat.
Docela úsměvná představa, že se strojař bude hrabat v assembleru, aby ušetřil pár nanosekund.
-
Docela úsměvná představa, že se strojař bude hrabat v assembleru, aby ušetřil pár nanosekund.
Napsal jsem dostatečně jasně, že nemá smysl se tím zabývat.
-
(http://cdn.meme.am/instances/250x250/56559030.jpg)
-
Co se týče paměti, zde jde o to, jestli se použije (plnohodnotný) GC. GC má totiž řádově vyšší nároky na paměť ("high water mark") a jakmile paměť začne docházet, řádově se zpomalí. Proto se často používá "automatic reference counting" (Apple ho má všude a Microsoft ve WinRT), jež zajistí automatickou správu paměti bez nevýhod GC.
No ono to ARC ma taky spoustu nevyhod, a ve vysledku ma vetsi reziji nez dobre napsany GC
-
JAVA a .net chrlí rychlý kód :) fakt jsem se hodně zasmál a pak se tu začne řešit Garbage collection jako vtip hodně dobrý.
Dneska se nevyplatí programovat dobře (nikdo to nezaplatí), proto se dělá "odpad" za málo peněz.
Ty lepší firmy primárně vytváří SW třeba na VXWorksu nebo i pod Linuxem v C++ prokládaný ASM instrukcemi.
Je to ale odporně drahé... a to železo je tak levné ;D
-
Dneska se nevyplatí programovat dobře (nikdo to nezaplatí), proto se dělá "odpad" za málo peněz.
Nevyplatí se ani programovat bez chyb - vždy můžeme zákazníkovi slíbit, že v další verzi budou chyby odstraněny.
-
me prijdou usmevne ty reci o koupi rychlejsiho hw, kdyz uz 10 let procesory stagnuji...
-
Dneska se nevyplatí programovat dobře (nikdo to nezaplatí), proto se dělá "odpad" za málo peněz.
Nevyplatí se ani programovat bez chyb - vždy můžeme zákazníkovi slíbit, že v další verzi budou chyby odstraněny.
Neoplaca sa ani naprogramovat to cele - vzdy mozes zvysok predat ako dlc
-
za umenie sa plati...
vacsinou je v poziadavkach definovana nejaka casova odozva
mozes mat program ktory ti spocita X za 6 minut, co je dostatocne
potom mozes mat program ktory ti spocita X za 28 sekund
takze je na tebe sa rozhodnut ci si pockas 6 minut, alebo na tom budu pracovat 2 programatori a tester 2 tyzdne aby to zrychlili na 28 sekund (a pridat ku cene $28.700)
-
me prijdou usmevne ty reci o koupi rychlejsiho hw, kdyz uz 10 let procesory stagnuji...
Stagnuje frekvence, nikoliv výkon. To co před deseti lety řešilo deset serverů s Xeon Irwindale dnes řeší server jediný s Xeon Haswell a ještě se mírně fláká.
-
Dnes je najdrahsia vec cas. jednoducho radsej sa kupi drahsi hw, a nasadi sa neoptimalizovany sw hned, alebo sa mesiac bude optimalizovat a firma pride o viac penazi, ako by ju stal ten hw.
Vsetko je dnes spotrebny material, aj sw. malokto dnes ladi hotovy sw, jednoducho ked to funguje nechaj tak.
-
Dnes je najdrahsia vec cas. jednoducho radsej sa kupi drahsi hw, a nasadi sa neoptimalizovany sw hned, alebo sa mesiac bude optimalizovat a firma pride o viac penazi, ako by ju stal ten hw.
Vsetko je dnes spotrebny material, aj sw. malokto dnes ladi hotovy sw, jednoducho ked to funguje nechaj tak.
Pokud se jedná o algoritmy se složitostí O(1) nebo O(log(n)), tak je fakt lepší to dohnat hardwarem. Pokud je ta složitost O(n) nebo horší, je nutné změnit software.
-
Dnes je najdrahsia vec cas. jednoducho radsej sa kupi drahsi hw, a nasadi sa neoptimalizovany sw hned, alebo sa mesiac bude optimalizovat a firma pride o viac penazi, ako by ju stal ten hw.
Vsetko je dnes spotrebny material, aj sw. malokto dnes ladi hotovy sw, jednoducho ked to funguje nechaj tak.
Pokud se jedná o algoritmy se složitostí O(1) nebo O(log(n)), tak je fakt lepší to dohnat hardwarem. Pokud je ta složitost O(n) nebo horší, je nutné změnit software.
A co teprve NP-úplné nebo ještě horší algoritmy... Tam už se vyplatí najmout si "profíka".
-
Dnes je najdrahsia vec cas. jednoducho radsej sa kupi drahsi hw, a nasadi sa neoptimalizovany sw hned, alebo sa mesiac bude optimalizovat a firma pride o viac penazi, ako by ju stal ten hw.
Vsetko je dnes spotrebny material, aj sw. malokto dnes ladi hotovy sw, jednoducho ked to funguje nechaj tak.
Pokud se jedná o algoritmy se složitostí O(1) nebo O(log(n)), tak je fakt lepší to dohnat hardwarem. Pokud je ta složitost O(n) nebo horší, je nutné změnit software.
zakaznik/uzivatel/zadavatel ale obvykle nema sanci poznat, ze provozuje suboptimalni algoritmus. obvykle ani nic takoveho nechce, neoceni a zamitne uz pri naceneni..
-
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í.
-
už déle platí, že překladač generuje lepší strojový kód než člověk,
Sem se skoro pokecal ...
cece, si uvedom, ze prekladac NEVI a vedet nemuze, co ten kod ma delat. VZDY, ve 100% pripadu pak dela zcela obecny preklad. Jinak receno, musi brat v potaz vsechny moznosti. Programator ovsem VI (nebo by mel), co ze ten kod ma delat, a tudiz muze (a prave v tom spociva drtiva vetsina optimalizaci) znacnou cast jednoduse vynechat.
Jina vec je, jestli to nekdo zaplati, ale o tom uz rec byla.
Dneska se nevyplatí programovat dobře (nikdo to nezaplatí), proto se dělá "odpad" za málo peněz.
Nevyplatí se ani programovat bez chyb - vždy můžeme zákazníkovi slíbit, že v další verzi budou chyby odstraněny.
Hlavne se mu pak da prodat maintenance. Kdo by to platil, kdyz mu vse funguje, ze.
me prijdou usmevne ty reci o koupi rychlejsiho hw, kdyz uz 10 let procesory stagnuji...
Usmevny ti to prijit muze, ale rozhlidni se kolem. 99% uloh ktery se resej jsou naprosto primitivni veci. Spocitani vejplat, spocitani ceny, ... z pohledu CPU trivialni operace scitani/odecitani/nasobeni/deleni. A pak se poinformuj, jak se to delalo pred 10ti, 15ti, 20ti lety. Zjistis, ze naprosto totez v naprosto stejnem rozsahu zvladal o 3-5 radu pomalejsi HW. Jak je to mozny? Co myslis, zvlad by dneska Z80 vejplaty? Ja myslim ze s prstem v nose. Jenze zvlad by to pro nej nekdo naprogramovat? Vzdyt jen otevrit dialog "spocitat ano/ne" by takovych CPu potreboval 100.
-
me prijdou usmevne ty reci o koupi rychlejsiho hw, kdyz uz 10 let procesory stagnuji...
Usmevny ti to prijit muze, ale rozhlidni se kolem. 99% uloh ktery se resej jsou naprosto primitivni veci. Spocitani vejplat, spocitani ceny, ... z pohledu CPU trivialni operace scitani/odecitani/nasobeni/deleni. A pak se poinformuj, jak se to delalo pred 10ti, 15ti, 20ti lety. Zjistis, ze naprosto totez v naprosto stejnem rozsahu zvladal o 3-5 radu pomalejsi HW. Jak je to mozny? Co myslis, zvlad by dneska Z80 vejplaty? Ja myslim ze s prstem v nose. Jenze zvlad by to pro nej nekdo naprogramovat? Vzdyt jen otevrit dialog "spocitat ano/ne" by takovych CPu potreboval 100.
Nevim jakou to ma spojitost s tim co jsem psal...
Casto vidim ze lidi si justifikujou prasacky programovani tim, ze se na to nasadi silnejsi hw, jenze silnejsi hw neni a v blizky dobe asi ani nebude...
-
Tak k tomuhle seznamu bych měl pár výhrad...
Příklady optimalizací?
- úprava složitosti algoritmu, tím se obvykle získá nejvíc a nezávisí to na použitém jazyce (akademický příklad - místo pomalého bubble sortu se použije quick sort)
Asymptotická složitost je dost abstraktní věc a překvapivě často má smysl vzít algoritmus s teoreticky horší složitostí, ale rychlejší v praxi. Bývá rychlejší přidávat prvky doprostřed pole (rozumné velikosti), než místo toho použít spojový seznam, protože lepší složitost dokonale přebije tragické využití cache spojovým seznamem. A to ještě ani nemluvím o té zanedbané konstantě. Nechci říct, že je složitost k ničemu, ale rozhodně to není nějaký spolehlivý ukazatel toho, jak rychle kód pojede.
- využití SSE/AVX instrukcí - dnes jsou kompilátory dost chytré, a aby člověk vymyslel rychlejší kód, tak většinou musí vědět co dělá, výsledek může být i pomalejší
SSE, AVX a v podstatě i GPU se hodí jen na určitou třídu úloh. Pokud to nejsou nějaké jednoduché iterace přes pole, tak bývá problém. Další věc je, že pokud se hodně nepočítá nad malými oblastmi paměti, tak je úzké hrdlo stejně sběrnice.
...
- u hrátek typu uložím si data do procesorové cache je třeba brát v úvahu, jak jsou ty cache velké, rozdílné parametry procesorů atd. Obecně platí nějaké hierarchie od nejrychlejšího k nejpomalejšímu přístupu - L1-L2..-RAM-HDD-NETWORK. Výkon se tím sice získat dá, ale kompilátor to obvykle řeší dostatečně dobře, že kromě speciálních matematických knihoven takové optimalizace v reálu nemají smysl.
Tak tady bych zatraceně nesouhlasil. Jestli je jedna věc, kterou by _každý_ programátor měl znát, tak je to funkce cache. Momentálně je to to nejužší hrdlo prakticky v _každém_ programu. V generování kódu překladač strčí do kapsy tak 90% programátorů, ale se zprasenýma datovýma strukturama neudělá ani ň. Tohle se navíc skvěle kombinuje s naivním přístupem k objektovému programováním, kdy se cache používá dost strašným způsobem.
Pro rozumné využití cache ani není třeba vědět, jak je velká. Je jen třeba tušit velikost řádků cache a co nejvíc se držet sekvenčního průchodu pamětí. Doporučím článekhttp://www.akkadia.org/drepper/cpumemory.pdf (http://www.akkadia.org/drepper/cpumemory.pdf). Název "What Every Programmer Should Know About Memory" není vůbec nadsazený.
-
Tak tady bych zatraceně nesouhlasil. Jestli je jedna věc, kterou by _každý_ programátor měl znát, tak je to funkce cache. Momentálně je to to nejužší hrdlo prakticky v _každém_ programu. V generování kódu překladač strčí do kapsy tak 90% programátorů, ale se zprasenýma datovýma strukturama neudělá ani ň. Tohle se navíc skvěle kombinuje s naivním přístupem k objektovému programováním, kdy se cache používá dost strašným způsobem.
Naprostý souhlas. Nejvíc se zoptimalizuje změnou způsobu práce, pak změnou algoritmu. A když už na tom není co vylepšovat, pokračoval bych právě optimalizací vzhledem k cache, speciální instrukce až potom, ty budou mít obvykle menší vliv. Pokud to není nějaký matematický výpočet, použije se těch speciálních instrukcí pár. Oproti tomu když v nějaké smyčce při každé iteraci budu muset data načítat z hlavní paměti místo z cache, promrhám tím mnohem víc času.
Kompilátor nějakého vysokoúrovňového jazyka by datové struktury teoreticky mohl optimalizovat, ale C kompilátor vám rozhodně nemůže přeskládat prvky ve struct, ze spojového seznamu udělat pole a z pole pointerů udělat pole struct.
-
Tak ohledně té cache, tak jste dobrý teoretikové. Samozřejmě, že sekvenční zpracovávání je dobré, ale
1) zpomalení cache versus paměť je jen lineární. Blbě zvolenej algoritmus je daleko horší zlo, protože ten prostě na větších datech nedoběhne.
2) napsat i jen tak blbou věc jako násobení matic tak, aby se správně využila cache je věc velmi netriviální, dobrá implementace matematický knihovny je na roky práce. Takže napsat, že každej programátor by to měl zvládat je dobrej hospodskej kec.
3) Každá architektura procesorů má tu cache organizovanou trochu jinak. Takže znalosti typu rozměr cache, Xcestnost atd...., pokud neladíte program na jednu konkrétní architekturu, jsou k ničemu. A to do toho ještě dělá dost velkej binec HW prefetch, kterej dost běžnejch cache-nepravostí umí vyřešit.
4) pro normálního programátora úplně stačí, když tak nějak tuší, že sekvnenční zpracování je plus.
A to píšu jako člověk, kterej zrovna teď dává dohromady maticový výpočty, kde když se na cache kašle, tak jde výkon do kytek....
-
Nevím, jak často programátoři programují násobení matic. Dost programátorů ale programuje webové aplikace, které jsou přirozeně vícevláknové, a kde může mít uspořádání sdílených dat vliv právě na to, jak se bude pracovat s cache.
Jinak bylo řečeno, že algoritmus je daleko podstatnější, než cache, na druhou stranu cache je většinou podstatnější, než použití speciálních instrukcí nebo než ruční optimalizace strojového kódu.
-
A to píšu jako člověk, kterej zrovna teď dává dohromady maticový výpočty, kde když se na cache kašle, tak jde výkon do kytek....
A co konkrétně s nimi děláš?
-
Pro rozumné využití cache ani není třeba vědět, jak je velká. Je jen třeba tušit velikost řádků cache a co nejvíc se držet sekvenčního průchodu pamětí.
Dnešní přístup do pamětí je už natolik složitý, že už ani tvrzení o sekvenčním průchodu pamětí není neotřesitelné. Když se ví jak na to, tak právě speciálním nesekvenčním přístupem se dosáhne zvýšení výkonu na dvojnásobek a možná víc. Problematika je na několik hodin vysvětlování.
Tohle se navíc skvěle kombinuje s naivním přístupem k objektovému programováním, kdy se cache používá dost strašným způsobem.
Tak to se raději ani nedívejte na správu paměti s GC nebo třeba v Erlangu, tam se cache přímo ignoruje.
-
Nebudu tvrdit, ze podceneni cache nemuze byt casty problem. Ale urcite neni jediny, jakekoli IO je daleko brutalnejsi: http://blog.codinghorror.com/the-infinite-space-between-words/
Dalsi oblibena potiz, je trebas blokovani UI threadu nejakou netrivialni cinnosti (coz je castym duvodem vnimane pomalosti Javy/Swingu).
A podobnych potencialnich problemu, jakymi lze zabit vykonost, urcite najdeme jeste vic. Nebylo dobre to omezit jen na jeden.
-
technomaniak:
Adaptuju řešiče tak, aby řešili speciální případ problému vlastních čísel. Teda sem spíš uživatel, ale např. rozdíl mezi jednotlivejma implementacema Blasu (nebo když se vezme referenční od netlibu) dost jasně cejtim a patřičně si vážim lidí, který jsou schopný napsat takový "šílenosti", jako GotoBLAS.
filip: Ale to už vůbec není záležitost cache a její organizace, ale multivláknového psaní. A tam jsou daleko větší problémy, jako správná distribuce práce, zamykání (když se dva hádaj o data, tak je to daleko větší problém než vyhazování z cache) a synchronizace, vůbec i volba algoritmu (zpravidla ten nejefektivnější není efektivně paralelizovatelnej, čili člověk musí volit podle nasazení mezi jednothreadovým a multithreadovým výkonem) atd....
Správné multithread programování je celé vyšší dívčí (multiprocesové pak vysoká dívčí) a redukovat jeho problémy na cache je dosti mimo. A naopak - multivláknové programy se sdílením dat, kde záleží na výkonu (teda ne nějaké odbavování webové aplikačky s pár konkurentníma přístupama) píše jen pár procent programátorů, možná ani to ne, takže proč by to měl znát každý programátor?
-
Ondra: IO - naprostej souhlas. V okamžiku, kdy se čeká na IO, je jakákoli cache úplně jedno. Proto se také DB algoritmy měří na počty načtenejch DB stránek.
UI - to je problém ne až tak výkonu, jako latence. Z principu jdou tydle dvě věci proti sobě: buď mám kód výkonej (dělá věci postupně) nebo s nízkou latencí (často střídám úlohy se všemi z toho plynoucími nevýhodami). Samozřejmě napsat kód tak, aby byl pomalej a ještě měl velký latence jde samozřejmě taky :-)
-
Logik: řešení (ne)zamykání považuju za algoritmus. Distribuce práce je přesně ten případ, kdy se někdy vyplatí myslet na cache - někdy se vyplatí počkat na jádro, které už má data v cache, než práci nacpat prvnímu volnému procesorovému jádru.
Netvrdím, že o procesorové cache potřebuje vědět každý programátor, ale pokud už někdo chce optimalizovat kód na téhle úrovni, ve většině případů mu daleko víc pomůže optimalizace práce s cache než používání speciálních instrukcí a přepis do strojového kódu.
Latence UI je přesně to, co uživatel subjektivně vyhodnotí jako "pomalý program".
-
@Logik
Tomu, cemu rikas vykon se u nas rikala propustnost a vykon byl neco obecnejsiho. Ale az na rozdil v terminologii s tebou samozrejme souhlasim.
-
Filip: Jo, takže všechno je algoritmus, jen řešení cache algoritmus není. Blbina - k efektívnímu využití cache se dělají speciální algoritmy úplně stejně, jako k minimalizaci počtu nutnejch zamykání. Je to problém na úplně stejný úrovni jako minimalizace počtu IO nebo minimalizace počtu nutnejch synchronizací - nejde nejprve vyřešit to a pak začít řešit cache. A oproti zmíněnejm věcem méně důležitá, protože zpomalení oproti špatně napsanému programu tu je řádově menší. A až na dodržování pár "good practice" to moc pro praktické programování nemá význam znát - nikdo to nezaplatí.
Ondra: Jo, souhlas. On výkon je defakto něco nedefinovatelnýho - někdo chce latenci, někdo propustnost. Když se to ale nespecifikuje, tak si osobně pod tím představím propustnost, ale to je asi dost tím, že toho UI moc nedělám (max ve webovejch apkách, kde zas se výkon z principu moc neřeší, protože to nikdo nezaplatí).
-
stejně, jako k minimalizaci počtu nutnejch zamykání. Je to problém na úplně stejný úrovni jako minimalizace počtu IO nebo minimalizace počtu nutnejch synchronizací - nejde nejprve vyřešit to a pak začít řešit cache.
on se jeste najde nekdo, kdo by minimalizoval pocet zamku? tohle se razilo nekdy kolem roku 1998. prvin a posledni implementacni detaily + tuning databaze jsem videl az kolik let pote a slo o sybase ase dost do detailu rozepsany zmeny mezi releasy / verzemi databaze. jestli a proc upgradovat a jak nastavit tuningovy parametry a kde ocekavat uzky hrdlo. zadouci uz tehdy bylo neminimalizovat zamikani, ale vyvazit fragmentaci a zamykani fragmentu.
-
zakaznik/uzivatel/zadavatel ale obvykle nema sanci poznat, ze provozuje suboptimalni algoritmus. obvykle ani nic takoveho nechce, neoceni a zamitne uz pri naceneni..
Ma sanci, i kdyz ta suboptimalita vypada ruzne. Z praxe SW na evidenci lidi zvladal jako blesk demo s 15 lidmi, s 500 lidmi to bylo na starsim HW citelne pomale a s 1000 lidmi to bylo i na novem HW temer nepouzitelne, nebot kazda operace trvala nekolik sekund.
Je treba vedet, kdy optimalizovat. 50us vs 100ms na jednu akci nikdo nepozna i kdyz jde o vice nez 3 rady. 100ms a 5s pri kazde operaci uz je poradny rozdil, i kdyz to nejsou ani 2 rady.
už déle platí, že překladač generuje lepší strojový kód než člověk,
Sem se skoro pokecal ...
cece, si uvedom, ze prekladac NEVI a vedet nemuze, co ten kod ma delat. VZDY, ve 100% pripadu pak dela zcela obecny preklad. Jinak receno, musi brat v potaz vsechny moznosti. Programator ovsem VI (nebo by mel), co ze ten kod ma delat, a tudiz muze (a prave v tom spociva drtiva vetsina optimalizaci) znacnou cast jednoduse vynechat.
A co priklad takoveho kodu pro GCC nebo Intelovsky kompilator se zapnutymi optimalizacemi? (myslim i optimalizace jako -ffast-math, pouzivani unsigned kde treba, -march=native)
Druha pricina prednosti prekladace je citelnost. Muzu volat funkce a(), b() a prekladac je inline-uje a tak nechutne poprehazuje instrukce mezi nimi (kvuli vyuziti pipeline), ze se v tom nikdo na prvni pohled nevyzna. To nebude nikdo cist a udrzovat.
Naproti tomu, kdyz vam programator napise vysoce optimalizovany kod prekladajici 10 cinnosti do jedne, tak bude jedina mozna oprava bugu komplet prepis. Uprava muze znamenat jeste horsi vyuziti pipeline nez neoptimalizovany kod.
Zjistis, ze naprosto totez v naprosto stejnem rozsahu zvladal o 3-5 radu pomalejsi HW.
Nebylo to naprosto totez. Kdysi se pocitali vyplaty tak, ze se nacetl kus vstupu (nebo cely) do pameti, tam se to ponasobilo v jednom cyklu a vysledek se nekam vypsal.
Ted se pocitaji vyplaty tak, ze se spusti behove prostredi, v tom se nacte 20 000 trid, spusti se 10 vlaken na GUI, GC, RMI, vsechno je to treba synchronizovat, nektere tridy se zacinaji po nekolika volanich JITovat, co znamena neoptimalni vyuziti instrukcni cache a to mame jenom prostredi. Uzivatel vyuziva nejaky framework, ktery natahne dalsich 1 000 trid, ktere jsou natolik obecne, ze zvladnou prakticky vse. Uzivatel zavola vypocet vyplaty pro kazdeho zamestnance zvlast a program ceka na data pro lazy init stub. Ten sestavi SQL query. Udela se spojeni s DB (kdyz uz neni), SQL query se zapouzdri do paketu a posle se to do DB. DB rozparsuje query a v lepsim pripade podle indexu vyhleda zaznam. Zaznam se zapouzdri tak, aby se mohl poslat, odesle se do programu. Program ze sestaveneho paketu vytahne data, precte metadata a data nacpe do objektu. Toto vsechno vyhodilo z cachi, co se vlastne melo pocitat a tak se to znova natahne. Vynasobi se 2 hodnoty, ulozi se do objektu a je to treba persistovat. Tak se zjisti, co se vlastne zmenilo a to se posila do DB (opakuje se ten cirkus). Neco jako uvolnovani pameti programator nedela a GC musi prochazet reference vzdy kdyz proto dojde pamet.
A aby se nezapomelo, cele to bezi v okynku, ktere ma pruhledne pozadi a dela pekne efekty, ktere se daji porovnat s prvnimi simulacemi vybuchu atomove bomby.
Kdyz se k tomu prida vice urovni ruznych frameworku, pro jistotu nejaka ta bezpecnost a osetrovani chyb, ktere predtim nemohli nastat, tak mame zdroj problemu. Dnesni PC nepocitaji to same. Pocitaji zbytecnosti.
-
zakaznik/uzivatel/zadavatel ale obvykle nema sanci poznat, ze provozuje suboptimalni algoritmus. obvykle ani nic takoveho nechce, neoceni a zamitne uz pri naceneni..
Ma sanci, i kdyz ta suboptimalita vypada ruzne. Z praxe SW na evidenci lidi zvladal jako blesk demo s 15 lidmi, s 500 lidmi to bylo na starsim HW citelne pomale a s 1000 lidmi to bylo i na novem HW temer nepouzitelne, nebot kazda operace trvala nekolik sekund.
Je treba vedet, kdy optimalizovat. 50us vs 100ms na jednu akci nikdo nepozna i kdyz jde o vice nez 3 rady. 100ms a 5s pri kazde operaci uz je poradny rozdil, i kdyz to nejsou ani 2 rady.
nema sanci. zakaznik neni koncovy uzivatel. koncovy uzivatel takove aplikace nema znalosti aby provedl popsanou analyzu a zadavatel zakaznik je od pouzivani dostatecne vzdalen a obvykle nevidi aplikaci s 500 lidmi, protoze uz po tom demu prohlasi hotovo a nechce platit zadne testy s realnou zatezi a optimalizace a rovnou to necha zavest do provozu a v provozu zase pro zmenu nevideli jak se chova demo s 15 lidmi, tak maji referencni latku chovani s 500 lidmi.
-
U nás - C, C++, některé věci v ASM, a snaha část problémů přenášet a počítat na HW (FPGA).
-
technomaniak:
Adaptuju řešiče tak, aby řešili speciální případ problému vlastních čísel. Teda sem spíš uživatel, ale např. rozdíl mezi jednotlivejma implementacema Blasu (nebo když se vezme referenční od netlibu) dost jasně cejtim a patřičně si vážim lidí, který jsou schopný napsat takový "šílenosti", jako GotoBLAS.
Vlastní čísla matice jsou hezký problémek, taky jsem si jeden program na to napsal. A ten tvůj je pro symetrické nebo nesymetrické okolo diagonály? Jak velké ty matice obvykle máš?
2all: Mě totiž připadá trochu divné či spíše směšné řešit tu nějakou procesorovou cache s její mikropamětí když matice double mohou zabrat i 10,20 a více GB v RAM. Školní příklady matice 5x5 se fakt v realitě neřeší. Nejsem vzděláním žádný elektro-informatik, takže pokud žiji v omylu tak budu rád když mě z toho vysvětlením vyvedete.
-
2technomaniak: V realu se resi daleko primitivnejsi ulohy nez matice a presto to nefunguje ani zdaleka tak, aby o tom uzivatel moh prohlasit, ze je to svizne. Naopak, pokud se resi nejaka algoritmicky narocna uloha, byva aplikaci prevazne "nehezka", ale zcela fukcni.
-
Tak ohledně té cache, tak jste dobrý teoretikové. Samozřejmě, že sekvenční zpracovávání je dobré, ale
1) zpomalení cache versus paměť je jen lineární. Blbě zvolenej algoritmus je daleko horší zlo, protože ten prostě na větších datech nedoběhne.
Třeba takový Coppersmith-Winogradův algoritmus je nepoužitelný jen a jen kvůli tomu "nedůležitému" lineárnímu zpomalení. To lineární zpomalení bývá občas tak veliké, že jakákoliv rozumná data nejsou dost velká.
2) napsat i jen tak blbou věc jako násobení matic tak, aby se správně využila cache je věc velmi netriviální, dobrá implementace matematický knihovny je na roky práce. Takže napsat, že každej programátor by to měl zvládat je dobrej hospodskej kec.
Neříkám, že by měl být každý programátor schopný napsat efektivní násobení matic. Ale každý programátor by měl minimálně vědět, proč by měl jednu aspoň transponovat aby nepřenášel z paměti 8x víc dat, než je třeba. Stačí ten krok od tragického k rozumnému.
[/quote]
3) Každá architektura procesorů má tu cache organizovanou trochu jinak. Takže znalosti typu rozměr cache, Xcestnost atd...., pokud neladíte program na jednu konkrétní architekturu, jsou k ničemu. A to do toho ještě dělá dost velkej binec HW prefetch, kterej dost běžnejch cache-nepravostí umí vyřešit.
4) pro normálního programátora úplně stačí, když tak nějak tuší, že sekvnenční zpracování je plus.
A to píšu jako člověk, kterej zrovna teď dává dohromady maticový výpočty, kde když se na cache kašle, tak jde výkon do kytek....
[/quote]
Já v principu souhlasím. Jde mi o ten základ. O "své" architektuře by měl programátor minimálně vědět, jak má velké řádky cache. Nějaký prefetch a spol. až tak důležitý není.
-
Tak to se raději ani nedívejte na správu paměti s GC nebo třeba v Erlangu, tam se cache přímo ignoruje.
Fakt? Měl jsem za to, že generační GC vypadá tak jak vypadá právě kvůli cache. První generace se přebere ještě dokud je v cache.
-
2all: Mě totiž připadá trochu divné či spíše směšné řešit tu nějakou procesorovou cache s její mikropamětí když matice double mohou zabrat i 10,20 a více GB v RAM. Školní příklady matice 5x5 se fakt v realitě neřeší. Nejsem vzděláním žádný elektro-informatik, takže pokud žiji v omylu tak budu rád když mě z toho vysvětlením vyvedete.
A tohle je ten zásadní problém. Pro efektivní práci s těmi 20GB je třeba zatraceně dobře využít cache, protože té je sice jen pár MB, ale je o několik řádů rychlejší než hlavní paměť. Celá myšlenka cache stojí na tom, že v praxi se obvykle v jednom okamžiku nepracuje se všemi daty, ale s jejich malým kouskem. A taky že se v těch datech nepohybujeme úplně náhodně.
Ty matice jsou takřka ideální příklad. Už blbá transpozice jedné matice před násobením srazí množství přístupů do hlavní paměti na osminu. Množství přenesených dat se sice v podstatě nezmenší, ale využije se toho, že přenos velkých bloků paměti je daleko efektivnější. Ještě lepší je kouknout se na blokové matice. Pak je z jedné veliké matice najednou spousta malých, které se už do cache vlezou a dá se toho výborně využít.
Podobné principy platí i jinde, než jenom u násobení matic. Třeba http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf (http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf) to rozebírá na grafech scény pro 3D enginy.