PCTuning fórum

něco ze SA :

On the iteratively improve performance front, look what Sun/Oracle has done with the SPARC T series. The T4 has 5x single thread performance improvement over T3!!! Obviously AMD can’t achieve this (as T3 was in-order execution), but a future version *may be able to do one thing the T4 does: combine the execution resources of the two int cores when only one thread is running. If I had to bet, AMD engineers are working on, or at least considering this right now.

Godlike:

The closest thing to AMD’s new Bulldozer architecture out there is Sun’s Niagara, and no one would accuse those designers of following the pack.

se koukni na obrázek T2 UltraSparc core, v jádru máš společnou FPU a dva integrer clustery , společný dekodér, fetch, nezní ti to povědomě ?
Akorát že oni nazývají jádrem celý ten modul s dvěma INT a FPU a zbytkem výpočetních částí a navíc každý ten INT umí SMT/HT

Tak zbejva asi jediny.Pozvat engineering team ze Sunu, aby ten indickej team z AMD kopnul do zadku....Treba by pred ty Sun-acky lidi polozili lidi z AMD vykresy, chvili by na to koukali a nekdo ze Sunu by zapichnul prstem do vykresu a rekl: " Wtf this?Are you fucking mad?".

del42sa píše:něco ze SA :

On the iteratively improve performance front, look what Sun/Oracle has done with the SPARC T series. The T4 has 5x single thread performance improvement over T3!!! Obviously AMD can’t achieve this (as T3 was in-order execution), but a future version *may be able to do one thing the T4 does: combine the execution resources of the two int cores when only one thread is running. If I had to bet, AMD engineers are working on, or at least considering this right now.

Godlike:

The closest thing to AMD’s new Bulldozer architecture out there is Sun’s Niagara, and no one would accuse those designers of following the pack.

Sparc T4 je zajímavej čip. Tehdy mě hodně zaujal když jsem o něm četl. 8 jader na každém z nich 8-mi násobné HT. Délka pipeline 16 stages na INT a 11 na FPU. (to mi připomíná že co se pipeline týče u BD jsme se vždy bavili jen o INT).

Má navíc velice unikátní features typu interní thread scheduler a priority manager, ala když na tom jednom jádru visí třeba 4 vlákna a OS řekne žed toto má prioritu tak jí má a žádné ostatní nebude brzdit jeho výkon. + Se umí přepnout do takzvaného single-thread modu kdy se kompet celé to vnitřní (říkejme tomu HT) ale i ostatní jádra vypnou. Většinou se to děje za předpokladu že co zrovna CPU dělá nepřetíží ani to 1 jádro + do tohoto stavu se CPU přepne komplet HW cestou, zbytek křemíku neidluje ale je doslova odpojen a dokonce se mohou některé jeho části použít pro navýšení výkonu toho jednoho aktivního (myslim že cache a to včetně L1 a další věci o kterejch už nevim) + to má v tomto režimu extra malou spotřebu.

Velice zajímavej čip, ale ruku na srdce, neni to X86 a na X86 se asi nedočkáme něčeho jako je interní task manager v CPU či schopnosti odpojovat fyzicky jádra za chodu a spřahovat jejich části v případě potřeby silného singlu, atd.

Prostě jak já říkám, X86 je dnes už nehoráznou brzdou, poslední čipy Power or IBM a třeba Sparc T4 jsou toho jasnym důkazem, že x86 už prostě neni král, je jen levná kvůli tomu že má momentálně největší mass produkci a windows na ničem jiném nejedou že. Ale to se může, a já doufám že změní.

Edit: Nutno ale říci, že srovnávat T4 sestaršími Suny je mimo. Je to pro ně obrovskej krok vpřed, vždyť starý sparcy nebyly ani out-of-order a neměly FPU.... byly to CPU výkoné jen v hodně specifickejch situacích, jinak většinou dostávali od Xeonů a Opteronů pěkné kopance. Sun (dnes Oracle) přešel defakto od 486SX architektury k P3....

Del - ano připomíná, až na to že ten produkt sunu neni X86 tudiž bude nativně mnohem efektivnější a umí to o čem fandové AMD (a já taky) sní už 6 let, ala něco jako reverzní HT, v případě nutnosti je to schopno podat velice solidní single výkon, což BD nedovede. A stejnak, na schématu to vypadá podobně ale jádro pudla bude úplně někde jinde, jsou to naprosto nesrovnatelné architektury. Na grafech vypadá FPU u Core2 a Nehalemu stejně, v praxi ji má Nehalem až 2x efektivnější. Go figure......

Godlike - ono se i jednoho dne může stát. Loni se šuškalo že Oracle hodlá CPU divizi co získal koupí Sunu rozpustit....... že pro něj neni výnosná. Ale kdo ví jestli s tim právě T4 nezahejbe.

ano já vím DOC, jen poukazuju na to, že ty architektonické řešení jsou velice podobné. Evidentně se AMD inspirovalo tam. Zajímavá je i ta různá délka pipelines , jiná pro INT a jiná pro FPU. Celkem by bylo zajímavé zjistit, jak to má BD.

DOC_ZENITH: Imho ty jsi RISC procesory příliš "oslněn". Já bych však řekl, že trendy jsou spíše opačné. Když koukneš na dnešní x86 cpu, zjistíš, že se začínají po předchozím RISC boomu navracet zpět k CISC architektuře. Pročpak asi?
O délce fpu pipeline jsme už ale mluvili a to v souvislosti s tvým výpočtem/odhadem výkonu cpu podle (poměru) délky pipeline. Nebo se pletu?

Del-: Tak když se kouknu na to schéma, tak vidim schéma 1 jádra. Tohle je tam v tom CPU 8x. A vidim schéma 1 jádra které má k dispozici 1 dost silnou 11 stage FPU a dvě 16 stage INT. To je dost rozdíl oporti BD, kterej žene 2 thready po 2 nezávislejch INT které nemohou spolupracovat na jednom threadu a sdílej mezi sebou 1 FPU. U sparcu můžou spolupracovat a počet threadů je až 8 a nehrozí mi díky tomu internímu priority managementu že by mi klesal výkon na thread když to nebudu chtít. Tohle je rozdíl, komplet rozdílnej přístup. BD má v modulu 2 nezávislé pipeline neschopné jakkoliv spolupracovat každá s vlastním threadem sdílející sheduler, FPU, L2. T4ka má v jednom jádru na jedné pipeline silnou FPU a dvě INT, oboje s 8-minásobným HT s priority managerem. Tudiž od pohledu je T4 dělaná na single thread obvzláště v INT oblasti s možností jej rozkrájet až na 8 threadů pro zlepšení prostupnosti v server loadu, s tím že je tu pojistka že v případě potřeby mi ten výkon v singlu nepoklesne.

U BD mi vrtá hlavou jedna věc a tou je sdílená FPU. Nevím jak je tam ta nezávislá FPU sesinchonizovaná a komunikující s dvěma ALU. Nemůže nastat situace že jedna ALU musí čekat když chce provést FPU operaci? Netvoří se tam ňáké latence? Podle AMD, pokud se nejedná o 256-bit AVX instrukce tak by toto nastat nemělo ale mě to steně vrtá hlavou. Při představě že jedno jádro modulu obsadí FPU svym požadavkem, nebrzdí to práci druhého když zrovna po ní chce něco také, netvořej se tam prostě latence a nekriplí to celkovej FPU výkon? Toť otázka a kdo zná odpověď možná zná vysvětlení pro herní výkon BD.

Webwalker: No idea, nejsem vývojář CPU. A nevidim žádnej návrat k cisc, všochni kráči na poli PowerPC se naopak derou za stále větší efektivitou. Co se vydalo směrem k cisc? Atom? Ten je naprosto useless. ňáké ARMy? Ty jsou výkonem také naprosto useless. Bobcat kterej vychází z K6 či snad BD? Nevidim tu žádnej dobrej CPU co by se vracel k cisc. Dnes jsou trendy naprosto zvrácené, už se nežene za výkonem ale všude se počítá výkon/plocha/wat a počet jader je adidas a pak to dopadá výplody jako je BD. Dle mého názoru tyhle trendy jsou předzvěstí pádu x86 impéria.

Měl jsem tu čest mít v ruce ctyřprocesorovou G5 od IBM. Ve své době niak nedrtila, byla dobrá, to jo, ale že by to drtila? Ne, výkon jejích jader mi přišel asi jako měla K8, atd. Kde je dnes power Gen. 7? Gmm? Kolikanásobně nám výkon vzrostl? Hmm? Kde je Sparc T4 od sunu oproti T3? +250% v multi a 450% v singlu? Když se oproti tomu kouknu na x86, kde je BD oproti K10 ehm.... kde je i SandyBridge oproti Nehalemu. Průměrně +25%? Kolikže to bylo let? pro 25%? Myslim si že nám zde už drobátko dochází dech a x86 se dostane do stavu agonie kdy už výkon půjde zvedat jen zvedáním počtu jader/CPU a to je slepá ulička. Kdežto když se kouknu na PowerPC architektury nemaj problém mezigeneračně zvedat výkon o 100+% jako jsem u toho byli zvyklí u x86 v 80. a 90. letech. X86 prostě dojde dech. V cheap low endu a mobilních devices jí nahradí ARMy a ve výkonejch strojích a serverech jí časem vydrtí PowerPC. Vlak vývoje a růstu výkonu PowerPC totiž moc nezpomaluje, zato vlak x86 u Intelu dost zpomalil a u AMD mu i odpadávaj kusy plechu.

Já vidím dvě EXU0 a EXU2 . Z každého jdou dva thready , což je dohromady 4 na to jejich "jádro".

Webwalker: my se jen bavili o tom, že u BD je minimum branch misprediction penalty 20 cycles , čili hloubka pipeline bude 20 stages (celkově) Ale jestli jsou pipelines v co-procesoru (což vlastně FPU je) všechny stejně dlouhé jako pipelines v INT to nevíme...

DOC: to že se ty jednotky umí spojit pro vykonání single thread to přece vím, tuto schopnost má UltraSPARC T2 Plus , který přinesl možnost SMP http://en.wikipedia.org/wiki/Symmetric_multiprocessing

nakonec to bylo už v tom horním postu hned nahoře. A já jsem přece už dávno mluvil o tom, že BD modul ke stejnému principu přímo vybízí. (zatím to ale bohužel neumožňuje)

Znova sa rozobera x86 ISA (zastarala / nevhodna z ?? dovodu)... Co ma tato instrukcna sada spolocne s dizajnom cipov ?

ta veta mala zniet:

DOC_ZENITH píše:Prostě jak já říkám, dizajn AMD /INTEL-u je dnes už nehoráznou brzdou, poslední čipy Power or IBM a třeba Sparc T4 jsou toho jasnym důkazem, že tento dizajn už prostě neni král, je jen levný kvůli tomu že má momentálně největší mass produkci.

EDIT: a ked sa konecne po viac ako dekade AMD rozhodne urobit zasadny krok s dizajnom svojich x86 cpu, tak tu mame v komentaroch maximalne "splash of s**t". Velmi by ma zaujimala medzigeneracna kompatibilita - a ak by uz aj kompatibilita bola, tak vykon aplikacie skompilovanej na "instrukcnu sadu verzie 1" na tom ultra super duper rychlom RISC CPU, ktory podporuje "instrukcnu sadu verzie 10"
Alebo chceme skoncit ako je teraz popularne v mobilnej sfere - vid priklad: Android a jeho uzasny Dalvik. Tak to nam potom treba povedat, ze tieto "Super CPU" su stale prilis pomale na to, aby krili koli univerzalnej kompatibilite potrebne spomalovace.

p.s. na Windows mobile bol rozdiel native code (ARMv5) vs .Net Compact framework na tychto zariadeniach v mnohych veciach dost viditelny. Nasledne ked som este videl porovnanie o kolko je .Net (Mono) / JRE na Androide rychlejsi oproti Dalviku, tak to bolo na tazky facepalm. Staci vsak zacat pracovat s polami (matice, spracovanie obrazu) a ide do sr*ciek s rychlostou oproti nativnemu kodu aj Java aj .Net.

DOC_ZENITH: FlexFPU BD sdílí(musí) s int jádry retirement a i load/store je prováděno AGU(LSU) z int části. Prostě řečeno ty dvě AGU na jádro musí obhospodařit nejen int ALU, ale také fpu. Pokud je nějaká int instrukce závislá na výpočtu v fpu tak se musí samozřejmě čekat (u Intelu také). Další problém nastává u výpočtů s rozdílnýma latencema, kde se můžou "srazit" na retirementu (Intel to má vyřešené lépe). No a pak je otázka jaké latence mají samotné výpočty (třeba SSE)?

del42sa: U K10 délka fpu pipe byla delší než int. Z povahy věci by to mělo být obdobné i u BD. IMHO

Trovaricon: S tím x86 máš pravdu, proto já uvádím RISC/CISC a nadále si stojím za tím, že CISC je v mnoha směrech výhodnější

DOCente, skutecne 11(!) stages na FPU? Ja vidim 27.

Cesta k CISC: Jak naprosto presne definovat CISC? Non-load/store, ortogonalni inst set? Nevyhovuje nahodou filosofii CISCu taky milion instrukci na vsechno? U modernich CPU se rozsirujici sety ani nevejdou do text fieldu v CPU-Z...

Tak tak Yuri:

T2: 8 stages INT/12stages FPU

T4: 16 stages INT/20stages Load Store Pipeline/27stages FPU pipeline

Integer execution unit. The integer execution unit (EXU) is capable of executing up to two
instructions per cycle. Single-cycle integer instructions are executed in either the EXU0 (slot0)
or EXU1 (slot1) pipeline. Load and store address operations go to EXU0 (slot0). Branch
instructions are executed in EXU1 (slot1). Floating point, multi-cycle integer, and SPU
instructions go thru the EXU1 (slot1) pipeline. Store data operations go to EXU0 (slot2), but
are not considered separate instructions by the EXU since the store address operation must also
occur for the same instruction.

Je tu koukám tvrdé lobby proti CISC, x86 či Intel/AMD designu, ale já bych to viděl složitěji. Výhody RISC se naplno ukázaly už někdy před 20ti lety, byly výkonější než CISC a téměř všechny CISC kromě x86 jimi byly vytlačeny. Jenže od té doby došlo k velké konvergenci CISC a RISC, přidávaly se instrukce do RISC a Intel/AMD zase zabudovaly původně RISCové nápady do vnitřní struktury procesoru (kdosi tu říkal že dnes je x86 procesor navenek CISC, ale uvnitř RISC, není to daleko od pravdy, taky mi to trochu připadá jako HW dekodér před RISC-like chipem), což velice vyrovnalo výkon obou přístupů. To je myšleno tím návratem k CISC.

DOC_ZENITH: Ano, výkon SPARCu T4 vzrostl mnohem výrazneji, ale je nutno vzít v potaz oproti čemu. Jak i říkáš, tyhle předchozí Sunovské architektury byly takové spíš 486ky (práce na nich je peklo), to že někde zatuhli z vývojem a teď to dohnali neznamená že jsou perspektivnější do budoucna. Stejně tak to že výkon půjde zvedat hlavně zvedáním počtu jader není až tak problém x86, jako výrobních procesů a fyzikálních limitů, na které budou dopadat všechny čipy.

Abych se zastal x86 - budou existovat rychlejší alternativy, ale na to jakou univerzalitu a kompatibilitu přináší, je ta cena (v podobě obětovaného výkonu) velice malá

No vždy se říkalo, že u x86 se vnitřně převádí instrukce do RISC, což je samozřejmě pravda, nicméně u dnešních cpu je vidět snaha převádět do RISC instrukcí až na poslední chvíli (nejlépe až při odesílání do výpočetních jednotek) a držet strukturu mops v pipeline co to jenom jde. V pipeline se pak nepohybuje tolik uops, což zvyšuje její propustnost.
Imho tohle byl také problém P4, která vytvářela příliš uops a zahlcovala pipeline, pokud se tedy nemýlím.
Problém se šíleným množstvím x86 instrukcí je dostatečně známý, s každým novým cpu vznikají další a další, kolik jich vlastně máme? 1000?

20 stage ALU pipeline není nic extrémního v porovnání s Inteláckým SB s 18 stage. Dá se říct že těch 20 je dnešní optimální délka s ohledem na blízkou 4-6 letou budoucnost. BD není vysokofrekvenční architektura a proto je nízké IPC dost neomluvitelná chyba. To je pro všechny kteří tady vykřikují, že je jim jedno na jakých taktech BD poráží Thubana.

A ještě k délce pipeline. Samotná délka nic nevypovídá o dosažitelných frekvencích, protože je třeba vzít v potaz i funkcionalitu. Pokud Intel zvyšuje počet stupňů pipeline, tak je to přidáváním vylepšení pro zvýšení IPC výkonu. Je nereálné, že by třeba Intel co dva roky totálně překopával pipeline jen kvůli zvětšení pipeline o 2 stupně. Ke zvyšování frekvencí tak dochází pouze díky odstranění bottlenecků s revizí frekvenčně slabších míst.

Reálný výkon takt na takt (reálné IPC) odráží vyspělost architektury a tím i know-how jejich tvůrců. Dá se říci, že je to asi nejsložitější věc na návrhu čipu. Tvůrce musí mít vizi a musí implementovat pouze technologie přinášející výkon (z té hromady nesmyslů co se objeví). Není bohužel překvapením, že AMD v tomhle poměrně značně zaostává (neargumentujte Bobcatem, který je architekturou dost pozadu, porazit Atom není žádná výzva). Nízký výkon takt na takt není chtěná vlastnost, nýbrž bohužel přímý odraz vývojových schopností AMD.

SB ma sice dlzku pipe 18, ale ma naviac μop cache s kapacitou 1536 µops, takze casto sa usetri niekolko cyklov pocas fetch + decode ak su instrukcie v cache. Podla intelu je ten hit rate 80%.
A realne je to potom rychlejsie ako Nehalem ktory ma 16 stage.

tak koukám, aby mi ten THuban ještě dlouho vydžel

Rozdíl je markantní mezi K10 (12stages) a BD (20stages)

K8 prodloužila pipelines o dva stupně oproti K7 (10 stages)

K8 12stages INT/17 stages FPU

kolik měla K8?

Vivec píše:kolik měla K8?

Imo stejnou jako K10.

Jo, K8 mala tiez 12 stages, ale 2x pomalsi decode ako K10. K7 mala 10 stages.