Názory k článku
IBM se chystá zbavit divize výroby procesorů

Skutečné důvody Apple se asi nikdy nedozvíme. A zřejmě tam nebyl jen jediný, ale spíše několik drobných, žádný sám o sobě nijak dobrý, ale dohromady už to bylo hodně.

Osobně jsem zaslechl, že jedním z důvodů bylo, že by na nové generaci Power procesorů běžel stávající SW díky nekompatibilitě stejně rychle nebo pomaleji, takže bylo nutné ho část přepsat. A když už se beztak muselo přepisovat, tak dostal šanci Intel, který v té době dokázal i bez úprav spouštět 20 let staré programy bez výkonnostních problémů. Jeden z momentů, kdy se Intelu zpětná kompatibilita vyplatila.

Prosim nemichejte Power a PowerPC. Power se pouziva v mainframech a je binarne kompatibilni az k OS/360 (pres 50 let!).
PowerPC je jina architektura pro "hracky"...

To tedy ne. POWER i PowerPC vychazi z architektury IBM801 (prvni RISC pocitac, nepocitame-li superpocitac CRAY-1).

PowerPC byla vetev Power architektury urcena pro desktopove pocitace, dnesni nejmodernejsi je POWER8, coz je obr -- procesor slozeny ze 6ti nebo 12ti chipu, 5GHz takt, 6 nebo 12 jader (podle verze), 230 GB/s propustnost k DRAM (trvala, spickova je 410 GB/s).

To o cem mluvis je IBM Z10 architektura. IMHO je to anachronismus zbavovat se CPU s moderni ISA ve prospech dinosaura.

> PowerPC byla vetev Power architektury urcena pro desktopove pocitace.

Vzdyt rikam ze jde o neco jineho (binarne nekompatibilniho).

IMHO je ten dinosaur navrzen tak dobre ze zadne zbavovani se nepotrebuje. Nebo jinak -.postav chip se stejnymi parametry (POWER8) na x86/ARM a pak se bavme o moderni architekture. :)

CISC instrukční sada je u současných Intelů vyjma zpětné kompatibility důležitá také kvůli vyšší code density. Pokud máte dvojnásobně velkou binárku (což je případ Alpha AXP vs Intel x64), potřebujete dvojnásobně rychlejší přístup k paměti a dvakrát větší paměť; obojí se pochopitelně týká jen kódu, nikoliv dat. Navíc nejde jen o RAM, ale také o cache.

Zvýšení code density bylo motivací třeba důvodem, proč na ARMu uvedli instrukční sadu Thumb, která vyjma 32-bitových instrukcí zavádí 16-bitové. Svět RISC procesorů zjevně přejímá některé koncepty CISCu. A CISC procesory si zase berou to lepší ze světa RISC, což je vidět na mikrokódu Intel x86/x64.

Od Pentia Pro je Intel x86/x64 v podstatě RISC procesor vykonávající microcode (který se občas liší podle modelu CPU), s dekodérem překládajícím CISC instrukce na RISC microcode. To mi přijde jako jasné převzetí části konceptu RISC, s tím že je zachovaná zpětná kompatibilita a vysoká hustota kódu.

U RISCového ARMu je zase vidět snaha o zvýšení code density, i za cenu toho že instrukce mají různou délku, což je typické pro CISC. SIMD mi také nepřipadá jako koncept ze světa RISC. Mimochodem u ARMu neplatí, že se každá instrukce provede v jednom cyklu. Například VFP instrukce mohou trvat desítky cyklů, což opět není moc RISCové.

Proto jsem psal, že se CISC inspiruje u RISC, a podobně RISC u CISCu.

Ad právě absence mikrokódu dost jasně RISCy definuje - i tady se to stírá. Už můžete najít ARM s microcodem: [nVidia] Tegra K1... our own custom-designed, 64-bit, dual-core “Project Denver” CPU. ... Denver implements an innovative process called Dynamic Code Optimization, which optimizes frequently used software routines at runtime into dense, highly tuned microcode-equivalent routines. ... This effectively doubles the performance of the base-level hardware through the conversion of ARM code to highly optimized microcode routines and increases the execution energy efficiency. Tu konverzi podle všeho zajišťuje firmware v ROM procesoru.
http://blogs.nvidia.com/blog/2014/08/11/tegra-k1-denver-64-bit-for-android/

Ad u ARMu je to něco jiného... dekodér... nemusí se řešit problémy... [s] dobíhajícími instrukcemi v pipeline - dneska už musí. Although an instruction in the NEON instruction queue is completed from the point of view of the ARM pipeline, the NEON unit must still decode and schedule the instruction. The NEON instruction queue is 16 entries deep. There is also an 12-entry NEON data queue that holds entries for Advanced SIMD load instructions. To samozřejmě obnáší synchronizaci, kterou musíte řešit.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Cfacfihf.html

Ad SIMD je na dlouhou debatu u piva - pro mě spíš na debatu nad Red Bullem, ale každému co jeho jest :). Klasický RISC má malý počet jednoduchých instrukcí, které se provádějí v jednom taktu. SIMD mi k tomu moc nesedí.

Zrovna ten K1 Dever mi neprijde prilis jako CISC. Spis je to RISC nebo VLIW, ktery interpretuje ARM instrukce. Jednak primo tak ze je hardwarove prevadi do svych, nebo kdyz objevi cyklus tak pomoci JIT kompilatoru.

Neco jako byla Transmeta ale myslim ze ta v sobe nemela primou moznost interpretovat x86 kod, coz se nedivim protoze to je pekelne slozite.

Naprotitomu ARM instrukce celkem jdou, mozna to ani nebude umet vsechny, stacilo by jen ty ktere se pouzivaji casto, treba non-Thumb a ostatni mohou jit pres JIT.

Takze to o cem oni mluvi jako o mikrokodu je vlastne nativni strojak toho procesoru.

Slovo mikrokod je bohuzel trochu pretizeno. Puvodne to znamenalo tabulku (v ROM) ve ktere byla ulozena prechodova a vystupni funkce konecneho automatu.

Pak s nastupem mikroprocesoru to vicemene splynulo s implementaci jednotlivych instrukci pomoci nekolika kroku v teto tabulce kterym se rikalo mikroinstrukce -- obvykle primo (nebo pres jednoduchy dekoder) tahaly za draty ridici sbernice cimz pripojovaly registry k vnirni sbernici, zapinaly ALU, zapisovaly data na vnejsi sbernici CPU, atd. Jelikoz se instrukce neprekryvaly behem provadeni v case, tak se dalo rict ze instrukce sestava z nekolika mikroinstrukci.

Alternativou k tomuto byl obvodovy radic, ktery delal v podstate totez, jen nebyl implementovan pomoci tabulky v ROM ale slozen primo z NANDu tak aby se choval jako takovato tabulka (pro slozitejsi funkce velmi pracny navrh, jakakoliv zmena znamena cele to predelat, ale jednodussi funkce muzou ve vysledku pouzivat mensi plochu chipu).

Pak vzniklo IBM801 (a pred nim CRAY), ktere zavedly instrukcni sadu tak jednoduchou ze (1) se instrukce mohly v mnoha pripadech casove prekryvat (2) byly tak jednoduche ze na jejich rizeni stacil obvodovy radic. Tomu se zacalo rikat RISC.

Pochopitelne, misto obvodoveho radice by se klidne mohl dat mikroprogramovy, jen uz jeho mikroinstrukce by neodpovidaly instrukcim procesoru protoze v kazdem okamziku je jich rozpracovano nekolik kdezto mikroinstrukce, ktera celou tu vyrobni linku na zpracovani instrukci ridi, se provadi v jednom okamziku prave jedna.

To co pan Tisnovsky mysli mikrokodem, je IMHO tento puvodni vyznam. Tedy zhruba to co bylo v i386. Pak ale prisla i486 a ta mela nejcastejsi instrukce pipelinovane taky, i kdyz nebyly RISC a ty mene caste provadela po staru pomoci mikroprogramoveho radice -- takze mela mikrokod v puvodnim smyslu jen na nektere instrukce. Mozna tam byl jeste jiny mikrokod ktery cely ten procesor ridil, mozna to bylo udelano obvodove, ale jak je uvedeno vyse -- tento mikrokod nesouvisi primo s instrukcni sadou CPU.

Pak prisel NexGEN, ktery mel uvnir risc procesor s instrukcni sadou nazvanou RISC86 a puvodni x86 instrukce do ni prekladal. Treba add [ebx], 1 se prelozilo na 3 operace load add a store. RISC86 byl superskalarni, tedy schopen dokoncit vice RISC86 operaci za takt, takze i toto drobeni instrukci na mensi kousky nemuselo znamenat zpomaleni. Slozitejsi CISC instrukce tzv. `vector path' (nesouvisi se SIMD, jen shoda jmen) se provadely jako `podprogramy' RISC86 instrukci. Ty byly ulozeny nekde na procesoru a tomu by se dalo tez rikat mikrokod.

Zajimave je ze Pentium-1 tuto techniku nepouzivalo a delalo to primo jako 486, jen to melo 2 pipeliny.

Pak AMD koupilo NexGEN a prakticky do ted to funguje takhle (s vylepsenimi samozrejme). Zaroven Intel zavedl ty sve mikrooperace coz je podobna myslenka jako RISC86. Jen to svadi k tomu zacit primo temto instrukci rikat mikrokod, zvlaste kdyz vector-path instrukce jsou pomoci nich naprogramovany takze zastavaji stejnou funkci jako mikrokod v 486.

Ale je to trochu neco jineho nez mikrokod ktery primo ridil HW, kdyz se jeste tolik nepouzival pipelining.

A to jsem pro jednoduchost radsi pomlcel o prejmenovavani registru a spekulativnim vykonavani instrukci (coz muze delat jak RISC tak CISC, ale myslim ze zrovna tohle bylo driv na CISC pocitacich -- scoreboarding algoritmus je tusim nekdy ze 70tych let, mozna dokonce i 60tych).

Tak jsem to odhadl dobre:

http://en.wikipedia.org/wiki/Project_Denver

According to Tom's Hardware, there are engineers from Intel, AMD, HP, Sun and Transmeta on the Denver team, and they have extensive experience in designing superscalar CPUs with out-of-order execution, very long instruction words (VLIW) and simultaneous multithreading (SMT).[14]

According to Charlie Demerjian, the Project Denver CPU may internally translate the ARM instructions to an internal instruction set, using firmware in the CPU.[15] Also according to Demerjian, Project Denver was originally intended to support both ARM and x86 code using code morphing technology from Transmeta, but was changed to the ARMv8-A 64-bit instruction set because Nvidia could not obtain a license to Intel's patents.[15]

Ano, s Transmeta jste to odhadnul zcela správně.

Pokud CPU interně převádí kód na jiné instrukce, tak bych označil ten interní kód procesoru jako microcode. A to bez ohledu na to jestli jde o jednoduchou tabulku, nebo poměrně komplexní kus SW. BTW micro-ops jsou základem microcode, nesnažil bych se tyhle dva koncepty oddělit.

V případě Intelu je ten microcode prakticky RICSový, v případě K1 Denver VLIW (přičemž VLIW je, silně zjednodušeně, evolucí RICSu s poněkud odlišným plánováním).

Na příkladu x86/x64 a K1 Dever je vidět, že se CISC a RISC velmi sblížily. x86/x64 překládá instrukce do microcode (některé na jednu micro-ops, některé na více), a podobně překládá instrukce do microcode i K1 Dever. U ARMu potom vidíme snahu o zvýšení code density, instrukce různé délky a instrukce trvající déle než jeden takt. Dělení na RISC a CISC je čím dál víc spíš odkaz na historii prapůvodního návrhu architektury, než popis současného stavu.

"Moderní CISC" podle mě má pořád co říct, protože při překladu instrukcí na microcode jde prakticky o RISC procesor s kompresí kódu za účelem zvýšení code density a efektivní kapacity cache memory. Navíc pokud bych měl něco psát v ASM (což je dneska pravda dost vzácné), tak za mě s dovolením daleko radši CISC než RISC.

Ja bych tomu mikrokod nerikal, vede to k nedorozumeni a podobnym zbytecnym diskusim. Kdyztak uz tomu rikejme mikrooperace jako to dela Intel.

Nesnazit se v principu ruzne koncepty oddelit je vyhodne pokud chcete vest flame war pro zabavu, ale jestli se chcete dobrat nejakeho vysledku tak je vzdy lepsi pojmy zpresnovat.

I tak je vlastne nejasne jestli Denver ma nebo nema takove mikrooperace, protoze -- co kdyby code morphing software nebyl v ROMce primo na chipu ale byl v RAM, coz je z hlediska CPU nepatrny zasah --- pak by to byl VLIW procesor, ktery zrovna JIT interpretuje ARM kod. Stejne tak by mohl vykonavat x86 kode nebo Java bytecode.

Tyhle diskuse je maji podobny smysl jako hadat se jestli Motorola 68000 byla 16tibitova nebo 32 bitova.

A nevim co porad mate s tou code-density -- ARM ji ma srovnatelnou s Intelem (v Thumb2 modu dokonce lepsi), lisi se to o par desitek procent, ktere CISC procesor ztrati tim ze instrukcni cache musi mit pridavne bity do kterych se pri preddekodovani predpocitavaji hranice mezi instrukcemi. S temito bity navic to pak vyjde temer nastejno.

Ja zase radsi RISC --- mnohem lip se pro to pisou kompilatory a vetsinou vyuzijete skoro vsechny vlastnosti CPU, takze nedochazi k plytvani tranzisotru na funkce ktere se skoro nikdy nepouziji. A psal jsem v ASM na x86, Cell (ktery je RISC i kdyz jeho jadra jsou vyrazne SIMD) i ARM a prijde mi ze nejtezsi to bylo na x86 -- velmi mnoho instrukci ktere se daji pro dannou operaci zvolit ruzne implementace CPU maji dost ruzne casovani, samotne zakodovani instrukce (jeho delka) zavisi na mnoha detailech. Ano muzete se rozhodnout to neresit a napsat to nejak, ale to uz pak rovnou muzete psat v Ccku a vyjde to lip. Nejjednodusi je IMHO psat pro ARM, rekl bych ze jeste snazsi nez psat pro 68000.

A souhlasim s vama ze to deleni na RISC a CISC patri spis historii.

SIMD je RISC (Really Invented by Seymore Cray). Sice CRAY-1 nemel vice scitacek a nasobicek ale byly pipelinovane, takze za kazdy takt se zpracoval jeden prvek vektoru a kdyz za sebou nasledovaly instrukce treba load v1; load v2; add v0, v1, v2; mul v0, v0, v1; store v0 tak po nacteni v1 se mohlo po prvcich zacit nacitat v2 a jakmile byl 1. prvek v registru, uz se mohl secist a protoze byla volna nasobicka tak i vynasobit a vysledek ulozit pomoci store (nejsem si ted ovsem jisty jake bylo omezeni na pocet takto zretezenych operaci, mozna to umelo retezit jen 2 nebo 3 operace za sebou).

Jestli treba namitnete ze to je vektorovy procesor a ze SIMD *musi* byt paralelni, tak bych podotknul ze treba Athlon XP ma vnitrne jen 64 bitovou ALU pro SSE instrukce. Ovsem registry jsou 128 bitove, takze on sice paralelne rekneme vynasobi 2 32bitove FP cisla, ale pak potrebuje dalsi takt aby zpracoval druhou pulku toho registru.

Ted me napada ze bych mohl zkusit zmerit jestli take dovede zretezit MUL a ADD podobne jako CRAY.

Jinak mam takovy pocit ze SIMD jednotky vznikly driv na RISC procesorech -- urcite ji ma ten MIPS co je v SGI O2. A skutecne mi prijdou vic RISC nez CISC (treba absence flagu je dobry priklad).

Ja myslim ze code density se precenuje. Treba u ARMu je rozdil oproti Thumbu a native modu asi 30 az 40%, coz asi ma vyznam pro pouziti v mikrokontrolerech kde je malo pameti, ale na cemkoliv vetsim je to jedno. Na mikrokontrolerech navic casto FLASH bezi na polovicni rychlosti nez SRAM, takze se vyplati kdyz je v ni kod, protoze pritomny HW pomalu precte 32 bitu naraz a pak je rychle streamuje po 16bitech jako Thumb instrukce do procesoru. Takze dokud neprijde instrukce skoku tak to vypada jakoby FLASH byla rychla.

Na `velkych' pocitacich ale dnes jiz code density nema prilis vliv. Kdyz chcete napsat kod ktery pobezi rychle tak (i na Intelu) stejne musite pouzit loop unrolling + software pipelining, ktery vam dotycne misto zvetsi klidne 2* az 5*. Nejakych 40% rozdilu te ktere instrukcni sady se v tom ztrati.

Ne vse v programu je sice takovyto hot-spot, ale pro celkovou vykonnost zalezi prave na nich (zda se cele vejdou do cache, apod.).

To by urcite bylo zajimave zjistit. Ja mel na mysli spis normalni ko.mp.ilatory. Tam by slo urcite udelat aby kompilator omezil un.rol.ling pokud by hrozilo, ze se blizi k velikosti I-cache. Jenze by to trochu komplikovalo cr.oss.-.com.piling.

V pripade J.I.T. kompileru je situace o to lepsi ze by mohl kod merit za behu -- x86 ma vselijake per.for.mance countery (sice myslim ze je muze pouzivat jen root a nejsem si jist jestli ma kazdy proces sve lokalni (tj. jestli se prepnou pri zmene procesu)). Tyhle citace umoznuji treba zjistit ca.ch.e-miss rate, bubliny v pi.p.eline apod. Ale myslim ze to neni moc stand.ard.izovane a A.M.D. to ma jinak.

Nicmene teoreticky by se mohl J.I.T. za behu naucit parametry ktere ovlivnuji vyrobu kodu tak aby to bezelo co nejrychleji.

Ovsem na druhou stranu J.I.T. by nemel sezrat veskery vykon CPU na sve filos.ofovani o tom jak neco prelozit --- uz ted se pokud vim dela `osiz.ena' alokace registru aby barveni toho gr.afu netrvalo prilis dlouho. Takze se nekdy stane ze JIT pouzije vic registru nez by pouzil norm.alni kompilator a musi proto generovat spi.ll-.ou.t code.

So.rr.y za tecky -- nepochopil jsem (a nechci to vedet) ktere ze slov ktere jsem pouzil je zrovna dnes tabu.

Jenze ty rikas ze POWER8 ma architekturu Z10 a to neni pravda. POWER8 je Power architektura, tedy neco jako PowerPC -- na urovni OS to nejspis binarne kompatibilni nebude, taky to ma nove vektorove instrukce, ale odhaduju ze userland binarka prelozena pro PowerPC na POWER8 pobezi.

Z10 je jina architektura ktera vychazi z IBM-360.

Mimochodem -- je to smutne -- ale posledni doubou jde spis o hrubou silu nez eleganci architektury. S tim jak pribyva transistoru na chipu tak vyhoda RISC pristupu, tedy ze dekoder instrukci zabere mensi plochu cipu, prestava byt dulezita. V dobach kdy zabral 1/3 CPU to bylo znat, dnes uz je to temer jedno (s vyjimkou spotreby -- jeden z duvodu proc ARM tak malo zere -- dekoder instrukci musi totiz porad bezet, nelze ho odpojit od hodin jako se to dela s jednotkama ktere zrovna nemaji co na praci).

Treba porovnani Intel i7 Haswell s POWER7 vychazi pomerne vyrovnane

http://en.wikipedia.org/wiki/POWER7

Notice that the POWER7 chip significantly outperformed (2x-5x) the i7 in some benchmarks (bwaves, cactusADM, lbm) while also being significantly slower (2x-3x) in most others.

Pro POWER8 jsem srovnani nenasel, jen tvrzeni, ze je 2* az 3* rychlejsi nez POWER7. Vzhledem k tomu ze POWER8 je nejmene 6 chipu a Intel jen jeden, tak, ac nerad, musim uznat ze Intel uz nejspis vyhral (i po technologicke strance, obchodne uz davno).

IBM zjevně sází na data analysis software and skills, cloud computing and Watson artificial intelligence technology. Zatím se jim to finančně moc nevrací, uvidíme jak to bude vypadat do budoucna.

Je znama vec, ze cim dal je RD od vyroby tim dele trva opravovat chyby a vyvoj i vyroba je mene pruzna. Pri takoveto vzdalenosti se skoro muze stat ze se z RD stane banda akademiku zcela odstrizena od skutecneho sveta. Takze hrozi ze vymysli uzasne veci ktere firme ale neprinesou zisk.