Názory k článku
Techniky zvýšení výpočetního výkonu počítačů
Ondrej 'SanTiago' Zajicek (neregistrovaný)
29. 5. 2008 10:24
Nový
RE: Techniky zvýšení výpočetního výkonu počítačů
celé vlákno
Mimochodem, uz i snadno dostupne dvouprocesorove (dual-socket, nikoliv dual-core) systemy s AMD procesory jsou NUMA systemy.
uživatel si přál zůstat v anonymitě
29. 5. 2008 11:24
Nový
su a nie su
celé vlákno
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...
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ý)
29. 5. 2008 11:17
Nový
Pochvala a odkaz: Sestavte si počítač
celé vlákno
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.
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.
Zaram (neregistrovaný)
82.117.130.---
8. 9. 2010 2:19
Nový
diky moc!!!!
celé vláknothanks a lot! tahle kniha je přesně to několik let marně hledám, a konečně se mi dostalo osvícení – jak to všechno do sebe zapadá, navíc podané s filosifickým náhledem – ustanovení zakladního paradigmatu a ne jen zlomky informací.
dejfson (neregistrovaný)
29. 5. 2008 11:18
Nový
super clanek
celé vlákno
diky.
(pozn: zerro flag = zero flag = priznak nuly?)
(pozn: zerro flag = zero flag = priznak nuly?)
aura:98
29. 5. 2008 12:37
Nový
Re: super clanek
celé vlákno
Omlouvam se, ma typicka chyba: zeRRo jako caRRy :-)
flatline (neregistrovaný)
29. 5. 2008 13:57
Nový
druhy priklad
celé vlákno
Prijde mi, ze slouceni dvou LD instrukci v druhem pripade neni idealni. Nechal bych (LD a) samostatnou, v dalsim kroku sloucil (LD b + RL a) a tak dale.
BLEK. (neregistrovaný)
1. 6. 2008 23:04
Nový
Re: druhy priklad
celé vlákno
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)
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ý)
29. 5. 2008 14:27
Nový
Paralelní počítání a William of Occaml
celé vlákno
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.
Č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.
aura:98
29. 5. 2008 16:05
Nový
Re: Paralelní počítání a William of Occaml
celé vlákno
Ano, 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 :-(
Rejpal (neregistrovaný)
29. 5. 2008 16:07
Nový
Re: Paralelní počítání a William of Occaml
celé vlákno
Kdepak, budoucnost patří funkcionálním jazykům a softwarové transakční paměti (STM). ;-)
Ondrej 'SanTiago' Zajicek (neregistrovaný)
29. 5. 2008 17:35
Nový
Re: Paralelní počítání a William of Occaml
celé vlákno
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ý)
30. 5. 2008 11:04
Nový
Re: Paralelní počítání a William of Occaml
celé vlákno
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 :) )
(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ý)
29. 5. 2008 14:37
Nový
pameti
celé vlákno
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 :-)
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ý)
29. 5. 2008 17:29
Nový
Re: pameti
celé vlákno
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.
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.
aura:98
29. 5. 2008 18:44
Nový
Re: pameti
celé vlákno
Stale 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... :-)
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... :-)
MD (neregistrovaný)
29. 5. 2008 16:13
Nový
Titulek:
celé vlákno
Ctu clanek a rikam si "Kdopak to asi psal?" A ano, trefil jsem to, opet Pavel Tisnovsky. Nikdo jiny by tak zajimave napsany clanek asi nesvedl :-)
cxl (neregistrovaný)
30. 5. 2008 12:21
Nový
Prejmenovani registru
celé vlákno
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ý)
31. 5. 2008 23:05
Nový
Re: Prejmenovani registru
celé vlákno
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
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ý)
1. 6. 2008 22:43
Nový
Re: Prejmenovani registru
celé vlákno
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).
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).
uživatel si přál zůstat v anonymitě
3. 6. 2008 9:04
Nový
Re: Prejmenovani registru
celé vlákno
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 :)
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 :)
