Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Je krásně vidět, jak zase zapracovalo PR oddělení a překroutilo to tak, aby se to zrovna hodilo do krámu. Není to tak dávno, kdy naopak AMD křičelo na celé kolo, že má lepší FPU než Intel, bez čehož vlak rozhodně nepojede...Myslím, že to bylo v době prvních Athlonů, kdyžtak mě opravte.
Nemyslím si, že můžete takhle porovnávat dobu jedno-jádrových CPU s dobou 4 a více jádrových.
Podívejte se na Intel ten sdílí celé jádro přes HT a tím navýší výkon o kolik - 60% ?
Osobně si myslím, že to je dobrá cesta (sdílet FP), protože tak 90% práce CPU je celočíselná....čas ukáže.
A nielen to, vo vedeckej oblasti sa výpočty presúvajú na grafické karty (Tesla?, ...) a tak význam spracovania na procesoroch klesá. Samozrejme v midrange oblasti to bude skôr na tých procesoroch, ale kto bude potrebovať viacej výkonu, proste kúpi viacej viacjadrových Buldozerov a bude to lacnejšie. V spotrebiteľskej oblasti to bude nesporne výhoda, pretože asi máloktorá aplikácia bude optimalizovaná na masívne využitie 256 bit výpočtov a ušetrené jednotky znížia cenu procesora, prípadne ušetrený kremík sa využije na iné navýšenie výkonu.
Přesně tohle jsem si říkal taky, double precision už zvládne řádově rychleji GPU, tak možná je dnes lpění na rychlosti FPU fakt přežitek.
Spíš jestli by FPU nešlo řešit nějak tak, že i v procesoru nějaké grafické jádro je, které by mohlo tyto výpočty dělat efektivněji/rychleji...
Mě by jenom zajímalo kdy se bude dát dostat v APU ke "grafickým" jednotkám přímo skrze instrukce assembleru. Tj. kdy bude integrace úplná.
Mě by se docela líbilo řešení, které si historicky (16-17 let zpět) pamatuju ještě z A1200, kde bylo časem v oblibě dokupovat lepší procesorovou kartu... A v lepším případě i s koprocesory... Takže když měl někdo jen standardní 68020 CPU a přikoupil 68881 nebo 68882 FPU, tak si pak člověk jen přihrál do systému MATH.lib právě pro daný koprocesor co měl... A najednou i staré aplikace, kde vůbec člověk nepředpokládal využití koprocesoru, často sakra zrychlily... Stačilo že používaly systémové knihovny...
No a podobný princip by šel určitě použít i po těch dlouhých letech s APU, kdy si dá třeba AMD tu práci a napíše vlastní knihovnu, která zajistí přesměrování některých početních operací na integrované "GPU".
Nevyznám se ale v současných widlích, jestli to takhle mají... Každopádně druhá možnost je možná prostřednictvím vylepšených kompilátorů, které tohle budou řešit...
Třetí řešení je dělení na HW úrovni přímo v APU, to by bylo sakra dobré řešení... Protože by to bylo použitelné i pro existující kód...
No a čtvrté nejsnazší řešení ke kterému to dle všeho spěje... Je podpora prostřednictvím DirectCompute a OpenCL, kdy se prostě některé kritické pasáže zkompilují v tomhle a to už si to rozdělení pohlídá samo... Tohle je do budoucna velmi flexibilní. Zajistí to perfektní přenositelnost a využití i dost šílených kombinací HW... Protože se s tím už v návrhu specifikace počítalo... Tj. může se počítat na různých HW současně a využít tak maximum dostupných zdrojů... A podle mne tahle poslední varianta asi vyhraje... A jsem na ni zvědavý...
Otázka je nakolik je takové počítání efektivní, četl jsem nějaké ohlasy že pod OpenCL je výkon nízký(nebo ne tak dobrý jako v CUDA). Dneska ale už těžko dohledám kde to bylo..
Té efektivity bych se u DirectCompute a OpenCL zas tak nebál, asi budou mít prozatím nějaký skluz oproti CUDA... Ale celkově je to prostě taky velmi efektivní řešení a myslím si že masovým nasazením to AMD má celkem dobře podchycené... Jakmile se budou v desítkách miliónů prodávat APU, tak je to něco, co utluče konkurenci i pantoflama... Na to prostě Nvidia nebude mít srovnatelnou páku... A u AMD je vidět že na penetraci vlastních produktů teď hodně sází... A je to
logicky dobrá volba jak si vydupat silnou pozici...
Navíc lidi jsou celkem líní používat jiné technologie... Budou určitě i nadále rádi používat microsoftí vývojářské nástroje, kde bude k dispozici DirectCompute automaticky... Tak použijí to co tam bude... Proti tomu NV nezmůže zhola nic... Takže její proprietární řešení ztratí ze své současné výhody vlastně všechno... Takže NV bude muset srazit pantofle a taky se držet hlavně OpenCL a DirectCompute... Její vlastní řešení CUDA za pár let bude svět vnímat jako slepou cestu... Já už ji tak vnímám teď, protože v dáli už vidím jen ty haluze, co si tam NV svým přístupem nachystala... Tudy prostě cesta nevede... Jen na úrovni HPC to bude živořit slušně ještě nějaký čas, když si tam NV buduje zázemí...
Vy jste zřejmě pamětník, od příchodu Core 2 (2006) má totiž Intel lepší FPU/SSE než AMD.
Dnešní CPU jsou jeden velký kompromis mezi výkonem, spotřebou, cenou. Flex FPU (a vlastně i Bulldozer modul)je velmi dobrý nápad, jak snížit náklady/spotřebu a zvýšit výkon. Bulldozer modul je o 20% větší než jedno jádro CPU a má o 80% vyšší výkon.
Nárůsty výkonu kolem desítek procent jsou pro výkonnostní počítání nezajímavé, umožňují přidat prakticky 0-1 instrukci do cyklu navíc. Zajímavé jsou až řádové nárůsty výkonu což se dá prakticky dělat jen přidáváním celých výpočetních modulů do jednoho celku. Proto vedou GPU oproti CPU, u GPU je nárůst jednotek v čase daleko větší než u CPU.
"aby se to zrovna hodilo do krámu" - co tímhle myslíš? To říkáš, jako by v AMD ten procesor viděli včera prvně a museli vysvětlit proč je zrovna takový, jaký je. Realita je opačná - oni ho takhle navrhli, protože to z uvedených důvodů považují za výhodné.
Mimo to, FPU Bulldozeru na rozdíl od Sandy Bridge podporuje FMA, takže hrubý FP výkon bude srovnatelný a přesnost Bulldozeru vyšší. Viz představení architektury na techreportu.
stejne jako z "uvedenych duvodu povazuji vyhodne tesselaci jen do 16px/triangle"
na tom, jak se amd ted chova neco dost smrdi. oni proste rikaji: my si myslime, ze je to tak dobre, tak si vsichni sednete na zadek a koukejte se prizpusobit
intel vykonove kompromisy v fpu nedela (a zrejme to nebude mit zadny negativni efekt)
nvidia kompromisy v teselaci ani antialiasingu nedela (bohuzel to ma negativni dopad v podobe vetsi spotreby)
amd dela kompromisy v obojim a pak se snadno stane, ze se nekdo "zabejci" a naprdi jim, jako v pripade ubisoftu
otazka ale je, jestli ma takovou taktiku amd proto, ze si vazne mysli, ze je to tak lepsi nebo proto, ze tim nahrazuji neco, co neumi udelat lepe (lepsi teselator) nebo stejne usporne pri ekvivalentnim vykonu (usporne plnohodnotne fpu pro kazde jadro)
Intel výkonové kompromisy v fpu nedělá a AMD je dělá, protože to podle něj má výhodu - viz. základy architektury bulldozer. AMD je s HD5000 v teselaci horší, ale zatím se to spíš projevuje v teselačních benchmarcích než v reálných hrách. HD6800 se v teselaci zlepšila na novou úroveň a HD6900 mý být ještě lepší. Z H.A.W.X. 2 dema nebo klidně celé jedné hry bych zatím žádné závěry nedělal.
terrorist: to jse směšné tvrzení, nVidia dělala kompromisy s teselací a anti-aliasingem léta... po dlouhých letech vydala jeden čip, který konečně podporuje obojí a ty z toho hned děláš pravdilo...
navíc mi není jasné, jak tohle souvisí s procesorem AMD... navíc mi není jasné, o jakých kompromisech mluvíš - kompromisem je sandy bridge, který FMA nepodporuje vůbec
tonouci se stebla chyta :)
kazdopadne o nepodpore FMA nic nehlasej, kdyz jeste nejsou sandy bridge na stole. navic si nejsem jisty, jestli pro stolni pocitace opravdu vyznam ma, nebo ne. pockej si na ekvivalent sandy bridge v server platforme a uvidis
a co se tyce teselace a aa, pletes si podporu s uzitecnosti. hd5000 mela teselaci jen jako feature, ale byla to fraska. hd6000 ji ma jako vylepseny feature, ale s podminkami pro vyvojare, ktere kdyz nedodrzi ani pres "bububu" od amd, je uplne stejna fraska. a teselace u caymana? dost pochybuju, ze by amd venovala takove usili propagaci 16px/triangle hranici jako dogma, kdyby chtela u caymana mit nejakou vetsi teselacni silu. takze co si tim chtel jako rict? treba ze cayman zvladne optimalne teselaci i pod 16px/triangle? :D
s procesorem amd to souvisi tak, jak jsem popsal nahore. amd si proste nastavi nejakou latku, nizsi nez souperi a pak vsem rekne ze tak je to dobre. ale to je blbost. o tom, co je dobre, rozhoduje zakaznik a ne prodavac (krome nabozenskeho imperia stevea jobse jmenem apple) ...
Kompromisem je nepodpora FMA? To mi nepřijde jako přesné vyjádření. Vzhledem k tomu, že dosud žádný x86 procesor tyto intrukce nezná a neexistuje SW který by je podporoval, těžko může být absence FMA kompromisem. Kompromisem vůči čemu? Nepodpora FMA může být maximálně tak nedostatek pro budoucnost. Může to být nedostatečně rychlé zaváděná nových technologií, ale určitě to není kompromis.
Ovšem to nic nemění na skutečnosti, že FMA je extrémně užitečná instrukce a pokud vím , tak až na x86 CPU ji snad podporuje všechno ostatní. Power procesory už snad několik desítek let a myslím že ji zná snad i Intelácké Itanium. Intel ji podle všeho nepodporuje ze zcela zřejmých důvodů. Vyžaduje to drastické změny v architektuře a Sandy Bridge je "pouze" vylepšené Core 2. Intel chystá FMA do procesorů Haswell, což má být zcela nová architektura plánovaná asi za 2 roky po Sandy Bridge (tedy rok po Ivy Bridge). To že FMA vyžaduje výrazné změny v architektuře je vidět i na tom, že jak AMD, tak Intel ji poprvé implementují až do zcela nových architektur. AMD u Buldozeru, Intel u Haswellu. AMD má ale tu smůlu, že u SW se tahle instrukce začne podporivat až ji budou znát CPU od obou výrobců.
Moc nechápu, že se tu z toho dělá něco nového přitom je to úplně to stejné jako první implementace SSE, které se vykonávaly jako dvě 64bitové instrukce. Jediný rozdíl u bulldozeru je v tom, že dokáže vykonat dvě (tentokrát 128bitové) instrukce za takt. Toto řešení je vhodné pouze do doby, kdy převláda SW využívající SSE. Jakmile se AVX pořádně rozšíří přijdou 256bitové jednotky.
Mezi první implementací SSE a Bulldozerem je vcelku velký rozdíl. Každé jádro v modulu totiž může najednou pracovat s oběma 128bit jednotkama, takže může zpracovat 256bit AVX instrukci v jednom taktu - samozřejmě za předpokladu, že druhé jádro zrovna FPU nevyužívá.
Tohle je skutečně výmysl PR. Protože tímto ztrácí AVX smysl na architektuře Bulldozeru(resp je tam jen pro kompatibilitu, ne pro výkon).
Otázka zní "Kde se použije AVX?". Jak už název napovídá tak hlavně při zpracování videa, nebo obecněji oblasti, kde se využívá všechen dostupný výkon. Přeloženo - když už někdo bude chtít optimalizovat pro AVX, bude současně chtít využívat všechna jádra. Takže si přechodem z SSE na AVX u bulldozeru moc nepomůže.
Takový postup byl použit v případě verzí SSE u nejednoho procesoru. A vždy s další generací, když výrobce doplnil zpracování v jednom taktu, se oslavovalo, jak pěkně narostl výkon.
To cos napsal je podle mě přehnané, ale nebudu se hádat, protože tady bulldozer není, takže ti výkon AVX nemůžu potvrdit ani vyvrátit - podle mě budou AVX u AMD CPU o něco slabší než u Intelu, ale ne o tolik aby tam byly jen kvůli kompatibilitě.
AMD jde dobrou cestou, protože si narozdíl od Intelu uvědomuje, že boj CPU proti GPU je ve floating-point aplikacích sebevraždou. Pokud se AMD víc soustředí na konkurenci ke CUDA od Nvidie než na FP výkon svých CPU, tak je to jednoznačně dobrá volba. Už dnes je v programech pro práci s videem (co umí GPU) vidět ten obrovský nárůst výkonu i se slabou a zastaralou grafickou kartou (např. GTS 250 se 128 cuda core).
neuslo ti tak trochu, ze CELE AVX je o boji cpu proti gpu? vubec bych se nedivil, kdybychom se u ivy bridge dockali jeste vetsiho integrovani intelackych grafickych jader a jejich vyuzivani k avx vypoctum ...
Neušlo. AMD počítá se silnou grafikou v Llanu a dedikovanými grafikami s bulldozerem. Pravděpodobně se i objeví silná IGPu v nějakém chipsetu k bulldozeru. Ivy bridge je daleko, ale z logiky věci vyplývá, že kdo bude chtít větší výkon ve floating point, tak veme dedikovanou grafiku(klidně i budoucí lowend), kterou žádný „obvod" v CPU nikdy nedokáže výkonově nahradit.
Mezi výpočty na CPU a GPU je a ještě dlouho bude dost velký rozdíl, zejména v tom, co je kde možné počítat. CPU má o řád vyšší výkon v jednom vlákně než GPU. GPU má síce o 2 řády vyšší celkový výkon, ale je na něm možné počítat pouze úlohy, které ve všech vláknech výpočtu provádějí přesně ty samé instrukce.
Nejsem na tohle odborník, ale nemyslím si že máš zcela pravdu. Problém s GPU je ten, že onen brutální výkon se dá využít jen u velice mála aplikací. Nejen že je třeba aby SW perfektně podporoval a škáloval s obrovským množstvý vláken, ale ještě navíc nesmí být moc "komplexní". GPU se skvěle hodí na provádění obrovského množství promitivních úloh. Ovšem jakmile se někde nějaký program například větví, vykonává instrukce v divném pořadí,nebo potřebuje "náhodně" šahat do paměti, je GPU v kopru. CPU se svými "podpůrným obvody" jako je OoO (Out of Order) vykonávání instrukcí, odhady větvení, sofistikované koherentní cache tří úrovní, atd, zvládá i podivně složité a nepředvídatelné požadavky komplexního softwaru. Proto třeba i tak jednoduché úlohy jako úprava videa, bežící přes GPU, požaduje na CPU aby data pro GPU napřed předžvejkal. Plno tak zvaných GPGPU aplikací stále dost vytěžuje i CPU.
Mimochodem, když už tu byla řeč o AVX, je zajímavé, e takto supermoderní sada instrukcí se zdá stále dost primitivní oproti instrukcím u chystaného Larrabee. To má být integrováno jako koprocesor u Haswellu (2012/2013) a je dle všeho ještě porkočilejší než AVX. Například má 512 bitové zpracování instrukcí (AVX 256 bitů), podporuje FMA (AVX ne) a má i podporu nějakého gather /scatter. Přiznám se, že vůbce nechápu co to je, ale prej je to důležité a AVX je kvůly nepodpoře téhle featůry občas kritizováno. Snad by mi to mohle někdo chytrý (0xR) laicky vysvětlit.
Scatter & gather je vlastne vektorovy zapis/cteni do/z pameti, kde kazda slozka vektoru muze byt na libovolne adrese. U SSE a AVX musi byt vektor v pameti "v celku", coz neni vzdy moc flexibilni. U GPU maji tyhle instrukce ale vetsi smysl, nez u CPU, protoze CPU ma kratsi vektory a hlavne nahodny pristup do pameti tak rychly a optimalizovany, ze by se oproti postupnemu nacitani moc neziskalo. Ale bylo by samozrejme fajn, kdyby se v CPU nekdy objevily :).
Jinak, AVX a LNI sady se nedaji porovnavat. Jiny ucel, jiny HW, jina filozofie a jina zpetna kompatibilita :).
Ono totiž celé AVX tak trochu postrádá u silnějších procesorů smysl - pokud někdo potřebuje zpracovávat video, tak to řádově (!) rychleji zvládne na grafice a o nějakém AVX se vůbec nebude bavit, naopak obyčejný konzument potřebuje video zejména přehrát a na to mu většinou bohatě stačí běžný procesor. Kdyby se to "montovalo" do něčeho, jako je Atom, který prostě FullHD video nepřehraje, tak prosím, ale co s tím v moderním procesoru?
Přemýšlím na co je vlastně 256bit AVX dobrá, takovou přesnost se dá využít na co ?
256bit AVX znamena pocet bitu registru a z toho vyplyvajici maximalni velikost vektoru
podporovana presnost vypoctu v pohyblive radove carce (FP) je jednoducha (32bit ~ SP) nebo dvojnasobna (64bit ~ DP)
tj. v jednom taktu lze zpracovat 8 SP resp. 4 DP FP vypoctu stejneho typu (SIMD)
To vím... a nebo plnou přesnost 256 bit ne ? A o tom mluvím, k čemu je to dobré...
ne, pokud vim, tak 256bit FP format zatim neni definovan (IEEE 754) a 128bit FP (quadruple) neni soucasnym AVX podporovan
vypocty lze pochopitelne provadet s libovolnou presnosti, ale to pujde o SW reseni
hmm zajímavé a v čem tedy spočívá rozdíl od různých MMX SSEx atd. ?
Třeba v tom, že zvládne je 2x více operací než 128 bit SSE.
AVX rozsiruje vsechny vektorove SSEx FP operace o jejich 256-bitove verze (8 sp nebo 4 dp), zavadi 256-bitove YMM registry, dale pridava ke vsem SSEx operacim (vcetne integerovych) jeden operand navic, aby vysledek nemusel prepisovat prvni zdojovy operand, dale odstranuje vetsinu omezeni pro zarovnani pametovych adres na 16B a nakonec pridava jeste nekolik novych instrukci. Krome toho taky zvysuje efektivitu kodovani instrukci. AVX je tedy v podstate takove SSEx 2.0 :).
Zastarale MMX je pouze integer, 64bit a vyuziva x87 "registry" (tedy spis stack). Prestoze je stale podporovano, nedoporucuje se dale pouzivat.
mozna bys to mel tem nymandum z Intelu a AMD vysvetlit ;)
ted vazne, to ze nekdo pouziva CPU prevazne na zpracovani videa jeste neznamena, ze je to jedinym ucelem moderniho procesoru
AVX prinasi napr. az 1.8x zrychleni v linearni algebre (DGEMM, CFFT, ..)
GPU neni vhodne na kazdy druh vypoctu, u malych problemu vadi rezie (setup, mem copy, ..), u velkych nedostatek pameti a u mnoha (vetsiny) ostatnich prilisna specializace GPU
Mě by se hodil ještě specializovanější čip. Nazval bych ho "bouncer", měl by miliony specializovaných registrů propojených křížově navzájem s vektorovýma čísly a setup subregistry kam by se zadal jednoduchý algoritmus, čip by pak prováděl v každém taktu aktualizace registrů dle vzorců a setupu propojení.
Na halt signál by bouncer přestal počítat a nazrcadlil by registry do RAM kde by si je vyzvedla propojená aplikace.
Čekám kdy se do CPU přidá nějaké to velké hradlové pole... protože emulovat tuhle strukturu je pomalé i na GPU.
Takovému chipu se říká FPGA a Intel bude FPGA od Altery dávat k některým Atomům(Stellarton).
Já jsem si jistý, že to lidé v AMD bezpečně vědí. Jak jsem napsal, podobný postup už byl několikrát použit u SSE. Tzn to nemusí být špatné inženýrské rozhodnutí. Jen v tom nehledejte ten přidaný výkon(rozhodně ne plný), kvůli kterému AVX přichází.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.