PCTuning fórum

jo do nekterych desek ano pouze s upgradem biosu.

http://cs.twitch.tv/amd

je tu nějaký AMD live event a v chatu nějaké "oficiální info" od AMD

okno jsem si zavřel a v tom novém nejsou staré posty z chatu, smůla!

babenky sú tam chutné

Spojení 2 jader (prakticky reverzní HT) by imho k vyššímu výkonu BD moc nepomohlo. Ono to jen tak hezky vypadá, ale rád bych viděl jak často by byly, díky závislostem, všechny 4 ALU využity. Problém bude někde jinde a určitě se po NDA dozvíme kde.

dexterav píše:babenky sú tam chutné

ten Chew se bude muset sám chladit dusíkem nakonec z těch HOT slečen ... 4 slečna a jeden borec,aj jaj

GaGy píše:Jak to teda bude s buldozerem pujde do AM3 patice ?

Půjde, ale ne do všech desek-většinou ty s silnějším napájením a větším ROM pro BIOSy...problém tam bude nejspíš s OC (bude nižší než na AM3+ a méně možnoti v nastaveních)

tak mě napadlo uplatnění pro BD, výpočetní stanice do škol atd... Pro ty systémy, kdy je jeden PC a k tomu je víc periferií. Na dělání levných pracovních stanic to bude úplně super, každý uživatel bude mít pro svoji práci třeba 1/2 modulu, což pro něj bude mnohem lepší než samostatná stanice na Atomu a k tomu třeba bude ještě jeden modul volný, kdyby se nárazově zvýšily požadavky na výkon. Viděl jsem takovýhle multipoint server systém postavený na C2D+GT8800 a to byl děs, jeden člověk si pustil rendrování krychle v blenderu a ostatní 4 uživatelé nemohli ani pohnout kurzorem, jak se systém zasekal. AMD by stačilo tohle jen protlačit marketingem a na Africkém trhu by to mělo úspěch, zvlášť s AMD grafikama, který zvládaj 6 monitorů. S možnostma výroby, by ten Africkej trh amd úplně stačil

Trocha humoru z toho chatu z tej AMD akcie:

Chuck Norris a Bulldozer

- Chuck Norris dokaze silnym uderom urobit z kremiku Bulldozer
- Chuck Norris pretaktoval Bulldozer na 9 GHz svojim sviezim dychom
- Chuck Norris dokaze rozbehat Nvidia SLI na dvoch Radeonoch HD 6990

Obcas to tam niekto placol a celkom sa mi to zdalo vtipne .

webwalker píše:Spojení 2 jader (prakticky reverzní HT) by imho k vyššímu výkonu BD moc nepomohlo. Ono to jen tak hezky vypadá, ale rád bych viděl jak často by byly, díky závislostem, všechny 4 ALU využity. Problém bude někde jinde a určitě se po NDA dozvíme kde.

4 ALU na takt sa nevyuziju nikdy a v hrach sa vyuzije priemerne menej nez 1 ALU na takt. Ale najvacsi pruser je ta dlha pipeline, asi chcu konkurovat P4. Kolko ze to ma, 20 stages?

mega52: Přesně tak, já na Denebu naměřím v DukNuk průměrné IPC 0,8.
Jinak na délce pipe až tak nezáleží, pokud je tedy dobrá Branch prediction. P4 měla i i delší pipe - podle typu.

webwalker: Ale pokial mas v kode pamatovu zavislost premennych tak branch prediction nepomoze a zalezi najviac na dlzke pipeline. Dvojnasobna dlzka vtedy znamena takmer 2x nizsi vykon. A P4 bola vtedy voci CoreDuo 2x pomalsia na takt.

mega52: Popravdě nevidím spojitost mezi délkou pipe a závislosti. Myslíš, že by závislá instrukce byla rychleji zpracována, kdyby v kratší pipe vůbec nebyla? Ale možná jsem tě dobře nepochopil.
Imo P4 byla pomalejší vůči CD2 i z mnoha jiných důvodů než je délka pipe.

webwalker: Tak to vysvetlim:
Ak je nasledujuca instrukcia zavisla od vysledku predchadzajucej instrukcie, tak sa z nasledujucej moze vykonat nacitanie a dekodovanie, ale dalej sa musi cakat kym sa vyhodnoti predchadzajuca instrukcia, tj. kym dojde az takmer na koniec pipeline, kedy uz je vysledok ulozeny v registri.
Ak mame pipeline dlhu 20 stage a tato kriticka cast(critical execution path) pocas ktorej sa musi cakat je dajme tomu 75% dlzky pipeline, tak sa caka tych 15 cyklov (clock cycle) kym zacne druha instrukcia.

Ak mas napr. taketo 4 zavisle instrukcie sa sebou, tak kazda trva minimalne 15 cyklov, celkovo je to teda minimalne 60 cyklov + cykly na zacatie prvej a dokoncenie poslednej instrukcie, teda spolu 65.

Ak mas ale za sebou 4 pamatovo nezavisle instrukcie, tak sa mozu vykonavat jedna za druhou, posunute o 1 cyklus. Prva sa zacne v 1. cykle a dokonci v 20. cykle. Druha zacne v 2. a dokonci v 21. cykle, ..., stvrta zacne v 4. a dokonci v 23. cykle.

Edit:
Ak mas za sebou 100 nezavislych instrukcii, tak sa dokoncia za tych 120 cyklov a priemerne IPC bude 100/120, a to je 0.83.

Edit2:
Toto je blbost: Ak mas viac ALU a FPU tak sa moze na kritickej ceste vykonavat viac instrukcii naraz.
Naraz sa mozu na viacerych ALU a FPU vykonavat len nezavisle instrukcie a tiez scheduler moze pripravit a dekodovat viac instrukcii, ci uz su zavisle alebo nie.

webwalker píše:Spojení 2 jader (prakticky reverzní HT) by imho k vyššímu výkonu BD moc nepomohlo. Ono to jen tak hezky vypadá, ale rád bych viděl jak často by byly, díky závislostem, všechny 4 ALU využity. Problém bude někde jinde a určitě se po NDA dozvíme kde.

myslím, že reverzní hyperthreading je v podstatě nerealizovatelná věc, alespoň v podobě jak byl prezentovaný dříve u klasických CPU jako Phenom nebo Core2:

First off, there's no way this would work the way the author seems to think it would. How would the cores' pipelines support this in any phase of execution? In the fetch phase, there would have to be some arbitration mechanism whereby the two cores fetched alternate instruction blocks from the I-cache, thus distributing the instruction stream across two processors.

Then, once the instruction stream is fragmented inside the two cores, how are the register files kept in sync? If an add in one line of code writes its result to a register in one core, then how could a test instruction in the other core read that distant register to see if it needs to branch? Or how would out-of-order execution work across two cores? Would the instruction schedulers have their own separate bus to communicate over?

V modulu je to ale něco jiného, nejde o spojování dvou vláken do jednoho, jen o využití různého počtu výpočetních jednotek pro jedno vlákno. Je fakt, že 4 jednotky to už by bylo pravděpodobně moc (sotva 3 se plně využijí) Realizovat by se to dalo a nejednalo by se reverzní HT, spíš o něco jako Flex ALU. Sám jsem celkem zvědavý co v BD tak ku.ví výkon. Bude to více faktorů, ne jen ALU/AGU, ale i délka pipelines, cache latence, atd.

mega52: Imho, pokud jsem příklad pochopil správně, pak by to mělo být trochu jinak.
Pokud jsou dvě nebo více instrukcí na sobě nezávislé, mohou se výpočty provést najednou na různých výpočetních jednotkách (pokud tento typ výpočtu podporují), pak je IPC třeba 3 (ILP).
Pokud jsou však výpočty na sobě závislé např. A=3+6, B=A*8, C=B-5 pak samozřejmě nejde paralizovat a jeden výpočet trvá 1c (všechny tedy 3c), pak je IPC 1. Pokud některý z výpočtů má větší latenci IPC<1.
Vždy však pipeline běží nepřetržitě a o "výhodné" plánování pořadí provádění instrukcí se stará OoO.
Tudíž 4 závislé instrukce za sebou trvají 4c (samozřejmě pokud je latence výpočtu na výpočetní jednotce 1).
Pokud máš 100 nezávislých instrukcí, IPC je úměrné ILP, tedy v případě 3ALU IPC=3.
Pochopil jsem to správně?

del42sa: Já to chápu takhle:
SMT: Dva thready do jedné pipe
Rev.HTT: Jeden thread do dvou pipe
Imho jestli se v případě rev.HTT jedná o dvě pipe nebo o dvojnásobek ALU, je tak trochu jedno, protože u BD mají int ALU svůj vlastní sheduler v každém int clusteru. Ale tak nějak se ptám, není to jedno?
Ale máš pravdu, FlexFPU je vlastně SMT, tak proč rovnou neudělali SMT taky ALU? Imho takhle asi dosáhli vyšší propustnosti pro servery, ale co DT?

mega52 píše:najvacsi pruser je ta dlha pipeline, asi chcu konkurovat P4. Kolko ze to ma, 20 stages?

Tenhle argument je prazvlastni.
C2 ma 14 stages, Nehalem 16. SB bez vyuziti vyhody L0 cache 18. Jsou Nehalem a SB autoamticky horsi?

webwalker píše:mega52:
Pokud jsou však výpočty na sobě závislé např. A=3+6, B=A*8, C=B-5 pak samozřejmě nejde paralizovat a jeden výpočet trvá 1c (všechny tedy 3c), pak je IPC 1.
...
Tudíž 4 závislé instrukce za sebou trvají 4c (samozřejmě pokud je latence výpočtu na výpočetní jednotce 1).

Toto neplati. Az take jednoduche to nie je. Jedna samostatna instrukcia nikdy nemoze trvat 1c(cyklus), lebo musi prejst krokmi: load,fetch,decode,execute a store. A ani to "execute" netrva 1c, ale ovela viac. Pri zavislych instrukciach klesa IPC az pod 0.1, prave kvoli kritickej ceste, kedy sa caka na vysledok predchadzajucej operacie. Podla tvojho vysvetlenia by IPC takmer nikdy nekleslo pod 1 a castejsie by bolo na pocte ALU, co je realne len u tazko optimalizovanych algoritmoch bez zavislosti a cyklov.

V reale je ale ovela viac nezavislych instrukcii ako zavislych, vtedy sa vyuziju viacere ALU a IPC sa dviha ku priemeru co je okolo 1.

yuri.cs píše:

mega52 píše:najvacsi pruser je ta dlha pipeline, asi chcu konkurovat P4. Kolko ze to ma, 20 stages?

Tenhle argument je prazvlastni.
C2 ma 14 stages, Nehalem 16. SB bez vyuziti vyhody L0 cache 18. Jsou Nehalem a SB autoamticky horsi?

Lenze C2, Nehalem a SB sa nelisia len dlzkou pipeline. Ale aj velkostou cache, branch prediction + vela vela dalsich optimalizacii.
Odporucam clanok na arstechnica a dole su odkazy na dalsie 2 clanky: Pipelining part 1 a part 2 kde je to detailne vysvetlene.

Edit: ale pravda, na BD som nemusel byt az tak kriticky.

Deneb(10h) a Zambezi (15h) se nelisi velikostou cache, branch prediction + vela vela dalsich optimalizacii (5 let vyvoje)?

//mega52:

webwalker píše:Pokud některý z výpočtů (nacpanych v pipeline) má větší latenci (nez 1T) IPC<1.