PCTuning fórum

DOC_ZENITH: Už vidim to grafické jádro jak nám počítá x87 thread..... to je naprostá utopie.

a proč ne ? vždyť tou jsou jen výpočty s plovoucí desetinnou čárkou. Co myslíš že počítají třeba takové Tesly ?

Like all previous designs from AMD (and in contrast to Intel), Bulldozer separates the integer and floating point schedulers, register files and execution units. In proof that Sutherland’s Wheel of Reincarnation applies to more than just graphics, Bulldozer employs a co-processor model for floating point and SIMD execution that is shared by both cores in a module – reminiscent of the days when x87 floating point co-processors would reside on a separate chip altogether. One advantage of this more formalized separation is that the floating point cluster might eventually be replaced or supplemented by a GPU shader array, an evolution of Bulldozer to fit the ‘Fusion’ mold. This co-processor model is an example of a substantial change that is also familiar from previous AMD CPUs.

http://www.realworldtech.com/bulldozer/6/

Protože je daleko? Tesly počítaj každá svou věc, jsou v sálovejch počítačích které jsou samy o sobě velké, výkonné a navzájem sesíťované, a jde o centralizovaně rozdělenou práci. Nejde je použít na rea-time redering protože jsou to silné ale vzdálené a latentní výpočetní jednotky. To samé vidim u GPU v APU. I když má třeba sdílenou L3 je to pořát useless latentní v porovníní s FPU jednotkou co sedí na pipeline.

Daleko ?? vždyt GPU shadery, které by potencionálně nahradily FPU jsou/budou přímo uvnitř procesoru.

A co myslíš ? Jak "daleko" od CPU bude Knights Ferry/Knights Corner/Xeon Phi koprocesor (vzniklý z původního Larrabee "GPU") ?

nebo jak daleko od CPU byl matematický koprocesor (FPU) když ještě nebyl součástí CPU ?


\\

Oni na to nejsou schopni vytvořit v praxi SW co v by nahradil standardní win32 x86 software pro CPU a ty se to bavíš o požití těchto zatím stále poměrně neuniverzálních GPU pro nahrazení x87 FPU jednotky v CPU? Mě to prostě přijde nereálné.

bavím se o GCN/GCN2 a dalších generacích GPU integrovaných v budoucích APU.

Kdyby tvá teorie byla realizovatelná, už by to tu sakra dávno bylo, nepřešlapovalo by se tady 10 let na místě s marnými pokusy o zvedání frekvencí, jader, atd. Najednou někoho trklo, nasadíme tam GPU! A vše bude vyřešeno a budeme mít obrovskej FPU výkon? Prdlajs....

proč to doted nešlo ? mimo jiné pro důvody o kterých jsme diskutovali na předchozí straně

Jak daleko? Dost na to aby nemohly pracovat na 1 threadu/ nemohl knight corner nahradit x87 samotného CPU. Přídavné FPU v 80.tých letech byly taky úděsně slow a pro geometrii se žačaly používat až s příchodem P54. Proto pentia tak drtily konkurenci v hernim výkonu protože jejich FPU byla součástí pipeline a nelatentní.

Heh no uvidíme. Tu jde o to jak by se to popralo s klasickým single thread x87 kódem. Pokud to "opět" bude potřebovat vlastní programování tak se nedostáváme nikam.

Zatim mi totiž přijde že se to GPU až na určitý specifický operace nepoužívaj vůbec. I ty slavné video konvertery tam většinou použijou jen ňákou fixní funkci ULV jednotky, vůbc ne samotné shadery pro výpočty. A nemělo by bejt kódování přes GPU samo o sobě x-krát rychlejší? Vždyť má o tolik více "flopů" než CPU. Ale prd a skutek utek.

Oni na to nejsou schopni vytvořit v praxi SW co v by nahradil standardní win32 x86 software pro CPU a ty se to bavíš o požití těchto zatím stále poměrně neuniverzálních GPU pro nahrazení x87 FPU jednotky v CPU? Mě to prostě přijde nereálné.

Kdyby tvá teorie byla realizovatelná, už by to tu sakra dávno bylo, nepřešlapovalo by se tady 10 let na místě s marnými pokusy o zvedání frekvencí, jader, atd. Najednou někoho trklo, nasadíme tam GPU! A vše bude vyřešeno a budeme mít obrovskej FPU výkon? Prdlajs....

nou píše: - programatory su lenivy
- firma to chce lacno. pre firmu nie absolutne zaujimave ze zrychlite program x-krat pretoze to nie je pre nich dolezite. dolezite je aby bol hotovy produkt.
- pouzivaju sa pomalosti typu Java/C# alebo dnes este horsia zhuverilost JavaScript/HTML5 kedy sa musi vykonat tisice instrukcii na to aby ste vykonali 5+5 pretoze je to cele pochovane pod milionom vrstiev abstrakcie.
- HW je lacny. vsetci vam povedia kupi sa lepsie zelezo to je lacnejsie ako to programovat.
- optimalizacie su pre firmu len naklady navyse. nic viac to neprinesie.
- spetna kompatibilita. bozechran ak by ste ten SW nemohly spustit na 10 rokov starom CPU ktore nepodporuje SSE. to vas ukrizuju. vid neschopnost prejst na 64bit systemy co by zabezpecilo aspon SSE2.

Amen

Prehnane receno cesta AMD mi je zahadna aneb "Hura AMD nam dela dobre AVX procesory" a dame si ho do vytrinky a zasedneme k PC s Intelem

Jakykoliv snizovani vykonu x87 jednotek je totalni kravina, a bude to kravina dokud neprijdou programovaci jazyky kde ty SSE/AVX atd jsou pouzivat v beznym kodu.

Kdyz clovek chce rucne vyuzit SSE misto klasickejch x87 instrukci tak nemuze v programu napsat
"x = 5.5*a"
ale skonci u neceho typu
"v1[0] = 5.5;
v2[0] = a;
ssemulfpacked(v1,v2,v3); //bacha je to makro a ne funkce...
x = v3[0];"
pripadne primo u inline assembleru. (a jeste nesmi delat v jave, C# ....) Jasne kdyz potrebujete vynasobit 2 pole tak je to super, ale za posledni rok sem snad takovou ulohu neresil.

del42sa píše:

DOC_ZENITH: Už vidim to grafické jádro jak nám počítá x87 thread..... to je naprostá utopie.

a proč ne ? vždyť tou jsou jen výpočty s plovoucí desetinnou čárkou. Co myslíš že počítají třeba takové Tesly ?

Protoze naprosta totalni nepouzitelna pomalost? Sice ti tam litaj teraflopsy jenze na tisicich jednotek. Radeon 7970 ma 3,79Tflops na 2048SP si to vydel: 1.8GFlops na SP, + zvyseny latence vypoctu, + to musis pustit mimo CPU na nejakejch jinejch knihovnach (dalsi latence) a pak muzes bejt rad ze se dostanes na 5% rychlosti na GPU. Jak to neni algoritmus paralelizovatelnej z vice jak 90% tak nema cenu o GPU vubec uvazovat.

Se mrkni na Amdahlův zákon. Kód paralizovatelnej z 50% znatelne nezrychlis od 16 vypocetnich jendnotek. kdyz by byl paralelizovatelnej z 95% tak uz nemas zadnej prinos zvysovanim poctu jednotek nad 2000. A to paralelizovatelny je tak asi zpracovani signalů a fyzika. Nemluve o tom ze je to za idealnich podminek a zanedbavaj se casy ztraceny na synchronizacich, parkovani vlaken a podobnejch blbostech, ktery v tom nejsou zapocteny.

Kdyz oznacis kus kodu, kterym muze probihat vic vlaken jako usek kde v jednu chvili muze bejt jenom jedno. Tak zamek ma aktualne latence kolem 50ns (pri pouziti mutexu a semaforu z win api uz je to o dva rady pomalejsi) takze prubeh metody jednim vlaknem je o 100ns pomalejsi (uzamknuti a odemceni). Kdyz je to zamceny dalsi vlakna cekaj a nic nedelaj (vyyykon klesa).

Vraz to do kritickyho mista v programu a pak ma te na novim 4 jadru se stestim vykon 150% toho co na 1 jadru. A 10* pomalejsi vyvojovy cykly a ladeni. Jak se nekde musi neco synchronizovat jde vykon do kytek. A lock free multithreading pouzitelne zvlada 10 lidi na svete

Vetsina "Vedecky prace" je prekvapive to sami, paralelni vypocty zadny, jenom to rozdelis do single thread uloh, kazda dostane balicek dat a bezi si minimalne par minut. (aby prestali mit vyznamnej vliv casy na inicializace a distribuci dat). Pak spustis 4 tyhle balicky na 1 pocitaci, na 100 pocitacich v clusteru. Za den prijdes, shromazdis vysledky v jednovlaknovy aplikaci na svim PC, to taky den pocita a je to.

edit:

nou píše:pouzivaju sa pomalosti typu Java/C# alebo dnes este horsia zhuverilost JavaScript/HTML5 kedy sa musi vykonat tisice...

C# neni vyznamne pomalejsi jak C++ (microsofti kompilator, x86/x87 kod), ted naposled jsem dostal na vypoctu CRC32 (4KB tabulky) dokonce asi o 3% nad vykon C++ kodu. Jedinej problem je, ze clovek musi klesnout do unsafe kodu a pouzivat ukazatele. Vsechnu rychlost v dobre napsanym kodu zere detekce hranic poli, pak volani nativnich knihoven (kde ten call je pomalejsi o locknuti dat v pameti a pripadnej preklad datovejch typu na neco pouzitelnyho a nasledny unlocknuti), a pak vecny kopirovani bufferu misto toho, ze ukazatel pretypuju na neco jinyho

ttxman píše:C# neni vyznamne pomalejsi jak C++ (microsofti kompilator, x86/x87 kod), ted naposled jsem dostal na vypoctu CRC32 (4KB tabulky) dokonce asi o 3% nad vykon C++ kodu. Jedinej problem je, ze clovek musi klesnout do unsafe kodu a pouzivat ukazatele. Vsechnu rychlost v dobre napsanym kodu zere detekce hranic poli, pak volani nativnich knihoven (kde ten call je pomalejsi o locknuti dat v pameti a pripadnej preklad datovejch typu na neco pouzitelnyho a nasledny unlocknuti), a pak vecny kopirovani bufferu misto toho, ze ukazatel pretypuju na neco jinyho

sam si to teraz hovoris ze C# je pomaly. ano dokaze byt rovnako rychly ako C++ ale tak sa v nom bezne neprogramuje. videl som clanok kde typek zobral Java kod na nasobenie dvoch matic. zacal dost naivnou implementaciou ktora bola neskutocne pomala. po takej desiatke iteracii roznych optimalizacii ktore odstranily kopirovanie objektov na kazdom kroku az po pakovanie do instrukcii SSE ziskal 1000 nasobne zrychlenie.

ad ak kompilujete kod pre 64 bit architekturu tak sa bezne pouzivaju SSE instrukcie. samozrejme iba ich skalarne varianty takze clovek ziska len trochu vykonu naviac.

No nevím chlapi, ale trochu mi to přijde, že se tady hodně směšují pojmy paralelizace a vektorizace

Hladis: AMD opravdu nedělá dobré AVX procesory (ty dobré AVX dělá Intel)

nou píše: sam si to teraz hovoris ze C# je pomaly. ano dokaze byt rovnako rychly ako C++ ale tak sa v nom bezne neprogramuje.

Ono ani v C++ se bezne neprogramuje rychlej kod. Jenom v nem aktualne dela podstatne min lidi co o optimalizacich vedi kulovy.

u matic je roblem je prevazne v hranicich poli .. kdyz je pri kazdy indexaci vygenerovanej
if(x>=0 && x<array.GetLength(0))
neco = array[x];
else
throw new IndexOutOfRangeException()
tak ti pri nasobeni matic for cyklama ten checking sezere 90% procesorovyho casu jak nic. Chce to trochu vedet jak to facha a minimalne psat ty cykly tak aby se optimalizovali. (taky duvod proc pouzivat foreach kde tohle prekladac nedela)

Ja povazuju za dulezity, ze to jde. C# mi usetri proti C++ spoustu prace a chyb. A kdyz potrebujes vykon tak to jde taky. Problem vidim porad jenom v SIMD instrukcich (jedina aktualne pouzitelna cesta jsou intel performance libraries)

webwalker píše:No nevím chlapi, ale trochu mi to přijde, že se tady hodně směšují pojmy paralelizace a vektorizace

Protoze pro programatora je to v zakladu porad ten samej problem. Co jde "vektorizovat" jde paralelizovat, obracene to tak uplne neplati (vlakna jdou narozdil od SIMD instrukci jeste pouzit na spousteni vic sekvencnich kodu soucasne, a na nektery dalsi slozitejsi ulohy). Nejpodstatnejsi rodil je vicemene v mnozstvi rezie pri pouziti SIMD instrukci / vlaken. Pouzit vlakna se velice casto nevyplati kvuli overheadu na jejich vytvareni, spousteni a synchronizaci. SIMD vice mene muze pouzit vsude kde opakujes nejakou cinnost nad polem bez overheadu. Jenze to bud nejde jako v pripade C#/Javy bez volani nativniho kodu, nebo je to naroubovany prez assembler a makra jako v pripade C++. Az nekdo prijde s nejakou user friendly implementacej budou vsichni hrozne vdecny a treba se to i zacne pouzivat

no najviac user friendly ako pisat vektorizovany kod je zapnut auto vektorizaciu v gcc. potom vam takyto kod prelozi prelozi gcc za pouzitia vecktorizovanych SSE instrukcii. (gcc ich na x64 pouziva by default. ale iba ich skalarne varianty) problemom je ze clovek stale musi kontrolovat samotny ASM ci to prekladac spravne pochopi a zvektorizuje. viac na http://locklessinc.com/articles/vectorize/

druha moznost ako pisat vektorizovany kod je pouzit build in funkcie alebo instrict. ale to sa takmer rovna pouzitiu inline ASM pretoze clovek nasledne pise jednotlive instrukcie v takomto formate a toto nikto nebude pouzivat. existuju aj specializovane SSE kniznice na pracu s maticami a vektormy pre 3D rendering ale aka je ich pouzivanost je otazne.

nou píše:no najviac user friendly ako pisat vektorizovany kod je zapnut auto vektorizaciu v gcc

Jo to je fajn. Bohuzel takovahle optimalizace navic predpoklada, ze vis co presne aktualni verze a pripadne parametry kompilatoru delaj s kodem. Pravidelna kontrola funkci po kompilaci funkce disassemblerem atd. Rekompilujes si to za pul roku a je to najednou 3* pomalejsi, musis to prepsat jinak, dalsi prace navic. (nedej boze kdyz je to 3rd party kod o kterym nic moc nevis). Moc prace navic a je to nejisty.

Lepsi byla podpora primo v jazyce a ne v kompilatoru, aby to na kazdym kompilatoru nefachalo jinak. Par struktur typu Vector8f, Vector32uint8 aspon zakladni matematika na nich SIMD akcelerovana. Pak by se to mozna pouzivalo vic. A navic by to slo implementovat napric vsema jazykama vicemene stejne.

Vlastne v pouziti SIMD neni zadna novinka od doby MMX (15 let?) snad krome automaticky vektorizace v kompilatorech. Programovaci jazyky by si zaslouzili poradnej upgrade. Na poli pouziti vic vlaken se aspon trochu neco deje.

ať tu vážení není z toho holubník ...Odlítám na dovču...

Nechci vám do toho kecat, ale dle mého nějaká komplexní autovektorizace v kompilátoru nebude nikdy už z povahy věci samotné (kompilátor nemůže vědět co vlastně chcete dělat). Každý "puntíčkářský" programátor si bude muset tuto kritickou část kódu odladit imho vždy ručně (pokud tedy bude potřeba - většinou však to ani nepotřebuje).
Na rozdíl právě od paralelizace (a to příkladně i na gpgpu) kde je toto v celku reálné třeba pomocí JIT kompilátorů, které v době překladu mají všechny informace o hardware na kterém běží a mohou ho beze zbytku využít.

webwalker píše:Nechci vám do toho kecat, ale dle mého nějaká komplexní autovektorizace v kompilátoru nebude nikdy už z povahy věci samotné (kompilátor nemůže vědět co vlastně chcete dělat). Každý "puntíčkářský" programátor si bude muset tuto kritickou část kódu odladit imho vždy ručně (pokud tedy bude potřeba - většinou však to ani nepotřebuje).
Na rozdíl právě od paralelizace (a to příkladně i na gpgpu) kde je toto v celku reálné třeba pomocí JIT kompilátorů, které v době překladu mají všechny informace o hardware na kterém běží a mohou ho beze zbytku využít.

To co sem psal naposled sem minil tak, ze je to fajn, ale nespolehlivy coz je to co ty vicemene rikas. Jenze to plati i pro GPGPU tam taky program nevi jak ma optimalizovat a jeste ma malo casu a navic je to jeste problem v mire paralelizace.


Takze abysme sjednotili pojmy. Ja to vidim takhle:
Vektorizace - uprava algoritmu tak, aby slapal na vektorovejch instrukcich, ale sekvencne v jednom vlakne.
Paralelizace - uprava algoritmu tak, aby se zpracovani mohlo rozdelit do nezavyslejch vlaken (CPU) komunikujicich prez zdilenou pamet.

Automaticka vektorizace: s trochou stesti ano.
Automaticka paralelizace pro automaticky nevektorizovatelny ulohy: Podle me v pouzitelny mire ani nahodou. Je to daleko slozitejsi nez vektorizace. Deadlocky a race conditions poradne neodhadne ani clovek, kdyby to slo jednoduse algoritmizovat nejsou s tim takovy problemy.


Rozdil mezi JIT a statickym kompilatorem je v tomhle pripade na strane tech normalnich. Kdyz si tam ten HW a optimalizace nacvakas spravne, tak je tam mas. JIT ma z principu (just in time) malo casu a proto neprovadi ty komplexni (a pomaly) optimalizace. OpenCL a podobny legrace jsou spis staticka kompilace na miste roubovana na konkretni HW nez JIT kompilace.


A asi bysme toho meli nechat nebo nam to flanker po dovoleny smaze

Můžu zakročit i já pánové Takže se už raději dále věnujte AMD Steamrolleru/Excavatoru, protože už diskuse směřuje hodně do programování a optimalizací SW. Sice to s procesory úzce souvisí, ale...

Prvni zminky o 28nm Jaguar (Bobcat 2) aka btver2 v gcc mailing listu

Cache L1 32K, L2 2MB. Pridane ISA extensions nad btver1: SSE4.1, SSE4.2, AES, PCLMUL, AVX, BMI, F16C a MOVBE.

Zvlastni tak masivni L2 v lowpower. Zrejme bude sdilena mezi 2 nebo i 4 jadra.
Krom absence viditelne "drahych" FMA a XOP intrukci zvlada AVX. Zpracovani po 4x64b vektorech zni nepravdepodobne, takez zrejme 2x128b -> ~10h 128b FPU? Dorovnaji toto moderni Atomy?

Bobcat je fakt dobrej CPU, i proot jsme tehdy více čekal právě od FX. Wow, AVX v Bobcatu II?

AVX je tu uz od uvedeni SB ale realne vyuziti/prinos je skoro 0 (prozatim). Myslim ze takovemu slabemu cpu jako Jaguar bude podpora AVX uplne na prd,to same u Atomu.Bude se to akorat dobre vyjimat v urcitych benchmarcich...

čili vše nasvědčuje, že x86 CPU jsou samo o sobě "zastaralá" a nehorázně závislá na softwaru. A bez softwaru se už klasicky výkonem moc nepohne. Leda ta integrace GPU do více procesů...Na rozšíření AVX by však měl tlačit i Intel.

bez softu ti je aké koľvek CPU nanič a nové inštrukcie na tom nič nemenia
to že x86 už dýcha z posledného je známe už asik 20r
problém je to neskutočné množstvo softu a aj istá kompatibila smerom dozadu kedy funguje aj soft starý 30r a toho sa ľudia iba ťažko vzdajú či už to má význam alebo nie
stačí pozrieť koľko trvalo aby sa rozšírili X64 OS a pritom CPU to zvládajú dlho predlho