• BiroAndras
    #462
    "Az in-order működési mód nem szinonímája a gyenge teljesítménynek!"

    Nem is mondtam ilyet. Megfelelően optimalizált kóddal valamennyire ellensúlyozni lehet, de nem teljesen.
    Ami nagyobb gáz, hogy debug kódnál nincs optimalizáció, így az lassabb lesz, és nehezíti a hibakeresést.

    "Az out-of-order rendszer működéséből adódóan sokkal kifinomultabb és összetettebb branch predictiont igényel. Az in-order meg nem."

    Ebben nem vagyok olyan biztos. A branch prediction inkább a hosszú futószalag, és a memória késleltetés ellensúlyozására való.

    "Ugyancsak több pipeline lépcsőfokot igényel az out-of-order rendszer, hiszen végrehajtás előtt át kell rendezni a sorrendet. Ezzel szemben az in-order rendszerhez rövid pileline kell."

    A magas órajelhez is hoszabb futószalag kell, márpedig a cell magas órajelen fog futni. Konkrétumot nem találtam, de az olvasottak alapján én viszonylag hosszúra tippelnék.

    "Az out-of-order rendszer és a hozzá tartozó bonyolult branch prediction (és a hosszabb pipeline egyéb elemei) sok tranzisztort igényel. Így nem csoda, hogy egy in-order rendszerű mag sokkal kisebb lehet."

    Természetesen. Pont az volt a cell-ben az ötlet, hogy az adott mennyiségű tranzisztorből bonyolult logika és nagy cache helyett sok egyszerű magot csináltak. Kétségtelen előnyei vannak ennek a megoldásnak, és valószínűleg ez a filozófia a jövő, de vannak hátrányai, és a cell még elég kezdetleges megvalósítás. ráadásul teljesen új programozási stílus kell hozzá, a mi jelenleg szintén hátrány.

    "A Pentium(1) is in-order volt, és az Itanium is az."

    Az Itanium nem is lett sikeres. Egyébként az Itanium egy órajel alatt 6 utasítást hajt végre, a cell PPE-je csak kettőt (szálanként 1-et).

    "Tehát, attól, hogy a PPE egy kicsi in-order mag, még lehet nagy teljesítményű, főleg hogy 3.2GHz-en megy."

    Névleges teljesítményben lehet jó, de a kihasználása nehezebb.

    "Adódik a kérdés, miért álltak át x86-on out-of-order rendszerre?"

    Mert rengeteg tranzisztorjuk volt, amivel kvázi nem tudtak mit kezdeni. A megoldás az volt, hogy realtime kód optimalizálást, és automatikus párhuzamosítást építettek a procikba.

    "Nehezebb igazán optimális kódot generáló compilert készíteni hozzá."

    Pont hogy könnyebb, mert sokmindent megcsinál a proci.

    "Minden proci-típushoz/-generációhoz külön meg kell írni az ide vonatkozó részt."

    Pont hogy nem. Éppen ellenkezőleg, jobban tűtik a compilerek bénázását.

    "Akkor bemutatom neked Mike Actont, aki a High Moon Studios egyik vezető programozója, akinek egy kissé más a véleménye"

    Elolvastam. Gyakorlatilag ugyanazt mondja mint én, minden szempontból.