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.
na fusion sa velmi tesim, myslim ze to bude evolucia
JJ, x86 půjde velmi pomalu do kytek, ale bude to trvat minimálně 10 let, nejspíše více. Nejprve budou procesory kombinované tj. jako fusion x86 část + ne x86 část(SP), přičemž výkon x86 částí se už nějak příliš zvedat nebude, tak jak bude přibývat stále více aplikací využívající SP (jak ta paní mluví o antivirech + dalších výpočtech na GPU dostupných již dnes), logicky se budou přídávat pouze SP. Tento trend vidíme (zatím v malé) míře již dnes. x86 kompatibilní jádro se bude velmi pomalu stávat méně důležitou součástí "procesoru", stále v něm sice bude, postupem času však už jen pro zachování kompatibility a možnosti běhu "starých" aplikací. No a jednoho krásného dne už tato část zmizí úplně. Znovu zdůrazním, že to potrvá ještě dlouho, ale je to nevyhnutelné. Vím, že konec x86 je prorokován již spousty let a většina skeptiků se mu stále vysmívá. Před pár lety bych se ještě vysmíval také. Situace je ale dnes již jiná. Trend konce x86 CPU byl nastolen GPU, na světě je již řada reálných aplikací používající SP, teprve teď je (zdůrazňuji velmi pozvolný)konec x86 reálný.
S GPU Windows nenabootuješ ;)
pak je "starý" :-D
GPU je akcelerátor ne řídící jednotka, můžeš trochu přehodnotit svoje fantazie.. ;-)
jasně, já to chtěl napsat tzv. "populárně" Pojmy GPU a SP myslím non-x86 obecně
Ty fantazie nejsou až tak docela mimo, ale já tady v tomto smyslu chápu budoucí verzi Fusion asi takto:
x86 architektura je totiž momentálně opravdu dobrá tak na to nabootování a základní I/O kolem procesoru. Na ni je již dnes nabalena halda rozšíření, MMX počínaje přes AMD64 a AES-NI konče. Není důvod, aby dalším rozšířením nebylo něco, čemu dnes říkáme "shadery", "stream procesory", "CUDA jádra" a podobně. Prostě to bude další instrukce zpracovávaná na úrovni křemíku něčím, co se dnes hodně podobá GPU. Taková třeba nemusí být přímo druhá verze Fusion, ale třeba třetí, čtvrtá. Ale podle toho, co říkají lidi z AMD, mám pocit, že k nějakému takovému cíli směřují.
To, co dělá GPUčko GPUčkem, se z drtivé části může přesunout do procesoru a samotný proces zobrazování se může de-facto stát pouhým rozhraním či spíše "video kodekem" v tom smyslu, jakým dnes chápeme HD audio či AC97 kodeky. Výsledkem by mohla být integrace podobného broučka za účelem video výstupu přímo na desku, vlastně by to klidně mohlo být přímo v čipsetu a i výkonné grafiky v PCI Express slotech budou pak jen "add-on počítadlem scén", které výsledný obraz pošle na displej zase přes malého broučka na desce nebo čipset. Však se mrkněte na Nvidia Optimus, kde už nyní dělá výkonné GeForcce video řadič grafika Intel HD v procesoru a výstup jde ven přes jižní můstek (trochu nebezpečí vidím v tom, že "patent pending" má tuhle technologii Nvidia ;).
GPU je efektivní díky masivní paralelizaci svých částí, když obohatíš CPU o jeho funkcionalitu tak tím o tuto výhodu přijdeš. Nebo nějak nechápu co vlastně chceš. ;)
Vem to tak, že jednodušší GPU (integrované v čipsetech) v určitých věcech trumfnou procesory. Nevidím důvod tuhle funkcionalitu neintegrovat do procesoru a neeliminovat tak prvek, kterému dnes říkáme integrovaná grafika :-). Výkonné grafiky by pochopitelně zůstaly, ale třeba i na PhysX mnohdy stačí jednoduchá grafika, která by mohla být "zavrtána" do procesoru. Stačí, když v procesoru budou patřičné instrukční sady. Pokud se nepletu, první náznak tohoto směru přijde v podobě vektorových instrukčních sad, u AMD snad v Bulldozeru, u Intelu v Sandy Bridge.
Takovéhle bludy může napsat leda někdo kdo vůbec nerozumí tomu, jak GPU fungují. GPU se hodí pouze pro určité specifiké typy výpočtů, které provádějí spoustu stejných operací nad různými daty. Tzn. je spousta dalších aplikací, na které se GPU(alespoň ty dnešní) vůbec nehodí. Např. nikdo zatím neimplementoval šifrovací nebo kompresní algorimy na GPU, protože by na GPU běžely řádově pomaleji než na CPU. Takže výkonný x86 CPU je a bude stále potřeba.
zajímavé. Jako bys komentoval příspěvek někoho, kdo tvrdí, že GPU nahradí CPU, žádný takový ale tady nevidím. Řeč byla o postupném nahrazování x86 architektury nějakou jinou. Fusion architekturou, která ponese jednotky vhodné pro paralelní výpočty (a jestli je to blábol, tak pak je blábol i celý AMD Fusion, ION platforma pod :-D ) a ponese samozřejmě i další jádro(a) na zpracování výpočtů které se špatně paralelizují. A tady jsi úplně mimo když říkáš, že to musí být x86. Může to být úplně jiná sada, a je to velmi pravděpodobné. x86 je značně omezující už x let, jestli je to blábol, proč teda vzniklo Itanium (asi není nejlepší příklad)a další. Existuje tolik sad, o kterých zřejmě nemáš ani tušení, které jsou oproti x86 vhodnější. x86 je pouze nutné zlo, respektované z důvodu kompatibility a monopolního postavení Microsoftu a jeho neochoty dělat systémy i pro jiné sady. Btw spojovat možnosti efektivního provádění kompresních a šifrovacích algoritmů s nutností x86 instrukční sady je teprve megablud. A na závěr je krásným důkazem tvých bludů o "vhodnosti x86 instrukcí" CPU pro šifrovací algoritmy, ViaPadlock jakožto hardwarová součást x86 CPU VIA, která tyto algoritmy zvládne několikrát rychleji, než kdyby je měla provádět skrze svou x86 část. Nejnovější Intely a obsahují ekvivalent ViaPadlock, což jasně dokazuje, jak je x86 instrukční sada na tyto úlohy nevhodná
Sorry ale ty si pořád pleteš akcelerátory a CPU. Specializovaný akcelerátor bude vždy efektivnější než CPU (a je jedno jestli akceleruje grafiku nebo šifrování).
Ale na druhou stranu nejde udělat akcelerátor na všechno, to by potom jádro mělo metr čtvereční, akcelerátory se dělají jen na to co nejvíc zatěžuje CPU.
PS: V čem konkrétně je instrukční sada x86 tak špatná ? (když už byla rozšířena o MMX, SSE, SSE2, SSE3, SSE3, SSE4...)
instrukcnu sadu som vnimal ako zastaralu ked som sa ucil programovat v asm na x86 a moril som sa so vsetkymi tymi segmentami atd.. a zavidel som modernym cpu ich priamociarost a logickost
x86 ma strasne vela instrukcii (tusim uz je to okolo 1500) ktore casto uz nie je treba a ale je nutne ich stale implementovat kvoli spatnej kompatibilite. Nove instrukcie zaberaju zbytocne vela miesta(potrebuju viac casu na dekodovanie, vacsiu cache...) , musia byt x bytove, pretoze menej pouzivane, zastarale vznikli skor.
Niekde som videl nejake porovnanie ze na tie iste vypocty je pri power architekture nutny jednoduchsi cip a menej energie (o desiatky %).
Je jasne, ze x86 sa drzi na spici len kvoli tazkym peniazom naliatych do tejto architektury. Nie je tak lahko mozne na tomto poli prerazit. Ak niekto pride s cipom o 10-20 % vykonnejsim ako ukazka efektivnosti novej archtektury, Intel dokaze obrovskymi prostriedkami a zvacsenim cipu porazit efektivnejsieho supera.
"V čem konkrétně je instrukční sada x86 tak špatná ?"
V skratke, s touto sadou je mozne urobit vsetko, ale je to ako hovorit "v com je svajciarsky nozik so srobovakom horsi od tohto profi srobovaku ?"
Aha, programování v assembleru, to to nemůžeš říct rovnou? :) Myslím že všech nevýhod zbavuje C++ a vyšší jazyky, tam tě mximálně zajímá nový CPU který tvou úlohu zvládne rychleji.
Akorát inline assembler bude problém, jak se vůbec moderně programuje pomocí MMX a SSEx sad, exituje na to v céčku nějaká automatika nebo ještě pořát se to musí drtit ručně v ASM ?
tak to poviem takto:
ak by som mal limit financny alebo napr na odber E, a zacinam od piky, tak s architekturou ktora nie je x86 verim ze mozem dosiahnut aj o 70% vacsi vykon/nizsiu spotrebu alebo o 10-30% mensiu plochu cipu.
Standardne C samozrejme ziadne SIMD nepozna. Pokial viem riesi sa to stale pomocou ASM alebo intrinsic funkcii. Kazda SIMD instrukcia ma svoju intrinsic funkciu, takze je to skoro ako inline ASM :-) Potom existuju kniznice ktore implementuju "bezne" vektorove funkcie a algoritmy optimalizovane pomocou MMX a SSE (myslim ze Intel aj AMD vydali nejaku takuto kniznicu).
Nejaku "automatiku" by som ale neocakaval. Vzdy musis ty sam povedat kompilatoru co vlastne chces robit. Tak isto ako nemozno ocakavat, ze kompilator zacne automaticky generovat multithreading kod.
Inak co sa tyka kritiky x86 tiez tomu moc nerozumiem. Vela ludi tvrdi ze x86 architektura je zla, pomala, neefektivna. Ale vzdy nejako chybaju dokazy ktore by tieto tvrdenia nejako podlozili.
nejak nechapem vyhody tohto spojenia pre ine riesenie ako mobilne/usporne. Uchladit 2 zrave casti cipu pri sebe musi byt nerocnejsie ako ked su od seba.
jednoduchý příklad: 7 + 25 > 28
Správa Digitimes o výrobe v TSMC asi nebude správna. GlobalFoundries totiž už vyrába Llano 32nm technológiou (SOI, high-k metal gate).
http://www.techeye.net/chips/global-foundries-12-inch-wafers-to-take-on-...
Procesory Fusion primárně nepatří do mobilního segmentu, jen CPU (lépe APU) založené na jádře Bobcat a částečně Llano.
IMHO:
1. Llano vyráběné 32nm SOI v GloFo
2. Ontario (Bobcat) vyráběné 40nm Bulk v TSMC
3. Zambezi, .. (Bulldozer) ???
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.