Hlavní navigace

Vlákno názorů k článku Povídky paralelistické: procesory Intel P6 od PaJaSoft - Nadavat Intelu za to, ze svou CISC historii...

  • Článek je starý, nové názory již nelze přidávat.
  • 31. 7. 2003 11:59

    PaJaSoft (neregistrovaný)

    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?

  • 1. 8. 2003 11:15

    alf1024 (neregistrovaný)

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

    co to je?

  • 3. 8. 2003 18:24

    Miloslav Ponkrác (neregistrovaný)

    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íří.

  • 3. 8. 2003 20:56

    sejda (neregistrovaný)

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

  • 4. 8. 2003 8:37

    Miloslav Ponkrác (neregistrovaný)

    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.

  • 4. 8. 2003 21:40

    hkmaly (neregistrovaný)

    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.

  • 6. 8. 2003 11:07

    Yokotashi (neregistrovaný)

    Spousta veci lze napsat multithreadove ... jen to temer nikdo nedela. Vzdyt i po vykonu lacnici mplayer je napsan jako jedno vlakno a na mem SMP stroji nestiha ...

    IBM dela brouky, ve kterych jsou 4 CPU Power4 ... to vypada jako cesta

  • 17. 8. 2003 23:25

    Ivona Prenosilova (neregistrovaný)

    >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 :-)

  • 4. 1. 2005 2:27

    m1c4a1 (neregistrovaný)

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