Kaveri - der Trinity Nachfolger
- Ersteller FredD
- Erstellt am
@Lynxeye: Programm(-ier)-technisch sind Immediates numerische Konstanten, die in voller Pracht und Schönheit (sprich: Länge) im Instruction-Opcode auftauchen. Ob sie einen Berechnungswert oder sonstwas darstellen (Shift-Konstanten, Shuffle, bedingte Anweisungen usw.) spielt keine Rolle; sie knappsen von den 15 erlaubten Bytes etwas weg.
@Allgemein: Außerdem habe ich den Eindruck, das geglaubt wird, in einem 64-Bit-Programm werden Adressen im Opcode auch als 64-Bit-Wert angegeben. Dem ist nicht so! Auch ein 64-Bit-Programm benutzt zur Adressierung nur 4 Bytes. Es wird relativ adressiert (im Gegensatz zu einem 32-Bit-Prog, das direkt adressiert). Alles "Folgen" der 15-Byte-Grenze
!
@Allgemein: Außerdem habe ich den Eindruck, das geglaubt wird, in einem 64-Bit-Programm werden Adressen im Opcode auch als 64-Bit-Wert angegeben. Dem ist nicht so! Auch ein 64-Bit-Programm benutzt zur Adressierung nur 4 Bytes. Es wird relativ adressiert (im Gegensatz zu einem 32-Bit-Prog, das direkt adressiert). Alles "Folgen" der 15-Byte-Grenze
!
Markus Everson
Grand Admiral Special
...oder AMD64. Letzteres hat im gegensatz zu 3DNow! ein neues Feld besetzt statt nur eine Alternative zu bieten.
Falls Intel ebenfalls in Richtung APU entwickelt (in meinen Augen ja) wäre es für AMD ein gewaltiger Vorteil wenn das Instructionset dazu von AMD kommt und bereits fest verankert ist wenn Intel dazu kommt..
Bei AMD64 hat das aber auch nur funktioniert weil Intel gepennt hat und 64Bit auf x86 nicht ernst nahm sondern lieber die itanic gepflegt hat.
Ebenso war 64Bit auf x86 zu dieser Zeit mehr als nur ein "nice to have" sondern schon aufgrund der Speichergrößen etc. sehr sinnvoll und auch vom Markt gebraucht. Gerade im Serverbereich ist der Speicherausbau schließlich schon länger an der 32Bit-Grenze angekommen als das auf dem Desktop akut wurde.
Im Klartext, bis 4GB und mehr an Arbeitsspeicher im Desktop aktuell wurden, waren schon so viele Opteronserver im Umlauf und das Ganze im Server und Profibereich so etabliert dass quasi kein Weg daran vorbei führte.
Die Bedingungen heute sind andere... Intel hat Oberwasser, AMD ist nur knapp der Pleite entgangen,
Nvidia hat den Profimarkt bei Grafikkarten schonmal besetzt und wir haben Krieg der Befehlssätze zwischen CUDA und OpenCL, Wobei letzteres sogar Industriestandard ist und auch von Intel unterstützt wird...
Ein Alleingang AMDs hier wäre also wesentlich risikoreicher...
Ebenso war 64Bit auf x86 zu dieser Zeit mehr als nur ein "nice to have" sondern schon aufgrund der Speichergrößen etc. sehr sinnvoll und auch vom Markt gebraucht. Gerade im Serverbereich ist der Speicherausbau schließlich schon länger an der 32Bit-Grenze angekommen als das auf dem Desktop akut wurde.
Im Klartext, bis 4GB und mehr an Arbeitsspeicher im Desktop aktuell wurden, waren schon so viele Opteronserver im Umlauf und das Ganze im Server und Profibereich so etabliert dass quasi kein Weg daran vorbei führte.
Die Bedingungen heute sind andere... Intel hat Oberwasser, AMD ist nur knapp der Pleite entgangen,
Nvidia hat den Profimarkt bei Grafikkarten schonmal besetzt und wir haben Krieg der Befehlssätze zwischen CUDA und OpenCL, Wobei letzteres sogar Industriestandard ist und auch von Intel unterstützt wird...
Ein Alleingang AMDs hier wäre also wesentlich risikoreicher...
gruffi
Grand Admiral Special
Naja, Intel hat 64-bit schon ernst genommen. AMD64 hat im Endeffekt funktioniert, weil Microsoft darauf gesetzt hat. IA-64 war wohl zu teuer. Ohne die Unterstützung von Microsoft wäre AMD64 womöglich so geendet wie 3DNow!.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich lese doch fast täglich mitGetrennte "Front-Ends"
Also doch nicht nur die Decoder, sondern das ganze, riesige Front-End!? - ähm...
Das glaub ich irgendwie nicht.
Ich hatte die C't bis vor Kurzem im Abo, muss also die eine irgendwo rumliegen haben *mal zum nachlesen vormerk*
Bezüglich GPU-Befehlen durch die x86-Decoder... gabs da nicht auch irgendwelche Patente die sich darum drehten Befehle an den Decodern vorbei "direkt" einzufüttern, stichwort "Known Good Code" oder so? - ich dachte mich da an irgendwas passendes zu erinnern... wo ist Dresdenboy wenn man ihn mal braucht
Solche Fragen wie zum (für Steamroller im 28nm-Prozess bei geplanten Die-Größen, Preisen und TDPs) optimalen Front End führen zu einem Optimierungsproblem mit mehreren Zielen. Je nach Priorisierung bei AMD kann leicht etwas anderes herauskommen als wir uns hier überlegen.
Folgende Faktoren spielen da z. B. hinein:
- Durchsatz/Energie
- Die-Fläche
- Aufwand/Nutzen für ein separat power-/clock-gatable Front End
- Aufwand/Nutzen für zwei statt einer Schnittstelle pro Modul
- Vorhandensein von µOp-Buffern
- Aufwand/Nutzen für verbesserten L1 I$
- Aufwand/Nutzen für erhöhte Anzahl Decoder (ein Patent sprach ja auch von 8 ops)
- Komplexität, Testbarkeit
Aber 2 Front Ends, breitere Decoder oder zumindest Decoderbänke mit einem breiteren I$-Zugriff sind schon denkbar, wenn das Back End weiter aufgebohrt werden sollte. Um nicht in Erklärugnsnot zu kommen, erzähle ich hier lieber mal nicht, dass in einem Patent etwas davon stand, mehrere Threads pro Kern zu managen...
Dann würde eine Optimierung der jetzigen 4 Decoder zwar einen jetzigen Flaschenhals erweitern (nicht beseitigen), aber einem wachsenden Back End-Durchsatz nicht mehr gewachsen sein.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ja anders gesagt, wie lange können die max. werden? Hab mich ja eh geirrt, es können nur 4 Bytes / 32bit bei den Speicheradressen werden, Danke @Helle53 für die Korrektur.
Ja eben, und was hätte AMD nun davon wenn sie aber z.B. 1024bit Vektoren im aktuellen GPU-Design verbauen würden? Das wäre wieder nix Halbes und nix Ganzes.
Hmm, was verstehst Du nun unter "auf SMT umstricken"? Eine Verbreiterung auf den doppelten Durchsatz? Dann wärs ok, was Du sagst, aber "SMT" wäre die falsche Bezeichnung dafür, denn SMT ist ist ja kein tiefgreifende Architektureingriff, da bleibt normalerweise alles so, wie es ist.
Uaah, mach mich nicht schwach, hast Du meine Bemerkung hier gesehen:Aber 2 Front Ends, breitere Decoder oder zumindest Decoderbänke mit einem breiteren I$-Zugriff sind schon denkbar, wenn das Back End weiter aufgebohrt werden sollte. Um nicht in Erklärugnsnot zu kommen, erzähle ich hier lieber mal nicht, dass in einem Patent etwas davon stand, mehrere Threads pro Kern zu managen...
Am Ende kommt Steamroller mit 8fach Decoder und SMT. Die aktuelle INT-IPC ist ja schlecht genug, dass da noch ein zweiter Thread Platz hätte. Außerdem hieß es ja für Steamroller "greater parallelism" *grusel*
Bisher war AMD ja der volle SMT-Feind, aber mit den neuen Chefs, wer weiß ...
Auf AMDzone wurde auch schon ein linkid Profile eines ehem. Sun Mitarbeiters gepostet, der SMT Know-How hat und jetzt für AMD arbeitet.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Halb so wild:Uaah, mach mich nicht schwach, hast Du meine Bemerkung hier gesehen:
Am Ende kommt Steamroller mit 8fach Decoder und SMT. Die aktuelle INT-IPC ist ja schlecht genug, dass da noch ein zweiter Thread Platz hätte. Außerdem hieß es ja für Steamroller "greater parallelism" *grusel*
Bisher war AMD ja der volle SMT-Feind, aber mit den neuen Chefs, wer weiß ...
Auf AMDzone wurde auch schon ein linkid Profile eines ehem. Sun Mitarbeiters gepostet, der SMT Know-How hat und jetzt für AMD arbeitet.
http://www.freepatentsonline.com/y2012/0166777.html
Ich habe nur versucht, die AMD-Aktie zu stützen *g*
Es geht da eher um das Thread-Parking, kein SMT. Aber deine Bemerkung habe ich gesehen und auch schon darüber nachgedacht. Denkbar wäre es, aber ich befürchte dann deutliche Flexibilitätseinbußen beim Scheduling.
Greater Parallelism geht vermutlich in die Richtung breiterer SIMD-Einheiten, ggf. breiterem Decoder und vllt. sogar mehr Int-Cluster.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jo, das WÜRDE es bedeuten.
Naja, das ist normal, wenn die IPC dann sinkt, alle Puffer sind dann schließlich nur noch halb so groß, auch die Schedulerplätze.Gut, dann bin ich ja beruhigt
Decoder: ok
SIMD Einheiten: Eher nicht, die bräuchten dann auch ne bessere Cache-Anbindung. Könnte man natürlich auch verbessern aber naja ... so nen tiefen Eingriff erwarte ich eher nicht.
INT-Cluster: Interessante Idee, aber wird dann auch irgendwie zu kompliziert. Das ganze Routing zw dem zusätzlichen Cluster und dem Front-End und der FPU stell ich mir horrormäßig vor. Wenn man das Front-End eh verbreitert, und dann pro INT-Cluster einen Port zur XBAR bräuchte, kann man einfach gleich ein komplettes Modul mehr aufs DIE basteln.
Ich spekuliere eher auf nen größeren Ausbau der AGLUs, damit mehr Arbeit 4fach parallel statt 2fach bearbeitet werden würde. Offene Frage dabei: Geht da noch mehr, als sowieso schon fürs 20h Modell angekündigt ist?
gruffi
Grand Admiral Special
Wer hat das denn behauptet? Die aktuellen GCN Vektor-ALUs sind 512-bit breit. Genauso breit wie Intels MIC Architektur SIMDs.
Dass nicht nur Teile der FPU SMT-like arbeiten (EUs), sondern die gesamte FPU.
Genau genommen ist die reine Integer-IPC sowohl bei Bobcat als auch Bulldozer sogar recht gut. Die Flaschenhälse liegen woanders.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Das war nur theoretisch, was jetzt ist, muss für die nächste oder übernächste Generation nicht gelten. Allerdings frag ich mich, woher Du die 512bit Info hast, ich find nur das hier:
http://www.amd.com/us/Documents/GCN_Architecture_whitepaper.pdf
Wundere mich ehrlich gesagt selbst, hab von den VLIW-GPUs noch irgendwas von 2048bit Vektoren im Hinterkopf und hätte schon auch wenigstens so 512bit erwartet.
Ja das bringt Dich dann aber wie schon besagt nicht weiter.
Wenn Du ein 4-8-4 Setup hast (Fetch-Decode-Dispatch), dann hilft Dir ein 4-8- [4 mitSMT] nicht weiter. 4=4 mit oder ohne SMT. Mit SMT könntest Du höchstens mal Glück haben, wenn der andere Decoder nicht alle 4 Plätze belegt. Aber viel ist das nicht.
Was ist denn bitte eine "reine IPC" ? Kann man die nur mit frisch gewaschenem Programmcode erzielen? Also das klingt mir etwas zu abstrakt. IPC ist immer von irgendeinem Programm abhängig und ich kenn keines, das irgendwie auch nur in die Nähe von nem Sandy käme. Hast Du eines? Das Problem liegt aber sowieso woanders. Für SMT ist erstmal wichtig, dass die Pipes nicht ausgelastet sind. Natürlich passiert das aufgrund irgendwelcher anderer Flaschenhälse, sonst wärs ja logischerweise nicht so schlecht ausgelastet. Die schlechte Auslastung wird dann durch SMT aber verbessert - allerdings eben nicht für eine bessere (single thread) IPC sondern nur für eine bessere TLP. Wenn Du Glück hast helfen die SMT-Verbesserungen auch im single-thread Betrieb, aber z.B. ein 8fach Decoder hülfe für 1 Thread auch nicht mehr als ein 4er.
@VlaDez:
Naja ... theoretisch möglich sicherlich, aber praktisch einsetzbar ... ne. Technisch müsstest Du bei 3 Threads alle Cluster für SMT ausrüsten und dann nach dem Front-End die Ops mal dem Kern mal den anderem Kern geben. Aber wenn man sowieso schon alle Cluster auf SMT umrüsten muss, dann kann man auch gleich das volle Programm mit 4 Threads fahren.
Da ja nun "XADD reg, reg" auf den AGLUs funktionieren soll, sollten doch eigentlich auch normale add Befehle ohne Verschiebung möglich sein, oder? (Und nebenbei auch endlich inc)
Desweiteren sollten dann theoretisch einige logische Operationen auch kein Problem mehr in der Implementierung darstellen. Die Frage die sich mir da stellt ist eher, ob diese häufig genug vorkommen, dass sich bei diesen die Verbreiterung auf 4fach parallel dann auch lohnt.
Laut Software Optimization Guide sind es im Moment ja ohnehin nur call und lea Befehle, die die AGLUs verstehen. Würde mich nicht wundern wenn da auch noch irgendwann push, jmp und dergleichen dazukommen, da diese ja eigentlich auch schon im call mit drin sind.^^
gruffi
Grand Admiral Special
Hmmm, was willst du jetzt mit den Registern? Es ging doch um die Vector-ALUs. Und die findest du auf Seite 7:
Heisst also 16x 32-bit = 512-bit. Das war auch schon auf den GCN Folien im vergangenen Jahr abzulesen.
Bei DP (64-bit) werden dann Rechenwerke zusammengeschaltet, so dass die Datenrate sinkt. Interessant aber:
War mir bisher nicht bekannt, dass DP auch mit der Hälfte der Datenrate von SP arbeiten kann. Ich dachte, Maximum wäre 1/4, so wie es bei den Southern Islands Designs offenbar konfiguriert wurde. Aber das nur am Rande.
Das war auch gar nicht der Ausgangspunkt. Der Ausgangspunkt war:
Vielleicht bist du mit dem VMT FPU Frontend durcheinander gekommen. Der Satz:
war aber als alternative Option dazu gedacht.
Das kann ich dir nicht sagen. Ich kann dir aber sagen, was mit "reiner Integer-IPC" gemeint war. Nämlich der reine Durchsatz der Integer Pipelines, ohne entscheidenden Einfluss von FP oder Sprüngen. Bobcat und Bulldozer verlieren ja gerade bei ersterem einiges an Performance. Bobcat, weil dieser aufgrund des limitierten Energiebudgets nur eine abgespeckte FPU besitzt. Und Bulldozer, weil dessen FPU ohne FMA nur mit halber Kraft läuft.
Theoretisch ja. Praktisch steht davon aber nichts im SOG. Theoretisch wären ADDs und (eingeschränkt) Shifts auch schon beim Bulldozer-Kern möglich. Denn nichts anderes macht ja LEA intern.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Hier kommt es darauf an, was als in die Verarbeitung einfließt und was für Ergebnisse herauskommen. Bei ADD wird z.B. das Carry-Flag gesetzt, welches von den AGLUs nicht geschrieben werden kann. Auch könnten AGLU-Befehle weniger interne Inputs benötigen (hab ich nicht geprüft) und nicht nach dem Muster µop src1, src2, dst arbeiten (bis auf inherente Inputs wie z.B. die im LEA-Opcode codierten Shiftbits). Bei EX-Befehlen ist es µop in_flags, src1, src2, dst, out_flags.
Push, Jmp sprechen andere Einheiten (SSO, BU) an, welche gar nicht oder einfach nach Gegebenheiten an die Ports angebunden sind.
Auch. Aber die Threads zu handhaben benötigt zusätzliche Signale und Logik und damit auch Zeit innerhalb der Taktzyklen.
Die bessere Cache-Anbindung wird wahrscheinlich notwendig, schon weil andere Verbesserungen wieder ein Balancing am Datenstrom erfordern.
Ja, es ist gut möglich, dass die INT-Einheiten unter sich flexibler werden.
Für Multiplikationen oder MADs braucht man praktisch 4 32b-Multiplier-Pfade (bzw. ~27b Mantissen für 54b) um die parallelen Additionen abzubilden. Daher 1/4 Durchsatz. Bei DP Additionen kann man aber mit 2 der 32b-Adder-Pfade auskommen.
Die Frage die wir uns doch eigentlich stellen müssen ist "wo genau liegen die Flaschenhälse".
Schon bei bekanntwerden der 2-issue Architektur haben wir über den ILP diskutiert und darüber dass gut ausgelastetes 2-issue womöglich besser ist als 3-issue (oder noch breiter) mit schlechter Auslastung.
SMT auf den INT-Kernen macht IMHO wenig sinn, weil die mit 2-fach OoO schon schlank genug sind dass sie sich effizient mit 1 Thread füttern lassen müssten, wenn der Rest der Architektur dazu in der Lage wäre.
Da es hier aber schon hapert, haben wir nicht ein problem von zuwenig EUs, sondern von ineffizientem Management. - Ergo hilft hier SMT ersmal garnichts, solange nicht die anderen Flaschenhälse beseitigt werden. Intel baut seit X Generationen 3-Issue Kerne, und da macht SMT unter Umständen durchaus Sinn. Wenn ich mich recht erinnere, gab es aber auch keinen einzigen Intel SMT-Kern ohne µOp-Buffer oder ähnlichem. Im Falle des P4 war das sogar ein Trace Cache.
BD hat aktuell noch nichtmal diesen. Eventuell haben wir hier auch einen interessanten Punkt gefunden.
SB und BD haben beide relativ kleine L1-Caches, im Vergleich zu den K10 beispielsweise.
BD muss sich aber im Falle einer Schleife z.B. die selben Instruktionen wieder und wieder und wieder durch die Dekoder Lutschen. - SB Dekodiert sie einmal, schickt dann die Decoder schlafen und kann inzwischen den L1I wieder mit dem nähsten Instruktionsblock befüllen.
Korrigiert mich wenn ich Unsinn rede.
Dazu kommt noch, dass SB im Falle von 1 Thread den gesamten L1D einem einzelnen Thread zur Verfügung stellen kann, also hier doppelt soviel aufbieten kann wie ein BD - INT-Cluster.
Daher bin ich immernoch auf dem Standpunkt, wir haben keinen Flaschenhals im Backend, sondern vorne! - Da hilft alles SMT nicht viel.
Thread Parking wäre allerdings interessant... Wo auf hutigen Systemen doch zig Hintergrundprozesse laufen und Kontextwechsel an der Tagesordnung sind...
Schon bei bekanntwerden der 2-issue Architektur haben wir über den ILP diskutiert und darüber dass gut ausgelastetes 2-issue womöglich besser ist als 3-issue (oder noch breiter) mit schlechter Auslastung.
SMT auf den INT-Kernen macht IMHO wenig sinn, weil die mit 2-fach OoO schon schlank genug sind dass sie sich effizient mit 1 Thread füttern lassen müssten, wenn der Rest der Architektur dazu in der Lage wäre.
Da es hier aber schon hapert, haben wir nicht ein problem von zuwenig EUs, sondern von ineffizientem Management. - Ergo hilft hier SMT ersmal garnichts, solange nicht die anderen Flaschenhälse beseitigt werden. Intel baut seit X Generationen 3-Issue Kerne, und da macht SMT unter Umständen durchaus Sinn. Wenn ich mich recht erinnere, gab es aber auch keinen einzigen Intel SMT-Kern ohne µOp-Buffer oder ähnlichem. Im Falle des P4 war das sogar ein Trace Cache.
BD hat aktuell noch nichtmal diesen. Eventuell haben wir hier auch einen interessanten Punkt gefunden.
SB und BD haben beide relativ kleine L1-Caches, im Vergleich zu den K10 beispielsweise.
BD muss sich aber im Falle einer Schleife z.B. die selben Instruktionen wieder und wieder und wieder durch die Dekoder Lutschen. - SB Dekodiert sie einmal, schickt dann die Decoder schlafen und kann inzwischen den L1I wieder mit dem nähsten Instruktionsblock befüllen.
Korrigiert mich wenn ich Unsinn rede.
Dazu kommt noch, dass SB im Falle von 1 Thread den gesamten L1D einem einzelnen Thread zur Verfügung stellen kann, also hier doppelt soviel aufbieten kann wie ein BD - INT-Cluster.
Daher bin ich immernoch auf dem Standpunkt, wir haben keinen Flaschenhals im Backend, sondern vorne! - Da hilft alles SMT nicht viel.
Thread Parking wäre allerdings interessant... Wo auf hutigen Systemen doch zig Hintergrundprozesse laufen und Kontextwechsel an der Tagesordnung sind...
gruffi
Grand Admiral Special
Na daran liegt's eher weniger. K8 kann doppelt so viel L1D aufbieten wie SB. Und trotzdem ist letzterer schneller. Ich kann mich dunkel erinnern, dass Andy Glew mal gesagt hatte, dass zwei 16 KiB L1Ds laut Analyse die richtige Dimension für das Bulldozer Konzept wäre. Allerdings hatte der auch immer SpMT im Hinterkopf.
Die FPU ist bei Legacy Code schon ein Flaschenhals, zumindest was den gesamten Durchsatz der CU betrifft. Was natürlich nicht heissen soll, dass es im Frontend keine Flaschenhälse gibt.
Daran alleine wirds sicher nicht liegen, dennoch ist ein BD schon vom Featureset her wesentlich näher am SB als ein K8.
Das mit SpMT ist ein weiterer Punkt, aber weiss irgendwer ob Andy Glews CMT-Design mit oder ohne µOp-Buffer geplant war? - ich stelle mir nämlich grade die Frage wie die Decoder es schaffen sollen noch einen SpMT-Thread mit Befehlen zu versorgen (zusätzlich zum Haupt-Thread) , wenn wir wissen dass sie im 2-Thread-Fall eigentlich unterdimensioniert sind. - da wäre ein Trace-Cache doch erst recht gut, eingedenk der Tatsache dass dann womöglich einige Befehle in beiden Threads auftauchen...
Spekulationen über Spekulationen
Das mit SpMT ist ein weiterer Punkt, aber weiss irgendwer ob Andy Glews CMT-Design mit oder ohne µOp-Buffer geplant war? - ich stelle mir nämlich grade die Frage wie die Decoder es schaffen sollen noch einen SpMT-Thread mit Befehlen zu versorgen (zusätzlich zum Haupt-Thread) , wenn wir wissen dass sie im 2-Thread-Fall eigentlich unterdimensioniert sind. - da wäre ein Trace-Cache doch erst recht gut, eingedenk der Tatsache dass dann womöglich einige Befehle in beiden Threads auftauchen...
Spekulationen über Spekulationen
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
Andy Glew's comp-arch.net wiki könnte da Hinweise geben.
Die Frage ist doch bei welchen Instruktion bringt ein µOp-Buffer einen Vorteil ?
Bringt ein µOp-Buffer nicht bei allen Instruktionen einen Vorteil ?
Nein, denn erstens kostet die Verwaltung des µOp-Buffers ebenfalls Zeit:
a) Das Hinzufügen von Instruktionen zum Buffer kostet Zeit
b) Das Entfernen von Instruktionen aus dem Buffer ( welche? ) kostet Zeit
c) Das Suchen ob eine Instruktion im Buffer vorhanden ist kostet Zeit
und zweitens kann ein solcher Buffer nur bei den Instruktionen einen Vorteil bringen, die einen Dekoder länger wie einen Taktzyklus beschäftigen. Kurzum dies ist nur bei Instruktionen der Fall die im komplexen Decoder landen.
Hier könnte auch das größte Problem beim Decodieren liegen, wenn man nur einen komplexen Decoder für 2 Threads hat. Denn sobald eine zu decodierende Instruktion den komplexen Decoder benötigt steht die weitere Dekodierung von Instruktionen für beide Threads komplett still bis der komplexe Decoder fertig ist.
Bei der Betrachtugn vergisst du aber die Schleifen.
Nicht umsonst hat Intel schon seit mehreren CPU Generationen Loop-Detector, damit eben wiederholte befehle nicht ständig immer neu dekodiert werden müssen.
Nicht umsonst hat Intel schon seit mehreren CPU Generationen Loop-Detector, damit eben wiederholte befehle nicht ständig immer neu dekodiert werden müssen.
Könnte man die Suche nach den Schwachstellen nicht von der anderen Seite versuchen? Also Code ansehen, der besonders armselig auf BD läuft und dann schauen, was genau für Berechungen es sind, die darin vorkommen. Daraus ergibt sich ja dann doch, was fehlt, oder?
Zum Thema ("kurze") Schleifen ein kleines Beispiel: Doch recht oft wird in einem Programm die Länge eines Strings benötigt. Mit SSE4.2 wurden (auch deshalb) einige Instruktionen zur String-Behandlung eingeführt. In Flat-Assembler-Syntax sieht das so aus (für die Ermittlung der String-Länge) :
mov rdx,[StrP] ;Pointer auf Anfang String
mov rax, -16 ;rax=Zähler
pxor xmm0,xmm0 ;xmm0 auf Null setzen
@@:
add rax,16 ;es werden immer 16 Bytes eingelesen
pcmpistri xmm0,dqword[rdx+rax],00001000b ;Zero-Byte (String-Ende) gefunden (Index)?
jnz @b ;wenn nein, nächste 16 Bytes einlesen
add rax,rcx ;rcx=Position Zero-Byte, rax=String-Länge
Also wirklich eine Mini-Schleife, aber eben nötig. Für einen ca.1.4GB langen String ergeben sich folgende Zeitwerte:
Intel i7-3770K : 78ms
AMD FX-8120 : 219 ms
Turbo usw. spielt da keine große Rolle.
mov rdx,[StrP] ;Pointer auf Anfang String
mov rax, -16 ;rax=Zähler
pxor xmm0,xmm0 ;xmm0 auf Null setzen
@@:
add rax,16 ;es werden immer 16 Bytes eingelesen
pcmpistri xmm0,dqword[rdx+rax],00001000b ;Zero-Byte (String-Ende) gefunden (Index)?
jnz @b ;wenn nein, nächste 16 Bytes einlesen
add rax,rcx ;rcx=Position Zero-Byte, rax=String-Länge
Also wirklich eine Mini-Schleife, aber eben nötig. Für einen ca.1.4GB langen String ergeben sich folgende Zeitwerte:
Intel i7-3770K : 78ms
AMD FX-8120 : 219 ms
Turbo usw. spielt da keine große Rolle.
Das ist ein Fall,
dann überelgen wir mal wie oft z.B. Array initialisiert werden müssen usw.
Schleifen sind allgegenwärtig.
Wenn ich darüber nachdenke wie oft ich im Alltag "for" schreiben muss.
Zugegeben, in .Net ist das nicht 1:1 übertragbar und mit for each - Schleifen, also iteratoren etc. wirds ohnehin schnell mehr... das ändert aber nichts daran dass solche kleinen Schleifenkonstrukte zuhauf existieren. Genau genommen ist jeder String ein char-Array irgendwo im Speicher.
Ergo: Die wahrscheinlichkeit ist relativ hoch, dass die Decoder selbst wenn sie die meisten Befehle in 1 Takt dekodieren können, noch eine Entlastung erfahren wenn sie bei Schleifen den selben code nicht wieder und wieder und wieder dekodieren müssen. DRY ist ein fundamentales Prinzip der Informatik. - Nebenbei, wenn der µOp-Cache so ineffizient wäre, wieso schleift Intel dann sogar mehrere davon mit sich herum? (Loop Detector UND µOp-Buffer) - deren Decoder brauchen auch nicht länger für einen Befehl als die von AMD oder?
dann überelgen wir mal wie oft z.B. Array initialisiert werden müssen usw.
Schleifen sind allgegenwärtig.
Wenn ich darüber nachdenke wie oft ich im Alltag "for" schreiben muss.
Zugegeben, in .Net ist das nicht 1:1 übertragbar und mit for each - Schleifen, also iteratoren etc. wirds ohnehin schnell mehr... das ändert aber nichts daran dass solche kleinen Schleifenkonstrukte zuhauf existieren. Genau genommen ist jeder String ein char-Array irgendwo im Speicher.
Ergo: Die wahrscheinlichkeit ist relativ hoch, dass die Decoder selbst wenn sie die meisten Befehle in 1 Takt dekodieren können, noch eine Entlastung erfahren wenn sie bei Schleifen den selben code nicht wieder und wieder und wieder dekodieren müssen. DRY ist ein fundamentales Prinzip der Informatik. - Nebenbei, wenn der µOp-Cache so ineffizient wäre, wieso schleift Intel dann sogar mehrere davon mit sich herum? (Loop Detector UND µOp-Buffer) - deren Decoder brauchen auch nicht länger für einen Befehl als die von AMD oder?
gruffi
Grand Admiral Special
Kannst du mal partielles Loop-Unrolling machen. Also zB 2 Vergleiche in der Schleife durchführen, dafür aber nur halb so viele Durchläufe. Würde mich mal interessieren.
Ich hatte ähnliches schon vor geraumer Zeit mal mit K8 und Core 2 gemacht. Während der K8 gut vom Loop-Unrolling profitiert hat, brachte das beim Core 2 praktisch nichts.
Ich hoffe, du hast den Code auch entsprechend im Speicher ausgerichtet? Gerade bei Schleifen kann das ordentlich Performance kosten, falls nicht. 16- oder 32-byte sind gängige Grössen.
Übrigens, wer nutzt heute noch SZ-Strings? *würg* (ich weiss, C, WinAPI, bla bla bla) SZ-Strings haben schon dem alten Schlemiel ordentlich zu schaffen gemacht.
Zuletzt bearbeitet:
