Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
A kolikze vyvojaru si dela tezkou hlavu s podporovanymi instrukcnimi sadami? :)
Pravda, asi jen ti, pro které "optimalizace" není sprosté slovo :-)
No nevim, podle mne se optimalizace na urovni instrukci procesoru nedela uz nejakou dobu. Ony mimochodem kompilery umi optimalizovat hodne kvalitne i s vyberem cilove instrukcni sady, takze na teto urovni uz se toho myslim moc nedela
Bohuzel, dneska se to uz moc nedela. Ale ne proto, ze by to nebylo nutne, ale kvuli lenosti, casove tisni a neznalosti soucasnych "lepicu kodu". Kompilatory optimalizuji velice spatne a pokrocile instrukce v podstate vubec nepouzivaji (krome Intel kompileru, ale ten ma taky rezervy). Treba ja pisu vsechny kriticke casti kodu primo v asssembleru (a rovnou vic verzi pro ruzne verze SSE / AVX) a bezne zrychleni je 4-6x oproti C++. Kompilatory totiz nikdy nebudou umet zoptimalizovat samotny algoritmus a datove struktury, coz je nezbytne, aby mohly byt vyuzity vsechny instrukce. Nekdy je dokonce nutne mit i jiny algoritmus napr. pro SSE2 a SSE4.1.
Mě spíš přijde, že pro většinu lidí to není opravdu nutné :) Určitě se to hodí třeba při psaní kodeků na (de)kompresi videa, ale že by se mělo optimalizovat v assembleru běžně a nedělá se to kvůli lenosti nebo časové tísni?
Nektere (bezne) programy by to potrebovaly jako sul. Treba kdyz cekam na spocitani par cisel v Calcu 2 min., nebo kdyz mi VS laguje pri psani textu na 8-jadrovem CPU, tak me berou vsichni certi... Existuji programy, ktere by sly zrychlit minimalne 10x. Ale jejich autori jsou vetsinou radi, ze jim to vubec nejak funguje a zakaznici to taky moc neresi (maximalne brblaji nekde na foru), takze tezko ocekavat nejake zlepseni v tomto smeru (bohuzel).
Zatimco tvuj kod je vzdy perfektni, cisty, prehledny, vykonny a neobsahuje bugy. :) To jen ostatni jsou lini a nemaji cas a nebo chteji ustetrit. A jsou radi, ze to vubec funguje.
Vubec to neni tim, ze jsou to jen lidi a ne vzdy disponuji prostredky (lidske, financni, znalostni, casove).
No ja jsem bohuzel taky liny a tim padem nemam dost casu na optimalizovani uplne vseho a tim nejlepsim zpusobem ;). A to je prave ono - z ruznych "lidskych" nebo ekonomickych duvodu se na optimalizaci vetsinou uplne kasle, coz ale neznamena, ze by nebyla potreba. Je to vec uvahy. Vzhledem k rychlosti vyvoje HW se vetsine firem proste vic vyplati pridat nove funkce a neresit rychlost. Na uzavrenych platformach je pekne videt, ceho vseho je i prumerny HW schopen, kdyz jsou vyvojari donuceni k optimalizacim.
Mym prispevkem jsem jen chtel rict, ze pokrocile instrukcni sady maji velky potencial a vyroky, ze dneska se uz neoptimalizuje, protoze to neni potreba (pripadne, ze to udela kompilator), jsou trochu mimo misu.
Ne, z "lidskych" duvodu, ale z lidskych... ne kazda firma ma tym profesionalu, kteri dokazi rychle a bezchybne psat kod v C++ ci dokonce assembleru. A uz vubec ne kazda firma by na takove lidi mela penize a ani cas, ktery by takovy vyvoj zabral. Ten je totiz uzce spjaty s narocnosti vyvoje. A cas jsou samozrejme penize, kterych tez neni vzdy dostatek. Proc myslis, ze se uchytily jazyky jako Java a C# ?
Rizeni projektu neni jednoduchy problem a neda se shrnout jen tim, ze nekdo "chtel usetrit a byl liny a vykaslal se na optimalizace". Optimalizace stoji hromadu penez a pomer cena/vykon neni takovy, aby to vzdy melo smysl. Navic, pojem "optimalizace" je tak obecny, ze je to slovo hrozne zneuzivane.
Produkty, ktere maji urcity uzitek z instrukcnich sad ci nejakych specialnich vlastnosti HW, vetsinou dane vlastnosti vyuzivaji. To predevsim ale proto, ze na tom zavisi jejich podstata a vyznam. Tento druh optimalizace urcite problem neni.
Ten problem optimalizace, o kterem tu mluvis ty, je vec jina. Zde jde predevsim o problemy spojene s navrhem kodu, kdy problem muze byt spatne zvoleny ci neefektivne napsany algoritmus. Spatny objektovy navrh. Ruzne problemy se synchronizaci vlaken, ci velka rezije pri jejich sprave. To jsou problemy, ktere se spatne hledaji, a jeste hur opravuji (predevsim pokud uz je produkt hotovy, ci ve fazi vyvoje, kdy takova oprava je velmi problematicka).
Souhlasim. Akorat je smutne, ze casto musi clovek na neco cekat a jeho HW je pritom vyuzivan treba na 10%. Cas jsou taky (vice nez) penize :).
„Kompilatory optimalizuji velice spatne“
Kompilátory dnes optimalizují špičkově. Dobré kompilátory, tedy nikoli gcc a podobné.
„Treba ja pisu vsechny kriticke casti kodu primo v asssembleru (a rovnou vic verzi pro ruzne verze SSE / AVX) a bezne zrychleni je 4-6x oproti C++.“
Jaké je zrychlení celého programu? A jste v háji.
Kompilátory dnes optimalizují celý program, vy optimalizujete jen nějaký maličký zlomeček kódu celého programu.
Kromě toho ne všechny algoritmy lze paralelizovat na SSE/AVX, spíše jen menšinu. Nehledě na to, že vektorové instrukce x86 procesorů jsou v zásadě velmi chabé a dřevěné.
Další věc je, že buď optimalizaci maličkého kousku (který C/C++ programátor napíše do několik minut) věnujete obrovské množství času, řekněme týdny abyste to zoptimalizoval. Tedy na všechny ty Vaše procesory – ale až vyjde další model, nebo druhý další model, můžete začít znovu přepisovat.
„Kompilatory totiz nikdy nebudou umet zoptimalizovat samotny algoritmus a datove struktury, coz je nezbytne, aby mohly byt vyuzity vsechny instrukce.“
Zato kompilátor umí jiné věci, které nezvládne žádný člověk. Umí optimalizace nad programem, který obsahuje třeba 100 miliónů objektů (tedy součet proměnných, funkcí, typů, modulů) a optimalizuje je stejně dobře jako program o 10 objektech.
Tudíž assemblerista dokáže možná maličko zoptimalizovat kraťoučký úsek kódu – a to třeba i mírně lépe, než kompilátor. Ale jakmile se ten kousek rozroste na několikanásobek, narazí na možnosti a meze lidského mozku udržet v hlavě potřebný počet detailních informací o všech objektech v kusu kódu.
Člověk pak u delšího kusu kódu nasadí taktiku „obětuji efektivitu kódu proto, aby to můj mozek zvládl“. Tedy začne používat koncence: volací konvence, rozdělování kódu do funkcí, objektů, vytváření abstraktních rozhraní – a to vše snižuje efektivitu kódu, ale zvyšuje udržitelnost – pro člověka, jehož mozek se nedokáže vyrovnat optimalizačním možnostem kompilátoru na skutečně reálně rozsáhlém modulu či programu.
Navíc kompilátory jsou rok od roku lepší. Dnes už jsou schopny velmi dobře odstranit důsledky taktiky „lidského obětování efektivity“. A zároveň oprimalizovat nad celým programem s obrovským množstvím objektů.
„Nekdy je dokonce nutne mit i jiny algoritmus napr. pro SSE2 a SSE4.1.“
A na to jsou kompilátory lepší. Jsou schopny na požádání vygenerovat kód pro libovolný procesor. Znají pravidla rychlosti i závislosti instrukcí pro mnoho modelů procesoru.
Mimochodem, před časem jsem zjistil, že operace s floating point čísly nad SSE není to pravé ořechové. U dvojité přesnosti byla FPU výrazně rychlejší, než celé SSE. Nehledě na to, že SSE si ještě věci zjednodušovala a nedělala výpočty v mezních stavech podle normy IEEE 754 a tak se to muselo opravovat a to dále zpomalovalo výpočet.
Jen tak pro připomenutí.
Miloslav Ponkrác
Problem je ten, ze optimalizovat cely program je blbost. Tato volba je stejne v kompilatoru defaultne vypnuta. Naprosto drtivou dobu casu (rekneme 99.99% casu) stravi CPU v jedine (nebo nekolika malo) hlavni smycce nejake vypocetni funkce (nebo nekolika malo), pro kterou je nutne prizpusobit cely "engine" tak, aby tato fce mela optimalne predpripravena data. Tato fce se vetsinou da zoptimalizovat za nekolik malo dni (nekdy i hodin - podle rozsahu). Typicky se jedna o nekolik desitek instrukci ve smycce bez jakehokoliv vetveni - to se musi eliminovat. Ale samozrejme zalezi na tom, o co se presne jedna. Rozsahlejsi projekty je nutne rozdelit do mensich casti, to mate pravdu. Pokud ma (pod)program obrovske mnozstvi objektu, tak to uz je samo o sobe vetsinou spatne. Vse se musi maximalne zjednodusit, aby to slo dobre paralelizovat a vektorizovat. Je jasne, ze u mismase bude kompilator lepsi.
"Dobré kompilátory, tedy nikoli gcc"
A ktere ze to jsou ? Drtiva vetsina programu je prelozena v MS VS pod Win nebo gcc pod Linuxem nebo Macem a koder s tim nemuze naprosto nic delat.
Co se tyce tech schopnosti kompilatoru, tak VS2010 uz "dokonce" umi automaticky pouzivat cmov, coz je instrukce stara tusim 16 let - tak si udelejte predstavu, jak je to s novejsimi a slozitejsimi vektorovymi instrukcemi. Zkousel jste nekdy disassemblovat nejaky normalni (nejen) komercni program ? Z toho by se jeden osypal. Vsechno v podstate jen 386kove instrukce, o vektorovem SSE se cloveku muze jen zdat...
"A na to jsou kompilátory lepší. Jsou schopny na požádání vygenerovat kód pro libovolný procesor. Znají pravidla rychlosti i závislosti instrukcí pro mnoho modelů procesoru. "
Tak tohle ja naprosty nesmysl. Zaprve - tohle umi dobre jen Intel kompilator, ale ten je zabugovany a schvalne mrsi kod pro AMD. Nejpouzivanejsi kompilator (MS VC++) neumi ani vektorizovat, natoz generovat ruzne codepaths pro ruzne architektury. Ale to je stejne jedno, protoze rucne se to da napsat univerzalne tak, ze to pojede dobre vicemene na vsem. Staci dodrzet nekolik zakladnich pravidel (16B alignment, loop unrolling, ...). Ty CPU se zase tak nelisi.
Kazdopadne, kompilator uz z principu nemuze dobre vektorizovat, protoze musi dodrzet algoritmus. Dokud nebudou x86 CPU umet scatter/gather (FP gather bude v AVX2), tak to u vetsiny smycek nepujde, protoze proste data nebudou spravne usporadana. Nad tim se musi clovek vetsinou hodne zamyslet, nez prijde na efektivni reseni. Kompilator nema sanci (a opravneni).
Ten, kdo nechce psat assembler, ma moznost pouzivat intrinsics. Kompilator tam sice nasype spoustu nesmyslnych MOVu, ale je to rozumny kompromis a mozne efektivni reseni.
"U dvojité přesnosti byla FPU výrazně rychlejší"
To tezko. Alespon na Core2 a novejsich. Ty zvladnou 4 DP flopy (8 v pripade AVX) / takt (2 na portu 0 a 2 na portu 1, pripadne dalsi 2 na portu 5, ale to uz jsou nestandardni operace, tak to nepocitam). To s x87 nedosahnete ani omylem (a v x64 nijak, protoze tam uz se nepouziva).
"vektorové instrukce x86 procesorů jsou v zásadě velmi chabé a dřevěné"
WTF ? Co tim jako chtel basnik rict ? Napr. skalarni scitani se od vektoroveho scitani lisi jen tim, ze vyprodukuje 1 vysledek misto 4 nebo 8 :). Throughtput, latence i pouzite registry jsou identicke. S nasobenim je to, prekvapive, uplne stejne.
Koneckoncu, to namerene (prumerne !) zrychleni 4-6x je realne a nijak nezmanipulovane (porovnani s kodem produkovanym VS2005/8/10 v defaultnim "release" nastaveni). Kdyby to tak nebylo, tak bych se na to taky vykaslal :).
„Problem je ten, ze optimalizovat cely program je blbost.“
Je to blbost, protože jste to řekl?
Není to blbost. Kompilátor to tak umí udělat.
---
„Tato volba je stejne v kompilatoru defaultne vypnuta.“
Například v MS Visual Studiu je pro release verze tato volba defaultně zapnuta.
Už jsem si všiml dříve, že se nestydíte lhát a to je také základní pohnutka, proč jsem příspěvek napsal.
---
„Naprosto drtivou dobu casu (rekneme 99.99% casu) stravi CPU v jedine (nebo nekolika malo) hlavni smycce nejake vypocetni funkce (nebo nekolika malo), pro kterou je nutne prizpusobit cely "engine" tak, aby tato fce mela optimalne predpripravena data.“
To závisí na druhu programu. Ale obecně nejvíce času běžné programy tráví čekáním na něco.
Je tedy zbytečné v řadě případů optimalizovat čekání, které program většinou stejně neurychlí.
---
„Tato fce se vetsinou da zoptimalizovat za nekolik malo dni (nekdy i hodin - podle rozsahu). Typicky se jedna o nekolik desitek instrukci ve smycce bez jakehokoliv vetveni - to se musi eliminovat.“
A tady jste krásně odhalil meze optimalizace v assembleru.
Na věc čítající několik desítek instrukcí padne několik dní Vaší práce. Na mojí konkrétní otázku „jak to zrychlí celý program“ děláte mrtvého brouka a děláte, že jste jí přeslechl.
Přitom ve vyšším programovcím jazyce jde o minutu práce – a Vy z ní uděláte několik dní práce v assembleru – proto je na místě otázka, jak se to projeví na efektivitě výsledku, tedy programu.
A odpověď z praxe: Většinou nijak, jde o libůstku assembleristů, která se nedá objektivně obhájit, protože program není většinou rychlejší ani kvalitnější. Jen dražší.
Dnes už kompilátor C/C++ optimalizují tak kvalitně, že pro assembleristu je velmi těžké obhájit vůbec nějaký přínos ruční optimalizace v assembleru. Ti jde jen u zlomečku případů.
To, že nějaký maličký kousíček kódu běží 5× rychleji je nepodstatné, když program to nezrychlí.
---
„Rozsahlejsi projekty je nutne rozdelit do mensich casti, to mate pravdu. Pokud ma (pod)program obrovske mnozstvi objektu, tak to uz je samo o sobe vetsinou spatne.“
Objekty nejsou myšleny třídy a instance, ale jednoduše objekty se kterými pracuje kompilátor, tedy proměnné, funkce, typy, atd.
---
„Vse se musi maximalne zjednodusit, aby to slo dobre paralelizovat a vektorizovat. Je jasne, ze u mismase bude kompilator lepsi.“
Jenže jen zlomeček algoritmů jde dobře paralelizovat. Je jen malé procento algoritmů, které jde dobře paralelizovat. Většina algoritmů jde paralelizovat jenom se ztrátami, některé dokonce vůbec.
A každé paralelizování má také cenu za paralelizaci. Jinak řečeno paralelní algoritmus má vyšší režii, než neparalelní, v ideálním zřídkavém případě stejnou. Něco to stojí.
Navíc SSE nedokáže ani zdaleka provést efektivně většinu paralelizovatelných algoritmů, jen některé speciální případy.
Lidé, co se skutečně seriózně zabývali SSE a jejím využitím pro výkonnější algoritmy veskrze do jednoho skončili s obrovským zklamáním, jak málo výkonné SSE je a jak malý výkon podává. A jak ve velmi malém počtu případů vůbec jeho použití za něco stojí.
To je i závěr tvůrců řady kompilátorů C/C++, to je závěr řady benchmarků a testů.
A to je důvod, proč tvůrci kompilátorů je laxně využívají SSE. První důvod je ten, že kompilátory se snaží o nejoptimálnější kód, a ten je ve valném případě mimo SSE instrukce a bez použití SSE instrukcí. Druhý důvod je ten co jste napsal, ze zdrojového kódu C/C++ se těžko tyto instrukce syntetizují.
Ono je to totiž tak, že instrukční sada procesorů je šitá na míru C programovacímu jazyku. V raných dobách proceosrů to tak nebylo, ale po vzájemné symbióze mezi C a procesory ušily postupně procesory instrukční sadu vhodnou pro jazyk C.
Na SSE uděláte optimálně možná pár umělých případů, nebo speciálních výpočtů. Řada z nich je součástí standardní či rozšířené knihovny C/C++ daného kompilátoru. A jen menšině programů se vyplatí v SSE dělat přímo.
Proto je pořád ta základní otázka: Jaký to má vliv na výsledný program. Protože kompilátor optimalizuje s ohledem na celý program, ne jeden podprogram. A uživatele programu taky nezajímá, že jedna funkce z miliónu je 5× rychlejší, když program běží stejně rychle jako předtím.
Ano, existuje možnost, že v nějaké klíčové funkci je rychlost podstatná, ale pak je ve většině případů daleko efektivnější pohrát si s výběrem vhodného algoritmu a datových struktur, než ďábelsky zrychlit jeden podprogram o několik nanosekund. Hlavně je to také udržovatelnější do budoucna.
Ano, existují programy, kde je psaní v assembleru na místě. Například video kodeky, nebo grafické náročné výpočty.
Porad tu zvatlate o nejakejch uzasnech compilatorech co zoptimalizujou program misto programatora bez uvedeni ktery to jsou. Tak prosim aspon jeden priklad, ze to neni gcc uz vime. My co pouzivame visual studio vime ze to neni ani ten microsofti. Tak kterej to sakra je ?
Dobrá, dáme si závod ano?
Vezmeme program, řekněme běžný menší program o velikosti ekvivalentních 100 000 řádcích zdrojového kód v C++.
Vy to napíšete v assembleru, já v C++.
Následně program vezmeme a doplníme do něj 2, nebo 3 nové podstatné vlastnosti. Vy to spácháte v assembleru, já v C++.
Uvidíme, jak to dopadne s rychlostí a jak s efektivitou vývoje.
---
Na x86 je obecně nejlepším kompilátorem Intel, ani Microsoft není vždy nejhorší.
Na jiných, než x86 procesorech jsou kompilátory ještě efektivnější, protože mají výhodnější sadu pro strojovou optimalizaci.
---
Jinak každý kompilátor samozřejmě program optimalizuje i za programátora. Doby, kdy kompilátory otrocky doslova přeložily program tak jak ve zdrojáku je jsou dávno pryč.
---
Ale znovu, i Vy se vyhýbáte základní otázce, a uhýbáte z ní jako had – jak se projeví optimalizace nepatrného kousku programu v asm na celkové rychlosti programu?
Většinou nijak, pokud se dobře zvolí algoritmus. Jen se rvývoj pekelně prodraží a protáhne. To je všechno.
Proč oponenti se kroutí jako hadi a záměrně se čelem nepostaví k otázce o kolik ruční optimalizace zrychlí průměrný program proti čistému C/C++, když do toho zasáhnout maličko assemblerem. Protože by to pro ně bylo velmi nemilé zjistit, že prakticky nijak.
Líbí se mi, jak se snažíte útočit, ale základní otázce „o kolik to celově zrychlí běžný program„ to děláte že neslyšíte.
---
Takže závěr: Dnešní kompilátory C/C++ jsou velmi dobré v optimalizaci na celek programu. A je velmi velmi těžké je přebít ručně. 99 % assembleristů to nedokáže vůbec ani na krátké rutině. To zbývající 1 % to zase nedokáže na celém programu, protože jen velmi nepatrná menšina programů má rychlostně kritické místo optimalizovatelné na malém kousku assembleru.
Zároveň bych Vás ujistil, že ono optimalizovat v assembleru není žádná sranda, zvláště ne na x86 platformě. Je třeba znát detailně architekturu všech používaných modelů procesorů, pro každý musíte ten program napsat trochu jinak, aby byl optimální. Každý model jinak zpracovává frontu instrukcí a jinak řadí a favorizuje jiné instrukce.
Oni assembleristé jsou obvykle spíše více sebevědomí, než odpovídá schpnostem. Znát pouze instrukční sada opravdu nestačí. Napsat nejrychlejší možnou rutinu pro něco není sranda a teprve když si to člověk odměří, zjistí jak citlivé to je. Někdy stačí přehodit pořadí dvou instrukcí beze změny programu a rutina jede 3× rychleji.
Optimalizace assembleru na rychlost na x86 je velká machrovina. Drtivá většina assembleristů píše výrazně pomalejší kód, než leze z běžného C/C++ kompilátoru. Možná 1 % lidí píšících v assembleru je schopno se s kompilátorem poměřit. Protože znalost instrukční sady na to opravdu nestačí. Je třeba detailně znát architekturu, instrukční proudy, detaily zpracování včetně časování jednotlivých instrukcí a mikroinstrukcí na jednotlivých stupních zpracování v procesoru.
A v neposlední řadě, zejména pro vymakanější nebo delší kódy to také vyžaduje velmi dobrou znalost matematiky a numerických metod.
S těmito znalostmi se můžete kompilátoru postavit, ale stále platí, že běžný kompilátor je nechutně dobrý – a 99 % assembleristů s ním prohraje co se týká rychlosti kódu.
Proto každého assembleristu, který tvrdí, že napíše rychlejší program ve většíně případů (mluvím o programu, ne o rutině o 20 instrukcích), nechť to předvede.
Programuji 25 let v C/C++, a v assembleru jsem se toho naprogramoval nemálo. A proto mě nenechalo v klidu tyhle kecy, co se tu šíří. A znovu, všichni se jako had vyhnuli základní otázce: „Jak moc to zrychlí program?“
Zrychlit program v kritických částech je většinou jednodušší lepší volbou algoritmu (k tomu jsou velmi dobré znalosti matematiky, algoritmizace a zejména numerické matematiky velmi dobré). Výsledek je většinou lepší, než optimalizování nanosekund.
Je tak tezke na jednoduchou otazku dat jednoduchou odpoved bez vytvoreni slohu se spoustou zbytecneho a otazky se netykajiciho balastu ?
Chtel jsem vedet jaky je ten vas uzasny compiler co zoptimalizuje kod za programatora a odpoved sem nedostal.
Ano zminujete intel compiler, ale ten je nepouzitelny vzhledem k tomu ze x86 nejsou jen intel procesory a jim generovany kod na neintel procesorech je spatny.
Dalsi zmizeny je microsofti compiler. Milej pane tenhle compiler generuje pro c++ i nekolikanasobne pomalejsi kod nez ono gcc ktery o par prispevku vys podle vas neni dobry compiler.
Takze ja furt cekam na ten zazracnej compiler co umi optimalizovat pro vsechny x86 procesory...
"Na mojí konkrétní otázku „jak to zrychlí celý program“ děláte mrtvého brouka a děláte, že jste jí přeslechl."
Budu naprosto konkretni a uvedu priklad z praxe - doba zpracovani jiste ulohy v mem pripade po prepsani do asm klesla ze zhruba 10h na neco pres 2 hodiny a to umoznilo porazit konkurenci. V jine (odlisne) uloze byl rozdil jeste trosku vyssi. K tomu stacilo zoptimalizvat zhruba jednu tisicinu kodu. Doporucuji - vemte si nejaky profiler, ktery vypisuje dobu stravenou v jednotlivych funkcich a uvidite, ze u programu, ktere hodne zatezuji CPU, se to deje prevazne v nekolika malo klicovych funkcich. Je to logicke - malo aplikaci dela velke mnozstvi RUZNYCH vypocetne narocnych veci. Vemte si napr. raytracing - tam muze CPU stravit i dny v jedine kratke fci. To same video, grafika 2D i 3D, zvuk, sifrovani, (de)komprese, zpracovani textu, rozpoznavani obrazu a hlasu, simulace, emulace, sitove protokoly, statistika, vyhledavani... Vlastne cokoliv narocneho s vyjimkou her (ale to je kapitola sama pro sebe). Prakticky vzdy je tam relativne malo narocnych algoritmu, zato klicovych. Drtiva vetsina kodu je jen nejaka obsluzna logika a na tu obyc. C++ kod (nebo i C#) a kompilator bohate staci - to mate pravdu.
K tomu jen poznamka - je to videt treba i u benchmarku Intel vs AMD. V jednom programu je rychlejsi ten, v druhem onen. Casto totiz staci, aby v hlavni smycce byla pouzita jedina(!) instrukce, ktera je na konkretnim CPU hodne pomala a celkovy vykon klesne o nekolik procent. Tohle treba (mimo jine) dela Intel kompilator a proto je pro obecne pouziti dost nevhodny.
"Například v MS Visual Studiu je pro release verze tato volba defaultně zapnuta."
Je mozne, ze se to muze lisit podle verze nebo typu projektu. Ted jsem se na ni dival - je vypnuta a pokud vim, tak vzdycky byla (ja bych ji rozhodne dobrovolne nevypinal). Kazdopadne, pro rychlost programu je to irelevantni. Viz vyse.
"Ono je to totiž tak, že instrukční sada procesorů je šitá na míru C programovacímu jazyku."
Ano, castecne jo. Napr. drive zminovana instrukce CMOV (implementace operatoru "?"). Akorat je pak blbe, kdyz ji kompilatory zacnou pouzivat az po 16 letech... Podobne je to i s dalsimi instrukcemi. Napr. SSE 4.2 implementuje operace s retezci (strcpy, strcmp atp.) - pokud vim, tak je zatim zadny kompilator neumi automaticky pouzivat a to uz tu mame treti generaci CPU, ktere tuto sadu podporuji.
"Jenže jen zlomeček algoritmů jde dobře paralelizovat."
Ano, ale vetsina tech narocnych bud paralelizovat jde, nebo lze nalezt paralelizovatelny ekvivalent. A je rozdil mezi paralelizovatelnosti a vektorizaci. Vektorizovat lze casto (s trochou kouzleni) i ciste seriove algoritmy. A kdyz nelze ani to, je na case to vzdat, prenechat kompilatoru a venovat usili tomu, co vektorizovat lze :).
Jinak, myslim, ze si uplne nerozumime. Zavadite diskusi uplne nekam jinam. Ja jsem jen chtel rict, ze rucni optimalizaci klicovych casti kodu lze docilit mnohonasobneho zrychleni klicovych operaci, coz potvrzuje i praxe. Vyvracet mi to muzete jak chcete, ale fakta jsou fakta. Kdyby to tak nefungovalo, tak jsem uz davno na dlazbe. Sefy a zakazniky nezajima v cem je to napsane, ale jak je to rychle. A dokud buse asm mnohokrat rychlejsi, nez kompilator, budu poizuvat asm. Taky bych byl radeji, kdyby kompilatory generovaly rychly kod, ale obavam se, ze se jen tak nedockame. Autori kompilatoru jsou vazne radi, ze jim to aspon funguje a ja se jim vubec nedivim - delat kompilator neni zadna sranda.
Hm, vymysli uz v AMD take neco sveho? :o
Například AMD vymyslela integrovaný řadič paměti přímo do procesoru a pak multikanálový řadič paměti. Později převzal i Intel.
To, že máte 64bitové procesory je také autorství AMD. Intel teorve později pod pohrůžkou Microsoftu udělal 64bitové procesory také, protože mu Bill Gates jasně sdělil, že on prostě 64bitové Windows udělá a budou primárně běhat na AMD procesorech, když Intel byl tak neschopný a nic pro 64 bitů neudělal.
Další novinky, které vymyslela AMD si najdete jistě sám.
Pan je evidentne lidovy vypravec pohadek :-D
AMD nevymyslelo integrovany radic pameti v procesoru, to tu bylo uz nekolik let predtim nez to udelalo AMD v procesorech transmeta crusoe.
64bitove procesory taky nejsou autorstvi AMD, to tu bylo jeste dyl nez ty integrovany radice pameti v procesorech. Sam intel mel 64bit procesory par let pred AMD (dokonce mu ms na to udelal patricnou verzi windows ktera tu byla driv nez windows pro amd64), jen holt AMD to navrhlo s ohledem na zpetnou kompatibilitu s x86 instrukcni sadou a Intel se nakonec musel prizpusobit.
Prosím, vyprávějte tu pohádku, jak měl Intel před AMD 64bitový x86 procesor. Rád si to poslechnu.
Všechno tu většinou samozřejmě bylo, ono mimo x86 platfrmu existovalo a existuje leccos.
Nicméně bavíme se tu o AMD a Intel a x86 platformě.
Tak mě prosím poučte o prvenství Intelu v 64bitovém x86 procesoru. Rád si to poslechnu.
Do toho.
Vy jste napsal ze AMD _VYMYSLELO_ integrovany pametovy radic v procesoru a ze 64bitovy procesor je _AUTORSTVI_ AMD. Ani jedno neni pravda. Navic ani vy ani prispevek na ktery jste reagoval omezen na x86 platformu nebyl
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.