Názory k článku Techniky zvýšení výpočetního výkonu počítačů
-
anonymníAMD je aj nie je NUMA
na NUMA by Windows okrem Server 2003 a 2008
SUMO
Bohužel má NUMA jeden problém - běžný operační systém, který byl až doposud zvyklý běhat na SMP systémech, by z ní nebyl příliš nadšen. Takže AMD přišlo s jakýmsi hybridem zvaným SUMO (Sufficiently uniform memory organization) - fyzická architektura je podobná jako NUMA, ale pro operační systém se tváří jako SMP. Vhodným nastavením v BIOSu lze určit, zda se systém má tvářit víc jako SMP nebo víc jako NUMA. Pokud zvolíte druhou variantu a budete mít vhodný kernel se zapnutou NUMA optimalizací, můžete dosáhnout vyššího výkonu. Výhodou je, že i ne-NUMA kernel bude fungovat.
http://www.logix.cz/michal/doc/article.xp/amd64
krasna ukazka vyhod NUMA je
Processors # Cores Clock rate SPEC CPU2006 (base) throughput
int_rate_2006 fp_rate_2006
2 Opteron 2360 SEs
(Dell PowerEdge R805) 2 × 4 2.5 GHz 92.4 82.1
2 Xeon X5482s
(Supermicro X7DWT) 2 × 4 3.2 GHz 121 80.4
4 Opteron 8360 SEs
(Dell PowerEdge R905) 4 × 4 2.5 GHz 167 152
4 Xeon X7350s
(Bull NovaScale R480E1) 4 × 4 2.93 GHz 177 108
http://www.heise.de/english/newsticker/news/108585
XEON ma SMP
Opteron ma fyzicku NUMA brzdenu
rast vykonu so zdvojnasobenim poctu CPU
cele cisla (Integer)
Opteron 167/92,4= 1,807
Xeon 177/121= 1,463
pohybliva radova ciarka
Opteron 152/82,1 = 1,851
Xeon 108 / 80,4 = 1,343
A co nam hovori teoria ?
rast vykonu v SMP je s druhou mocninou poctu CPU
cize Xeon mal mat narast 1,414
a pri NUMA je narast vykonu rovny narastu poctu CPU
cize AMD ma mat narast 2,000 - minus_naroky_na_synchron....
na druhej strane prave optimalizacia na NUMA zlomila vazy tripple a quad core AMD
lebo dvojkanalovy radic moze byt pouzity ako dva radice, kazdy pre jedno jadro v dual core, ale pri viac jadrach to uz interne v ramci CPU musi fungovat ako SMP
A toto vyrieis az 4 kanalovy radic RAM v buducej generacii server CPU AMD... -
Krtek (neregistrovaný)Nedá mi to než se přidat k těm, co děkují za tento seriál. Díky němu se s radostí připravuji na zkoušku z číslicových systému.
V jednom z prvních dílů dal kdosi k dobrému adresu videa o tom, jak "počítače fungují". Video je zajímavé, ale ještě zajímavější jsou stránky onoho řečníka, který spolu s dalšími připravil semestrální kurz "Od logického obvodu k KC" - http://www.idc.ac.il/tecs. S pomocí programu v Javě si můžete vyzkoušet, zda jste schopni přijít na princip paměti, ALU, CPU, atd. Na našich vysokých školách jsem zatím nic podobně úžasného nenašel. -
-
BLEK. (neregistrovaný)U současných procesorů (PentiumPro a výš, K6 a výš) je úzké hrdlo dekodér instrukcí, nikoli výkonné jednotky. Takže se instrukce překladačem přehazují podle toho, aby rychle prolezly dekodérem. Jak budou zpracovávány jednotkami překladač neřeší, protože to si jádro procesoru přeskládá samo.
Pro Pentium Pro/2/3/Core se instrukce skládají podle pravidla 4-1-1 (jedna těžká instrukce, co se rozloží na 4 mikroinstrukce, pak dvě lehké instrukce).
Pro Core 2 je to 4-1-1-1.
Pro Pentium 4 se musí od sebe dávat instrukce s přímými operandy.
Pro K6-2 se scheduluje 2+2 nebo 4. (dvě lehké instrukce na 1 nebo 2 mikroinstrukce nebo jedna těžká na 4)
Na Athlonu je to celkem jedno --- zpracuje vždy 3 za tik (jen nevybírat mikrokódované VectorPath instrukce) -
Vuk (neregistrovaný)Jazyk occaml neexistuje. Existují OCaml nebo occam, tady jde zjevně o ten druhý.
Čekal bych, že zažije (occam či nějaký příbuzný jazyk) docela renesanci, až se zjistí, že už na multicore standardní jazyky (C++, Java) docela selhávají - běžně používané techniky synchronizace mezi thready najednou nestačí; Java sice nabízí prostředky, jak to řešit, jenže jsou zoufale neobratné a mají hroznou režii. Soudím, že to je v základech jazyka, že tady žádné flikování bez podstatné změny principu nepomůže. -
Pavel TišnovskýZlatý podporovatelAno, jde o occam, omlouvam se za mateni. Mozna az kdyz se skutecne vice zacnou pouzivat multicore (treba vic jak ctyri, osm jader), tak by podobny jazyk zacal byt skutecne uzitecny (prozatim se to da na dvou jadrech resit "rucne"). Ale jde o to, zda se occam prosadi sam o sobe, nebo se podobna technika prida do mainstreamovych jazyku, za kterymi stoji zastupy vyvojaru. Jinak PCcko jako takove je flikovane od zacatku, takze by to nebyla zadna novinka :-( -
Ondrej 'SanTiago' Zajicek (neregistrovaný)Osobne si myslim, ze (minimalne blizka) budoucnost patri rozdelovani ulohy na tak hrube casti, aby se minimalizovala nutna komunikace mezi thready (nebo procesy). Nejenze tim odpadaji problemy se synchronizaci, ale je to i rychlejsi (odpada vzajemne invalidovani si cachelines mezi procesory).
-
Vuk (neregistrovaný)Přesně tak. Z toho mi ale právě vychází to, co říkám - například v Javě něco takového dělat jde, ale je to hrozně neobratné a nepohodlné, a nezdá se mi, že to lze opravit přidáním nějaké nové jazykové konstrukce či nového nástroje. Mimochodem - neplyne z toho taky postupné opuštění threadů a pokorný návrat zpět k procesům?
(A k funkcionálním jazykům - těm patřila i minulost a přítomnost, akorát mainstream si toho ještě nevšiml :) ) -
Karell (neregistrovaný)Jak bylo receno, tak se zvysujicim se mnozstvim cpu je nutno k nim pridavat pamet a kopirovat do ni vstupni data. Zajimalo by me, jestli existuje nejaka pamet, ktera by umoznovala cteni nekolika (stovkam?) uzlum zaroven, takze by lokalni pamet mohla byt mnohem mensi. Asi by se musela rozdelit na nejake bloky a do kazdeho bloku by byl umoznen pristup jen jednomu uzlu, ale i tak by to mohla byt uspora pameti. Bylo nekdy neco takoveho pouzito?
A jeste poznamka k textu - mam pocit, ze odstavce v casti o transputerech jsou prohozene (nejdriv je zmineno, ze to nebylo uspesne a pak se teprv vysvetluje co to vlastne je).
a samozrejme diky za serial :-) -
Kvakor (neregistrovaný)U grafickych karet takova pamet bezne existuje (resp. spis exisotvala), rika se ji dual-ported RAM (u grafik spis VRAM). Ta umoznuje zaroven pristupovat ze dvou mist, i kdyz ta pro grafiky umoznovala vetsino jen jeden plnohodnotny (pripojenky ke sbernici) a druhy jen sekvenci (pro CRTC+DAC a generovani obrazu).
Dnesni grafiky ale maji jen normalni "jednoporovou" architekturu pameti, dvouportovost je dohanena rychlosti a udelatory typu ringbus, navic samotne cteni dat pro ucely zobrazovani dnes zabira jen zlomek prenosove kapacity. -
Pavel TišnovskýZlatý podporovatelStale by tam bylo to uzke misto, kterymi by se procesory k pameti pripojovaly, to je dost neprijemne. Predstavte si 1000 mikroprocesoru nejakym zpusobem pripojenych k takove pameti - sbernicova struktura selhava, protoze by 999 mikroprocesoru cekalo na ten jediny, ktery by se dostal "k lizu". Jasne, jde udelat dualportovou pamet (stejne je tam nekde uvnitr switch), ale dal to moc dobre nejde (dualport je vylepseni: "jen" 998 procesoru by cekalo).
Nebo jiny priklad: 1000 procesoru, 1000 bloku pameti - uvnitr takove blokove pameti by musel byt switch pro vytvoreni vsech moznych kombinaci, coz je skoro nepredstavitelne. Mensi pocet bloku = nejake procesory nemuzou cist, takze zase nutnost lokalni pameti, aby zbytecne nestaly.
Tim rozdelenim pameti na male casti pristupne jednotlivym procesorum se sice cely problem pro maly pocet procesoru zesloziti (von Neumannova architektura je to nejjednodussi myslitelne reseni), ale potom cely ten system muze pekne "rust", neni tam to uzke misto, jake predstavuje klasicka centralni pamet nebo sbernice.
Svet je proste slozitej... :-) -
cxl (neregistrovaný)Myslim ze v souvislosti se spekulativnim a OOO provadenim je naprosto bezpodminecne zminit techniku prejmenovavani registru, coz je mnohem lepsi reseni problemu zavislosti instrukci nez navysovani poctu architekturnich registru (vysoky pocet architekturnich registru casto zpusobuje problemy s HW implementaci procesoru, viz Itanium).
-
dejf (neregistrovaný)Prejmenovani registru resi jen malou cast problemu - situaci, kdy nasleduje instrukce, ktera do registru neco napise a jeho obsah tak nahradi, jindy nikoliv. Napr
LD A, adresa
XOR A,A - tato instrukce z registru A cte a ac je jasne, ze jej vynuluje, prejmenovani neni mozne.
LD A, adresa2 - tato instrukce by mohla vyuzit preklad na LD B -
BLEK. (neregistrovaný)Pentium 4 dokáže přejmenovávat i XOR reg,reg a SUB reg,reg (je to v něm zadrátované, že tento speciální případ rozbije závislosti). Na Pentiu Pro/2/3 XOR závislost nerozbíjelo.
Kvůli přejmenování se třeba při 16-bitovém čtení paměti negeneruje instrukce MOV AX, WORD [paměť] (protože nerozbije závislosti, obsah EAX závisí na předchozích horních 16 bitech EAX), ale místo ní se generuje MOVZX EAX, WORD [paměť] (ta přepíše celé EAX, tak závislost rozbije). -
anonymníMyslim ze prejmenovani naopak resi dost podstatnou cast problemu.
Bez prejmenovani neni mozne paralelizovat jednotlive iterace smycky mezi sebou. Treba:
loop:
ld a, [ix]
ld b, [iy]
add a, b
ld [ix], b
inc ix
inc iy
cmp a, c
jl loop
bez prejmenovani musi kazda dalsi iterace cekat na dokonceni te predchozi, protoze jsou tam zavislosti. S prejmenovanim lze provadet iterace zaroven. Nebo aspon nekdy :)
(Omouvam se za syntaxi assembleru, kterou jsem si prave vymyslel, snad je to srozumitelne :)
