foofoobar schrieb:
Mit fällt da eigentlich nur noch ASM, Veritas und Nvidia ein. Wobei NV ja von den Kernel-Blobs weg geht.
Kurze Latenzen sind natürlich immer schick, aber bei typischen FPU-Code dürfte wohl der Throughput wichtiger sein.
Nvidia hat Teile ihre Treiber als Quellcode zugängig gemacht. Jedoch waren die Einschätzungen, dass da selbst mit hohem Aufwand die Treiber allenfalls in Jahren in eine Form zu bringen sind, die die Kernelmaintainer annehmen. Der hohe Aufwand ist Imho nicht zu erkennen.
Och es gibt Einige Hersteller wo es nicht all zu rund läuft... Das wäre aber was für das Linuxforum und ein "Blame and Shame" Thread
Was die FPUs angeht, das kommt wirklich auf den Anwendungsfall drauf an. Computeaufgaben ohne bedingte Sprünge profitieren kaum. Anwendungen die z.B. ihre Logik in Javascript abbilden können hier durchaus profitieren. Für JS sind ja alles Floats, jeder bedingte Sprung profitiert da im Zweifelsfall von besseren Latenzen der FPU.
Und dann ist "Compute" auch immer so ein Ding. Sowas schiebt man sinnvollerweise eh zu den dicken Vektoreinheiten. Bei denen würde ich davon ausgehen, dass diese nicht verkürzt werden.
latiose88 schrieb:
AH ok stimmt Intel hat immer mehr Decode schon gehabt als AMD.Ab wann bringen breitere Decode nichts mehr bzw ab wann bringen die was?
Weil je breiter desto aufweniger kann die Anwendung sein.Nur was passiert wenn die Struktur eher einfach gehalten ist oder es eh alles im Decoder schon platz hat.Verpufft dann die Steigerung am Ende dann?
Sinnvoll ist ein Frontend, dass so viele µOps ins Backend schiebt, wie das Backend in den folgenden Stufen verarbeiten kann. Was sich aber nicht vorhersagen lässt. Weder bei RISC ISA' wie ARM noch CISC wie x86.
Für die Energieeffizienz ist es auch sinnvoller nicht jede Operation immer wieder durch die Decoder zu jagen, sondern nach Möglichkeit die bereits übersetzten µOps zu cachen. Mit ausreichender Trefferquote auf diesen Cache, braucht es weniger breite Decoder, da ein Teil bis im besten Fall Alle µOps eh aus dem Cache kommen. Wobei das für RISC wie CISC ISA' gilt.
Darüber hinaus ist es ein kompliziertes Ausbalancieren. Breite Decoder warten auf schlecht/nicht vorhergesagte Sprünge und leere Cache auch nicht schneller als schmale Decoder.
latiose88 schrieb:
Ja du bist verwirrt aber ich starte 2 x zum Ein Videoumwandlungs Programm
Es mangelt an klarer Ausdrucksweise
Wenn zwei Programme laufen, dann ist das ein Problem des Betriebssystems. Da möge der Sheduler vom Betriebssystem bitte entscheiden wann/wo/wie er welches Programm auf welchen logischen Prozessorkern schiebt.
latiose88 schrieb:
Wie verhält sich dabei das Verlinkte mit den Decode
Wenn der Sheduler vom Betriebssystem ein Prozess einem Kern zum Ausführen zuordnet kommt es zu einem sogenanntem Kontextwechsel. Caches und Register die vom vorhergehendem Prozess genutzt wurden, sollten in validiert sein. Der neue Prozess läuft exklusiv für sich auf dem (logischen) Kern. Entsprechende Befehle jedes Prozesses müssen also exklusiv für diesen Prozess durch die Decoderstufen. Es darf da auf KEINEN FALL dazu kommen, dass Instruktionen zwischen Prozessen ausgetauscht werden!
Oder kurz: Für die Decoder ist das total egal. Instruktionen rein, µOps raus und das immer nur exklusiv für einen Prozess.
Danach wird dein Beitrag derart unverständlich, dass eine Antwort nicht möglich ist.
