PCTuning fórum

DOC_ZENITH píše:JJ pokud test potřebuje FIX, tak toho asi moc netestuje protože test má testovat výkon/prostupnost a ten tam je nebo ne.

Tak ja nevim. Napda me, ze testovat se pamet da treba pomoci memcpy. AVX dovoli 256b vs 128b u SSE vs 64b x86-64. Pokud je test zkompilovany tak, ze na jednom CPU pobezi s AVX a na druhem ne, tak jsou vysledky spatne.

Nevim jak by AVX mohlo ovlivnit prostupnost paměti. Ta tam buďto je nebo neni. Pokud Ňáká instrukce umí specifické operace v paměti které napomohou k rychlejšímu výsledku jedná se o operace v paměti, ne o prostupnost paměti. Prostupnost paměti = bandwitch mezi CPU a RAM. To potřebujeme změřit a tam AVX žádnou roli nehraje tudiž ten test by jej v žádném případě neměl používat.

A jak tu prostupnost CPU-RAM prosim zmeris? Ze by vykonanim nejakych instrukci? Nebo snad virguli?

Copy test se da udelat za pomoci memcpy - za jak dlouhou dobu zkopiruji blok XkB zacinajici na jedne adrese na druhou adresu. Pokud manipuluji s pameti po 64b, tak logicky musim pouzit 4x tolik instruci, nez kdyz pouzivam 256b. Tudiz je test pomalejsi - skrz CPU musi protect 4x tolik instrukci.

ten "fix" ale změnil výkon i Haswellů a taktéž výrazně SB-Eček, protože je zároveň multithreadový a bere výkon paměti subystému i v závislosti an CPU. Aidu přeci jen dne nedělá žádnej imbecil

edit: Trovaricon me upozornil, ze placam vetsi nesmysly nez obvykle..

yuri.cs píše:A jak tu prostupnost CPU-RAM prosim zmeris? Ze by vykonanim nejakych instrukci? Nebo snad virguli?

Copy test se da udelat za pomoci memcpy - za jak dlouhou dobu zkopiruji blok XkB zacinajici na jedne adrese na druhou adresu. Pokud manipuluji s pameti po 64b, tak logicky musim pouzit 4x tolik instruci, nez kdyz pouzivam 256b. Tudiz je test pomalejsi - skrz CPU musi protect 4x tolik instrukci.

Ano a přesně to nechceme, kopírovat bloky, protože co kdyby ta věc už v paměti byla a ty jsi použil instrukci co jí zkopíruje? V tu chvíli měříš efektivitu tý instrukce a ne prostupnost paměti.

Já si to představuji tak že random generaovaná data, jejichž generaci nebrzdí CPU (je to nenáročné + se tproces vejde do cache) a rychlost jejich kopírování do ram, a pak zpátky. To jest prostupnost.

U APU by se dala změřit i prostupnost videopaměti/framebufferu.

https://www.youtube.com/watch?v=axyHkKn_e80

Další video ve hře BF4 s nastavením různých detailů. Vypadá to slušně...Po OC hlavně by to mohl být mazec (2666 MHZ DRAM a IGPU kolem 1 GHz...)

ttxman & DOC_ZENITH - prosim vas, nesirte svoje "dojmy", pretoze si to dost ludi precita a vezme za fakt.
Ocividne vecna poznamka, ktoru napisal yuri.cs:

A jak tu prostupnost CPU-RAM prosim zmeris? Ze by vykonanim nejakych instrukci? Nebo snad virguli?

vas vobec od vasej "intelektualnej" diskusie neodradila. programatorom pripadate presne takto: http://www.youtube.com/watch?v=I8-T4-PoRTI#t=24


AD CU v Kaveri - nevsimol som si ziaden leak (ono je to dost "nezaujimavy" udaj) k pripadnej uprave velkosti / rychlosti cache - vzhladom na silnu (minimalne marketingovu) orientaciu na HSA. myslim, ze v tomto smere by kaveri mohlo "zamavat" projekciami realneho vykonu.

Trovaricon: moh bys mi rict, co je na mem "dojmu" spatne? Rad se naucim neco novyho a slibuju, ze pokud sirim bludy, tak je odstranim (a budu se stydet za to co sem proved).

ttxman - to co spominas je latencia nie priepustnost. Ked zacnes sekvence pristupovat do pamate tak aj najdementnejsi prefetch mechanizmus sa uvedomi a zacne robit svoju ulohu t.j. uz mas (takmer) vzdy "riadky" pamate v cache. Nasledne nastupuje presne to co si popisal - aj pristup do L1 trva... ak mas load jednotku, ktora vie nacitat 256 bitovy vektor a ty napriek tomu stale kazdym dotazom pytas z pamate (realne vsak uz z cache) 32 / 64 bit vektor tak asi tazko vytazis pamat... Jedine co si vytazil su L/S jednotky CPU. Dokonca ani v pripade (2x) 256bitoveho vektora loadovaneho na jednom jadre nebude pri rychlostiach dnesnych 2+ kanalovych DDR3 radicov dost.
Latenciu pristupu zamaskujes tak, ze instruction queue CPU (vdaka OoO) zaspamujes load instrukciami pouzitim optimalizacnej techniky "z dob paskovych jednotiek" @ loop unroll.

DOC_ZENITH - ad sandra na G32 - ocividne autori testu testuju nieco ine ako si ty myslis: prispendlim si n vlaken na jednotlive jadra CPU a spustim na kazdom z nich funkciu, ktora si naalokuje blok x bajtov pamate a pouzitim load instrukcie (zvycajne) s najvacsou moznou sirkou cieloveho registra prejdem naalokovany blok. Zmeram T zoptimalizovaneho prejdenia bloku na jednotlivych vlaknach a nasledne vyratam:
n * x / T

Ok mas pravdu z toho co sem navrhoval tady nevytahnu vic jak +-8GB/s na 1 vlakne i pri extremne velkym typu (2* velikost line se zda jako limit). Jdu si hrat s assemblerem, za trest si naprogramuju benchmark na propustnost pameti, high level jazyky mi zkazily smysl pro realitu, fakt sem veril tomu co sem psal (puvodne sem myslel, ze narazis jenom na tu latenci L1, tohle je mnohem horsi).

koukal jsem na to schéma Kaveri čipu z prezentace AMD a jen tak jsem přemýšlel, kolik modulů by bylo hypoteticky možné umístnit do plochy cca 210mm2. Pokud ty poměry velikostí odpovídají obrázku, tak by do té plochy šlo umístnit:

a) buď 6 modulů/12 vláken (bez L3 cache)

b) 4 moduly/8 vláken a 4 CU (256SP)







Která varianta by pro vás byla zajímavější ? Pokud by AMD chtělo, pořád by mohli vydat vícejádrovou variantu aniž by museli nějak extra překročit velikost cca 230mm2.

PS: obrázky jsou pouze ilustrativní a velmi zjednodušené.

Ta nejvýkonnější

del42sa> Mám pre teba novinu, tie pomery nezodpovedajú skutonosti, pochopiteľne. V skutočnosti by GPU malo zaberať trochu menšiu plochu, takže zrejme by si tam v skicári mohol narvať aj 8 modulov, to už by teda bolo niečo... Alebo, tak ma napadá, koľko by sa tam zmestilo Intel Haswell jadier? To by tiež bola zaujímavá varianta. Vieš, ono v prvom rade záleží na tom, či je ten socket FM2+ na niečo také pripravený, nie na tom, čo si sa ty naučil robiť v mspaint.

BTW: V poslednej variante si zabudol adekvátne zmenšiť pamäťový radič, keďže už nebude musieť byť HUMA, pre skúseného návrhára čipov to iste nebude problém a všetko to vieš úplne presne spočítať (tak, ako si sa kasal u Keplera, ak by si náhodou nevedel na čo narážam).

Ifkopifko ty musíš mít buď nějaký děsný mindrák z dětství a nebo nějakou jinou psychickou poruchu. Je mi tě opravdu líto....

PS: jianak to GPU opravdu menší není, řekl bych že to odpovídá tomu, co mělo AMD ve svých materiálech a to že GPU zabírá 47% Die. Možná to na první pohled tak nevypadá, ale když k modulům připočteš i řadiče a uncore část čipu, tak to sedí. ( nakonec proč by to kreslili do prezentace jinak, když tam mají přímo uvedená procenta ) To že je nákres zjednodušený ví AMD a vím to i já, ještě jsem na to schválně upozornil

Pri pohľade na tie tvoje obrázky som si skrátka nemohol pomôcť...

del42sa píše:nakonec proč by to kreslili do prezentace jinak...

Čo ti ja viem? Možno pretože je to schéma? Pre Kaveri to nie je jediná schéma, ktorá bola prezentovaná. Taktiež, napr schémy pre Trinity tiež nezodpovedajú reálnemu die, aj u Radeonov si si to mohol všimnúť... ale nič, choď ďalej "navrhovať" nejaké tie CPU/APU/GPU.

@ifkopifko: ale ved on len cisto spekuluje, tak ako sme aj my ostatni spekulovali ohladne inych veci, nechapem o co ti ide. A vlakno ma v nazve aj "spekulace", tak je to ok. Trochu iny ton by si si mohol zvolit pri svojej diskusii, nic v zlom .

ifkopifko: mezi obrázkem v prezentaci o Trinity a reálným die je jeden podstatný rozdíl . AMD v prezentaci neuvádělo, kolik procent zabírá GPU.

u Kaveri AMD přímo explicitně v prezentaci uvádí, že GPU zabírá v die 47%. Myslím, že by bylo celkém dost hloupé, kdyby nákres ukazoval , že GPU zabírá např jen čtvrtinu, když mají pod ním uvedené přesné číslo.....

Navíc když se podíváš na Trinity die, tak jak si myslíš že budou vypadat ty poměry u Kaveri ? GPU versus CPU, když AMD uvádí že GPU zabírá téměř polovinu die ?



o velikosti Kaveri jsme už diskutovali dříve tady

del42sa> Ja som tím samozrejme nechcel povedať, že nezaberá tých udávaných 47%, ale to, že tie pomery na schéme tomu nezodpovedajú, a ani rozmer tých modulov nemusí zodpovedať. Je to schéma.

maltra> Veď ja nehovorím, že to nie je OK. Existujú špekulácie zmysluplné a nezmyselné. A čo sa tónu týka, tak poznáš to... "ako sa do hory volá..." ...aj keď to nemusí byť vidieť v tomto vlákne.

Inak, aj mňa by potešilo trojmodulové APU, ale nie ak by to príliš oslabilo iGPU. Aj vydanie silného CPU do socketu spoločného s APU by bolo fajn, toto súčasné trieštenie AMD podľa mňa dosť ubližuje. To ale nie je otázka veľkosti die takého APU/CPU, ale toho, či to tak bolo dizajnované... osobne to "silné CPU" u FM2+ nepokladám za reálne. Trojmodulové APU v pláne kedysi bolo, tak tam nádej ešte nezomrela. Obávam sa ale, že keď to bude aktuálne, tak už to nebude na 28nm.
Najviac by ma ale potešilo, ak by sa konečne výkon na jadro aspoň priblížil konkurencii, potom by aj dvojmodul mohol byť OK. A tiež keby konkurencia nebola energeticky efektívnejšia faktorom cca 1,7. To sú tie naozajstné problémy, nie počet modulov.

To se nestane protože návrh die u AMD je vesměs kompletovanej automaticky kdežto u Intelu ručně protože na to má prostředky. Takže i na stejném výrobním procesu za stejnej podmínek by CPU intelu měl citelně lepší výkon celkově, výkon na takt, výkon na thread, a výkon na W. Samo sebou horší výroba a zbytek tomu dál přidávaj.

AMD potřebuje fixnout architekturu pak se na tom může stavět. Jak moc se to SR podaří uvidíme. Ale vzhledem k tomu že die neni tak velká tak nevidim důvod pro neexistenci mnoha jinejch čipů. Já bych to vydal takto, 4 verze.

- 2 jádra, low end GPU, minimální spotřeba. TDP 45W. Možná by se tohle dalo vyřadit a použít upravené Jaguar jádro.
- 4 jádra, silné GPU, takty co se vejde do TDP 95W.
- 6 jader, low-end GPU, takty co se vejde do TDP 95W.
- 8 jader, L3 cache, TDP co se vejde do 130W. + Níže taktované 95W modely. Tato die by taky existovala v dual-node verzi pro socket G34 a osazovala se do starejch desek skrz bios update aby se server scéna aspoň nák udržela živá. Všechny tyhle die by byly do FM2+, ta se jako platforma oproti LGA1150 nemá moc co stydět, problém neni v platformě ale výkonu těch CPU.

Ale u AMD to teď vypadá na komplet rezignaci. Ala jen 1 jádro, u kterého se budou jen vypínat SP u GPU či jeden z modulů a tim se bude strašně "ekonomicky" vyrábět low-end. Tzn top model v CPU konkurence I3ce a vše nad tim rezignace. Total stažení ze serverů, atd. Tzn nebude se vydělávat. Kdo by si koupil top model APU? ala totálně si zatrhnou jakejkoliv upgrade? A ty nišší modely se nevyplácely ever protože celeron stojí 900kč a pentium 1200. Ne, ta platforma musí nabízet možnosti se někam pohnout. Pokud top model bude občas pokud nedojde na single thread konkurovat I3ce a v GPU někde lehce pod 7750, tak to prostě neni nabídka. Je to pod tou čarou nej cena vs výkon řešení. Je to už v sféře low-endu. A pokud AMd bude nabízet jen low-end platformu kde nebude možnost upgradu CPU výše, tak sorry ale to je finish. Prodá se pár OEM sestav a pár fanoušku si to ze zoufalství koupí a budou všude tvrdit že jim APU stačí. Ake globálně přijdou o veškeré ziskové části trhu. Pokud se to snažej nahnat cenou ala 4 klacky za APU (to je vtip ?), tak toho prodaj ještě méně. Sice asi s většim ziskem ale méně takže menší penetrace trhu = menší ochota pro to optimalizovat SW, a celá huma se může jít klouzat. Atd.