haswell vs. ivy do budoucna.

[Vlastik80]

Prosím o rychlé vysvětlení oč u TSX šlo- v čem mělo jít o revoluci a proč se stalo že to nevyšlo ani u jedné řady cpu co to mají podporovat? Díky...

Edit- a můj humorný výklad? No já před lety programoval v assembleru což bylo hnus, pak turbo basic, basic, amos atd. ale prostě mi přišlo že by stačilo mít paralelní programy pro zpracování, což už jistě je, já svého času prostě jel po řádcích a aplikace činila vše postupně, zmnožením tohoto do paralelního jsem si představil práci programu na bázi košíčku kam můžou všichni najednou ale nestane se že by došlo k NOP či ERR...

[DOC_ZENITH]

Prosím o rychlé vysvětlení oč u TSX šlo- v čem mělo jít o revoluci a proč se stalo že to nevyšlo ani u jedné řady cpu co to mají podporovat? Díky...

Edit- a můj humorný výklad? No já před lety programoval v assembleru což bylo hnus, pak turbo basic, basic, amos atd. ale prostě mi přišlo že by stačilo mít paralelní programy pro zpracování, což už jistě je, já svého času prostě jel po řádcích a aplikace činila vše postupně, zmnožením tohoto do paralelního jsem si představil práci programu na bázi košíčku kam můžou všichni najednou ale nestane se že by došlo k NOP či ERR...

http://www.anandtech.com/show/6290/maki ... extensions

http://www.sisoftware.co.uk/?d=qa&f=ben_mem_hle

TSX nastoupilo s haswellem, měla to bejt jedna z jeho stěžejních featur. Platná hlavně jdeme li nad 4 jádra že... ale tejden před launchem LGA2011-3 Xeonů Intel ohlásil že v určitejch situacích to produkuje bugy a kraviny, a že to chce HW fix, nejde to SW ošéfovat, takže to vypnul u všech Haswell based CPU globálně. Některé méně standardní early I7 mičky před začátku H-refresh éry a předprodukční eng samply Xeonů v kombinaci se starym mikrokódem to maj aktivní, dle toho se to podařilo změřit.

Současná implementace je ale poměrně divná, mizerně to škáluje u dat co se nevejdou do L1 a pod... prostě je to zabugovaný a fixlý to bude nejdříve v Broadwellu.

[oneb1t]

to uz je vsechno davno vyreseny hlavni problem je v tom ze to zpomaluje vyvoj protoze krome vlastnich bugu aplikace resis jeste dalsi problemy vznikajici z ruznejch deadlocku a synchronizace informaci mezi vlaknama

navic tomu pomerne malo lidi do detailu rozumi a skoro nikde se takova vec poradne nevyucuje

na serveru to neni takovej problem tam se vetsinou obsluhuje jeden klient = jedno vlakno (treba apache2)
jenze to taky neni uplne idealni protoze to zas vytvari triliardu vlaken ktery se hadaj o par jader a context switche tam zabijej vykon

pak tady mas apky jako lighttpd ktery jsou sice single thread ale ve vysledku je to rychlejsi jak beznej apache2 protoze misto aby se pracovalo na skalovani pro vic vlaken se pracovalo na maximalni optimalizaci rychlosti pro jedno vlakno (nejsou context switche a pozadavky se obsluhujou tak jak prichazej)

TSX prinasi lockovani nativne ale pomalejs nez kdyz si to programator rozhodne sam protoze se to pak deje skoro furt ale v realnym pripade to neni potreba lockovat furt dokola

[Vlastik80]

Laická otázka - nemá Intel nejlepší inženýry na testování fcí u samplů než vyjde final produkt?? To pak vypadá že ne a pokud ano pak by to bylo omluvitelné snad jen náhodnou kombinací požadavků na cpu která způsobí např. přehlcení apod.- nestalo se něco už v minulosti u Intelu s floating point??? Tuším že ano...

Takže u L1 jde o přetečení? To jsou mi věci že to projde ven do final kousků... Jasně lock pak, ale i tak...

[oneb1t]

oni to urcite testujou ale vetsinou jsou to nejaky specificky zavady na ktery se blbe da prijit navic znacny plochy v cipu navrhuje pocitac a bude jen par lidi ktery do detailu rozumej tomu co ktera cast presne dela

z toho taky vznikl vtip

Proč je Pentium doopravdy rychlejší než 486?
Protože 486 výsledky počítá, kdežto Pentium je odhaduje!

kde v nekterejch pripadech pentium 1 vracelo spatnej vysledek (da se o tom vygoolit vic jestli te to zajima)
http://en.wikipedia.org/wiki/Pentium_FDIV_bug

[Vlastik80]

jj to bude ono, díky, vím že se o tom psalo, no když vezmu v potaz Murphyho zákony, pak stejně platí že chyby má každé cpu, jen se na ně nepřišlo a přijde se na ně až se to bude nejméně hodit a až to způsobí co největší škody...

V éře 486 se mi líbilo že se začaly nasazovat ko-procesory, záviděl sem tomu, protože já měl obyčejnou 80386 a ty 486 těch bylo snad více typů - slintal jsem nad tím jak musej bejt skvělý...

[oneb1t]

tak ono nejsou ty problemy jen v samotnejch procesorech oni jsou pak nasledne i v programech
tady jsou treba "vtipny" selhani z minulosti

http://cs.furman.edu/digitaldomain/them ... umeric.htm
http://www5.in.tum.de/~huckle/bugse.html

[DOC_ZENITH]

Vlastik: Ihmo největší power 486 byl v tom že to byl první CPU co měl vlastní L1 cache, FPU byla cool ale L1 nám dala výkon. A u DX4 pak zdvojnásobená + writeback zápis opět zdvojnásobil výkon. Pentium přineslo FPU synchroní s ALU součástí 1 pipeline (ala čti nízkolatenční), 2x tak rychlou FSB a rovnež onboard L2 sychro pipelined burst cache vázanou na FSB.

Back on topic, AMD taky mělo své, vzpomeň na TBL bug první K10 Phenomů a Opteronů, to v kombinaci s nástupem Nehalemu AMD vykoplo ze serverů... už pak nikdy neměli comeback, ačkoliv magnycours socket G34 platforma ve své době nebyla vůbec zlá.

Nebo třeba Zambezi vs Vishera, opticky identické jádro, jen opravené bugy a vněkterejch situací to znamenalo až o 25% více výkonu na thread.

[Vlastik80]

Škoda že Intel nepokračoval v tom co tak pěkně začali- např. skok z Q6600 na i5-2500K mi přišel znatelný, nemluvě o tom že jsem přešel de facto z E4400 na 2500K a to byl skok už velký...

[DOC_ZENITH]

Největší (resp poslední velkej) skok byl z Core2, což byl poslední procesor staré P6 architektury na Nehalem (první I7 do 1366) Nehalem přinesl komplet novou architekturu a hlavně silnou FPU. Sandy bridge je už jen vylepšenej Nehalem, má rychlejší a synchroní cache (hlavně L3), a hlavně jde vysoko a strašně easy taktovat, ten se mezi lidi tim zapsal a stal se problémem pro samotnej Intel, blbě se jej totiž překonává i v rámci vlastní stáje. Haswell jej sice vydrtí v novejch technologiích (AVX, FMA) ale v praxi je žádnej běžnej SW nepoužívá, vše se dnes uptimalizuje na Nehalem, protože to automaticky znemená že to poběží dobře na všech CPU z něj vycházejících ( Nehalem, Lynfield, Westemere, Sandy Ivy, Haswell, Broadwell, atd atd to bude pokračovat dokud Intel nezmění architekturu). Tím zároveň výkkonostně odpadly starý Intely a AMDčka co tuhle architekturu nemaj, ačkoliv v den Vydání Nehalemu vypadal celkem obyčejně, protože ve starym softu programovanym pro P6 byl asi jen o 10% rychlejší, když jej dnes po 6 letech postavíš v moderních hrách proti Core2 quad tak tu Core2 naprosto deklasuje.

Tohle je velkej problém pro AMD protože Intel compilery sypou kód optimalizovanej pro jejich CPU který maj úplně jinej poměr sil ALU/FPU a podle toho to taky lecky doapdá.

[dexterav]

mno nehalem čo sa týka oc tiež nebol máčalka
4GHz ako nič čo pri 920 predstavuje slušné % hore kedže vtedy ešte ani turbo nebolo také agresívne

[DOC_ZENITH]

Jo to byly OC... E4300 1,8 @ 3,4Ghz
.................... I7-920 2,66 @ 4,2Ghz
.................... I7-3820 3,6 @ 5,125Ghz

Od té doby je to nemastné neslané.

[Vlastik80]

Skylake údajně nebude taktovatelný, odemčené -K modely budou pouze v rodině Broadwell (tj. první 14nm ještě před Skylake).
Přesné datum uvedení Broadwellu neznám, něco mi ale říká, že bude v létě.

... zajímavé informace, doufám jen že Intel nakonec mile překvapí.

[havli]

Skylake-K imho budou, ale az pozdeji... aby melo vubec smysl vydavat Broadwell-K.