Názory k článku Povídky paralelistické: procesory Intel P6

nice1 jen tak dal

Aha. Tak z tohoto důvodu ty procesory tak šíleně topí, jsou pomalé a vůbec stojí za ... Aby mohl být zachován nedomyšlený formát intel instrukcí a zachována zpětná kompatibilita, tak se vymyslí 5x složitější procesor, který dělá 98% času pořád dokola tytéž operace, které by se mohly udělat jednou při kompilaci. Ale to by nesměl být všechen SW skompilován pro jednu nedomrlou architekturu, která se tu drží čistě jen ze setrvačnosti a marketingových důvodů i když už 10 let jsou známi lepší technologie. Ale aspoň je to učebnicový příklad jak paralelizovat velmi obtížný problém. Hlavně ta logika, která zabezpečuje, aby se to navenek neprojevilo je přímo mistrovský kousek inženýrské práce. Takže se stráví miliony člověkohodin vývoje sofistikovaného zabezpečení správné kauzality, než by se vyrobil modernější design instrukční sady. Hlavně, že se díky masovému nasazení vynucenému setrvačností trhu podaří převálcovat cenou každou konkurenci.

Nebylo by mozne v nejakem dalsim clanku zminit prave ty jine a pripadne lepsi reseni nez pouziva Intel? A to i treba takove, ktere jeste (nebo jiz) nevyrabeji.

Spravne, pochopil jsi, jsi neobvykle bystry :).
Ale muzes zkusit pres vikend prepsat vsechen komercni i nekomercni software na tvuj nejoblibenejsi procesor a pak nam dej vedet kterej to je, my uz ho nekde nakoupime ;)

za prve vsetok netreba a za druhe staci len kompilator napisat na danu architekturu a je vymalovane :-)

Vidim ze jsi to moc nepochopil. Myslis si ze Alpha nebo PowerPC to dela jinak ? Pokud si ten clanek doopravdy pozorne prectes a promyslis, musis dojit ke zcela opacnemu zaveru - na instrukcni sade celkova vykonnost/slozitost procesoru zavisi mene nez se zda. Jasne, ponekud rozevlate binarni kody x86 instrukci situaci mirne komplikuji, ale ne tolik aby stalo za to je menit....

"Jasne, ponekud rozevlate binarni kody x86 instrukci situaci mirne komplikuji,..."

Praveze instrukcni sada ia32 je prekvapive relativne usporna vec - obvykle instrukce jsou zapsany kratkymi operacnimi kody, mene obvykle delsimi. Coz zpusobuje lepsi vyuziti pameti kodem (mensi velikost binarek, mensi L1 a L2 i-cache footprint, atd). Vzhledem k tomu, ze dnes uz i tzv. RISC procesory sve instrukce aspon zcasti interpretuji nebo aspon jsou podobne superskalarni a zretezene, je to jen otazka o neco slozitejsiho dekoderu u ia32 oproti RISC (coz se ale vrati v uspornejsim kodu).

Spis nevim, jak jsou na tom napriklad Pentia IV se spekulativnim vykonavanim kodu (coz ma treba R14k a UltraSparc II/III) - kdyz se neumi predpovedet vysledek vetveni, zacne CPU provadet jednu z vetvi (nebo dokonce obe) a pak se jen jedna necha vypropagovat ven.

IA32 ma jine slabiny: jednak maly pocet obecnych registru (tohle x86-64 odstranuje), jednak slabou podporu pro viceprocesorove systemy (prefix lock versus ex-post detekce kolizi), dale treba hardwarove plneny TLB, ktery vynucuje pevny format strankovych tabulek.

-Yenya

Jasne, souhlasim se vsim. Vsak jsem taky napsal "mirne". Prece jenom, asi by se ta sada dala i zorganizovat lepe, je tam spousta vyjimek a prefixu, a registry take chybi.

Mozno by sa zisiel aj porovnavaci clanok ku intelom ... Alpha a PPC mali niektore veci davno, zatial co intel ich este nestihol skopirovat :-) A co si pamatam jeden referat o PPC co som robil, tak tam je paralelizmus ties pekna palka ... dokonca tusim aj lepsie vyrieseny.

Nemusis sa obavat ALPHA aj s celym vyvojovim teamom, uz skoro rok patri Intelu takze onedlho budu Intelacke procesory az napadne podobne Alpham.

Jo a cely Alpha tym pujde do kopru - je to soucasti obchodnich dohod mezi (jeste) Compaq a Intelem... - dokonce je jasny presny harmonogram "utlumu" - pravda, "jeste" asi tak 10 let (je to dlouho?) nebude uplne bez zivota...

Jenomže Alpha se používala, alespoň pokud vím, dost jako emulátor jiných platforem. No, a pak je jednodušší ty latformy používat přímo. Mám pocit, že pro Alphu se nenašlo určení, že to byl možná dobrý procesor, ale to je tak vše.

Já jsem alespoň o Alphě slyšel často jako o emulátoru jiných prostředí. Sem tam něco i nativně, vím, že třeba Windows NT běželo na Alphě nativně. A snad i Linux. Pokud je tomu tak, tak se nedivím, že Alpha jaksi nenašla scou "osobnost" a svůj směr a byla jen v pozadí "jiných šéfů".

Alphy se IMHO pouzivaji ve velmi vykonych serverech, ktery ted vyrabi HP.

Co se OSu tyce krome WinNT a Linuxu je na Alphach hlavne OpenVMS a Tru64 Unix.

http://setiathome.ssl.berkeley.edu/stats/cpus.html

Average CPU time per work unit

Nadavat Intelu za to, ze svou CISC historii taha furt sebou je detinske. Na druhou stranu je fakt, ze kdyby jeho nove procesory neobsahovaly CISC sadu x86 a byly zalozeny ciste na RISC sade - proc neudelat praci jen jednou pri kompilaci? - miniaturnich instrukci (nenazyva se to nahodou op-codes?), pak by dosahly daleko vyssiho vykonu, ale jen obcas a za presne stanovenych podminek.
Jak je z popisu videt, ten fetch/decode je sice narocny, ale Intel ho pomerne dobre zvlada aby nezpomaloval cinnost ostatnich instrukci. Nevyhoda CISC je, ze instrukce mohou byt ruzne dlouhe => uz pri jejich dekodovani musime vedet, kolik dat ve skutecnosti budeme potrebovat... Myslim, ze i RISC maji ruznou delku "instrukcniho slova". Na druhou stranu se ukazalo, ze ani unifikace v podobe VLIW procesoru (very lange instruction word) procesoru neni vyhrou - pro urcite ulohy (coz bezne AZD - automatizovane zpracovani dat neni) je to vhodne, pro vetsinu vsak ne...(aspon z hlediska vykonu) - naopak ve zpracovani dvou a vicerozmernych signalu (obraz, zvuk) ma nas soused Slovensko velmi kvalitni produkt na svetove spicce...
Jako daleko horsi je penalizace v pripade, ze ten OOR (out of order) se rozhodne spatne - CPU totiz nema dostatek systemovych zdroju na to, aby prochazel "dopredu" vsechny cesty, ale dela predikce. Uvadi se, ze nejlepsi aloritmy maji spravnou predikci vetsi nez 90%... jenze to stale mame 10%, ktere nas stoji daleko vice, nez bychom dostali bez predikce (jejiho vypusteni), celkovy vykon je vyssi, stejne jako HT (hyper-threading) enabled za optimalniho stavu lepe vyuzije ty vicenasobne jednotky (ALU, apod.). Bohuzel az se odstrani tyto problemy - jako ze je to mozna v laboratori, ale ne v realu zatim dosazitelne (a nikdo o vysledcich nemluvi), pak bude vykon taky jinde...
Navic, jak uz jsem zminil ty systemove zdroje - autor naprosto opomnel (mam pocit) veci, jako to, ze CPU ma ve skutecnosti daleko vice registru - dokonce dela takove finty, jako dynamicke prejmenovavani registru dle potreby (ma urcity pocet "int", urcity pocet "fpu" apod. registru) ci stinovani...
Dik za clanek, mozna to nekterym objasnilo, ze dneska neni honba za GHz, ale ze cil je trochu jinde. Neda mi to, abych nemel pocit, ze autor prave dokoncil nejaky kurz Advanced CPU architectures a ze sveho nadseni se chtel podelit, coz je dobre, jen by nemel vynechavat podstatne "bloky" (treba praci s registry).
Jinak doporucuji scripta (eng only) prof. Dvoraka z VUT FIT, tusim, ze se jmenuji Advanced processor architectures....
Bude v nejakem pokracovani treba popis vektorovych procesoru apod. - tedy pure-paralel technologii, ktere si vydobyly misto na slunci, byt v dnesnim podani jsou ustrani main stream zajmu?

> naopak ve zpracovani dvou a vicerozmernych
> signalu (obraz, zvuk) ma nas soused
> Slovensko velmi kvalitni produkt na
> svetove spicce...

co to je?

tiez ma to zaujima :-)
co by to asi mohlo byt?

Ono se pořád mluví o RISC, ale mám pocit, že samotné instrukce rychlost nějak moc neovlivňují. Možná dokonce spíš naopak. RISC instrukce jsou delší, protože je jich často potřeba několik na stejnou operaci, to znamená, že více bajtů se protlačuje přes pomalejší pamět do procesoru. Pro stejný výkon je potřeba větší cache v procesoru. Mám pocit, že při dnešní architektuře je RISC možná i pomalejší. Posílat op kódy mi přijde jako nepříliš chytré.

Osobně si myslím, že výkon procesoru o RISC / CISC moc není.

Spíš je to o tom, jak neparalelní proud instrukcí přeměnit v paralelní vykonávání v co nejvíce větvích. Používá se leccos od vykonávání instrukcí mimo pořadí, dynamické přejmenovávání registrů a přepínání mezi vnitřními sadami registrů, párování instrukcí, předpovídání skoků, zároveň při podmíněných skocích se mohou vykonávat obě větve, dokud se nezjistí, jak to dopadne. Tady je ta největší nabušenost každého procesoru. A problém je spíše principiální, než že by toto jiné procesory měli jinak.

Vývoj jde směrem k tomu, že určitou optimalizaci musí provést kompilátory. Intel x86 procesory dokáží vykonávat jakýkoli kód, pokud jim kompilátor nepomůže, tak jen běží pomaleji. Modernější procesory se dokonce bez účasti kompilátorů neobejdou, třeba takové Itanium požaduje od kompilátorů dodání pomocných informací pro optimalizaci. Zase procesory "od Linuse" se neobejdou bez podpory řízení VLIW instrukcí, pokud to správně chápu.

Osobně si myslím, že to půjde postupně jiným směrem, a to tím, že samotné programy nebudou sledem instrukcí, ale paralelizovanými kusy ve strojáku, které budou již kompilátorem připraveny tak, aby je procesor mohl vykonávat paralelně bez jakéhokoli rozhodování a přemýšlení. Alespoň se mi zdá, že tímto směrem to míří.

mozna .. ale sotva udelate na urovni prekladace "predikci vetveni kodu" .. takze to zase tak jednoduche nebude ..

A co třeba psát programy rovnou paralelně?

Predikce větvení kódu je jedna věc, a ta se asi sotva vyřeší lépe (i když mohu se mýlit) na úrovni procesoru, nebo kompilátoru. Ale dokážu si představit, že pojedou instrukce v několika větvích, které se vzájemně neovlivňují. Pak špatná predikce skoku ovlivní jen jednu větev.

Osobně si myslím, že správná cesta je směrem k multiprocesorovým strojům. Třeba i na úrovni, že jeden čip bude už sám o sobě představovat několik procesorů, které si třeba mohou i své jednotky vzájemně půjčovat, jak to dělá například hyperthreading.

Ono zvyšování taktu má své meze, pokud se budou zvyšovat takty jako dosud, tak základní desky budou mít problémy s fázovým posuvem signálů na desce a synchronizací mezi jednotlivými součástmi základní desky. To dožene výrobce nejdříve dávat čipy co nejblíže k procesoru. To ovšem pomůže jen na chvíli a pak bude nutné integrovat do čipu s procesorem i leccos z čipů, které jsou dnes součástí základní desky. To taky pomůže jen na určitý čas a pak se bude muset jít cestou multiprocesorových strojů, aby se zvýšil výkon.

Psat programy paralelne nepomuze, protoze v typickem programu (pochopitelne jsou vyjimky) moc paralelnosti na urovni jazyka neni. Nejvic paralelnosti je v tom kdyz mas na radce komplikovany vyraz - pak lze ruzne casti vyrazu provadet paralelne. A to je vec kompilatoru a taky toho ze musi dostat dost registru aby se mu to do nich veslo.
Pochopitelne, na architekture i386 se tohle dela spatne protoze ma malo registru. To je jeji nejvetsi chyba.

>Jinak doporucuji scripta (eng only) prof. Dvoraka >z VUT FIT, tusim, ze se jmenuji Advanced processor >architectures....
nedavno jsem si objednavala z VUT FIT knizku od pana Dvoraka a pana Drabka s nazvem Architektura procesoru. jedna se o stejnou knizku ? (tato je v cestine a pomerne dobra).

kazdopadne nejlepsi dokumentace je ta primo od vyrobce :-)

Musím říct, že Drábek je možná dobrej hardwarář, ale přednášet neumí vůbec! :)