"A HT implementálása mivel jár? Kicsit hosszabb lesz a futószalag, mert a HT-hoz több belső, fizikai regiszterre van szükség (regiszterfile a regiszterátnevezés miatt), márpedig ha nagyobb a belső regiszterkészlet, akkor annak elérése is növekszik, és ezt kompenzálni kell."

Az ok-okozati összefüggés még sántít kicsit (a többit már fentebb megbeszéltétek): a HT-hez tényleg kétszer akkora register-készletre van szükség, de nem szabad keverni a két szálét, mert pl. egy-egy szál téves becslésénél a másik szálat nem szerencsés visszarendelni az utolsó megfelelő, közös állapotba. Ehelyett célszerűbb két külön registerfile-t fenntartani, saját vezérlőlogikával, ahogy a chip-architect-es die-photo elemzés is mutatja, Northwood és Prescott esetében is. További lépcső(k) a futószalagban valóban kellhet(nek), mert a registerfile-olvasási stádium elég korai lépcsőfok, gyakorlatilag a megduplázott decode-hoz kapcsolható, és később 'sorba' kell rendezni az utasításokat (vagy az RS fogadási szélességét kell duplájára növelni), de a registerfile-hozzáférési idő ebben az esetben nem nő.
(Az ilyen típusú szélesítés a Conroe->Penryn 4->6 MB L2-nél a legszembetűnőbb, 16- után 24-way set-associative lett).

"A méret növelése jelentős terhet ró a chip komplexitására, viszont ha az ütemezés leegyszerűsítése (megkötések bevezetése, kevésbé rugalmas vezérlés) mellett döntenek, akkor az a teljesítmény rovására mehet, mégha ezzel együtt az elérhető órajel nőne is. Szóval ebben a kérdésben csak találgathatunk, én inkább az erőforrások kiszélesítésére tippelnék, az Intel tranzisztorszám büdzséjébe 45 nm-en belefér."

Ez egy SZVSZ egy nagyon jó "tipp", ami ha előbb nem (a Nehalem-nél), utóbb (valamely utódjánál) be fog következni. Egy dolog nagyon szembetűnő az utóbbi pár évben: míg az AMD felépítése teljesen kötött 3 szélességű (mert az utasításdekódolás és -végrehajtás erre van felkészítve; esetleg "nagyobb" áttervezés nélkül legfejlebb 4-re lehetne ezt szélesíteni), addig az Intel jóval szabadabban teszi-veszi és variálja az execution port-jait és azok tevékenységét, ahogy épp a 'szüksége' kívánja (volt a PPro óta 5-4-6 execution port); ehhez a portok közti (horizontális) ütemezés nagy rugalmassága kell. Az Intel legmagasabban talán az utasítások in-flight (VLIW nélküli) portokra leosztásában veri legjobban az AMD-t, jelenleg is, mert úgy tűnik, ez nála közvetlenül a portok előtt, a Reservation Station-ben történik (ami persze még több execution-port, vagy még kifinomultabb ütemezés esetén igényelhet még több lépcsőt), AMD-nél pedig már a dekódoláskor (Pack stages; nem véletlenül kapkod az AMD valami új - Transmeta? - megoldás után).

Ha így direkt rákérdezel az Itaniumra: azt jó lenne tudni, hogy azt Intel hány execution port-ig tud elmenni az utasítások in-flight utasítás-leosztásban, a fordítóprogramok segítsége nélkül.

"A Core-ban a Reservation Station 32 egyszég széles, ráadásul ez kezeli a memóriaeléréseket is, míg a P4-ben külön RS-t rendeltek a memóriaportokhoz."

Ez az információ, hogy az RS kezeli a memóriahozzáféréseket (out-of-order), honnan származik? Mert ez nagyon 'elegáns' lenne, de akkor szakítottak a PPro óta jelen levő Memory (Re-)Order Buffer-rel?

[ Szerkesztve ]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙