News Schalter entdeckt: Windows 11 wird für Advanced Performance Extensions gerüstet

[lowrider20]

Auf einem 386er

Du Kasperl! Was Microsoft bei Markteinführung von Windows 11 ausgesperrt hat, ist dir wohl entfallen.

 

[mae]

Oder bis der I-Cache unwirksam wird.

Der wirkt immer, er kann aber eine bessere oder schlechtere Missrate haben. Wie wirkt sich Inlining aus? Wenn es nur einen Aufruf einer Funktion gibt, ist inlining fuer den I-Cache auf jeden Fall hilfreich, weil die cache lines besser ausgenutzt werden, und weil das Inlinen insgesamt zu weniger Code fuehrt. Wenn es mehrere Aufrufe gibt, die alle inlined werden, kann das zu insgesamt groesserem Code fuehren (ausser die Funktion ist so kurz, dass der Aufruf groesser ist als der inlined code), aber der Vorteil der besseren Ausnutzung der cache lines besteht weiter. Und je nachdem, welche Teile des groesseren Codes dann ausgefuehrt werden, kann die cache miss rate durch das inlining trotzdem sinken.

Wir haben bei einem aehnlichen Thema versucht, durch Wiederverwendung von Code-Stuecken die I-Cache miss rate zu reduzieren. Aber im Ergebniss ist sie gestiegen; die Erklaerung dafuer war, dass die schlechtere Ausnutzung der Cache-Lines zu mehr cache misses gefuehrt hat als durch die Wiederverwendung eingespart wurden.

Dass Hotspot damals (als die I-caches noch kleiner waren als jetzt) nach der Aussage des Entwicklers das nicht als Kriterium verwendet hat, deutet darauf hin, dass eine Vermehrung der I-cache misses kein grosses Problem war.

Das wird sich Intel in Zukunft nicht mehr leisten können.

Es war auch in der Vergangenheit ein Schuss in's Knie, aber die Marketing-Abteilung musste ihre Wichtigkeit demonstrieren, indem sie solche Knieschuesse anordnen. Ob sie jetzt damit aufhoeren?

 

[DavidXanatos]

Ach meno.. da sehe ich schon die nächste schrott laviene anrollen, windows 14 wird sicher APX vorraussätzen.

 

[blackiwid]

Also der L3 Cache wandert dann insgesamt in eine neue Ebene, nicht nur der zusätzliche bei den X3D?

Ja hab grad nochmal geschaut was Moore's law an leaks präsentiert hat und hast wohl recht betrifft wohl mehr die x3d, ansonsten kommt man vor allem neben mehr cores (auch pro CCD) und immerhin auch mehr Cache ohne x3d auf nen deutlich überarbeiteten Speicherkontroller, was bisher bei AMD eher ein Flaschenhals war.

"Non monolyptic Zen 6 products werden "bridge dies" nutzen um sie zu higher speed IOD zu verbinden.

Wobei es da um Medusa geht war das nicht nur die Laptop Varianten?

 

[Nagilum99]

Du Kasperl! Was Microsoft bei Markteinführung von Windows 11 ausgesperrt hat, ist dir wohl entfallen.

Natürlich nicht. Aber bis heute kannst du das System ja trotzdem darauf betreiben - es ist nur lästiger geworden. Zwangsläufig müssen aber irgendwann Zöpfe abgeschnitten werden um moderne Systeme effizient zu nutzen und Ballast abwerfen zu können.

Ergänzung (Dienstag um 21:49)

Ein anderer Vorteil von APX ist, dass "A = B-C" nicht mehr wie bei AMD64 normalerweise in zwei Befehle "A = B; A=A-C" aufgeteilt werden muss; letzteres kostet mehr Resourcen im Front End.

Die Erläuterung ergibt viel mehr Sinn als wa Devpandi oben schrieb.

 

[lowrider20]

es ist nur lästiger geworden

Und genau darauf bezieht sich meine Aussage. Es funktioniert OHNE Einschränkungen. Trotzdem wird es einem auf normalen Wege verwehrt. Und das zu Zeiten überhöhter Preise (2021 durch Pandemie, aktuell nicht besser) mit einer Funktion, welche eigentlich nur für Firmen relevant bzw. von Interesse wäre.
Es ist mir schon klar, daß Windows einfach zugemüllt ist, aber das wird MS nicht hinbekommen, daß sie alte Zöpfe abschneiden UND ein stabiles, effizientes sowie schlankes System liefern.

 

[Nagilum99]

Und genau darauf bezieht sich meine Aussage. Es funktioniert OHNE Einschränkungen. Trotzdem wird es einem auf normalen Wege verwehrt. Und das zu Zeiten überhöhter Preise (2021 durch Pandemie, aktuell nicht besser) mit einer Funktion, welche eigentlich nur für Firmen relevant bzw. von Interesse wäre.

Faktisch ist's ja ganz einfach: Sie haben das sicher schon sehr lange geplant und das konsequent umgesetzt.
Es wurde auch immer mitgeteilt, dass es sein kann, dass alte Systeme mit einem der kommenden Updates nicht mehr laufen werden. Sie halten sich frei zu welchem Zeitpunkt das (vermutlich wirklich) stattfinden wird.

 

[foofoobar]

Die Erläuterung ergibt viel mehr Sinn als wa Devpandi oben schrieb.

Was aber wenig mit der Anzahl der Register zu tun hat.
Das ist dann eine 3-Operanden Maschine, also ein anderes Merkmal.

Ach meno.. da sehe ich schon die nächste schrott laviene anrollen, windows 14 wird sicher APX vorraussätzen.

Dieser Krempel ist ja nur noch für den Desktop relevant.

 

[DevPandi]

Die Erläuterung ergibt viel mehr Sinn als wa Devpandi oben schrieb.

Ah ja, in den ein + durch ein - getauscht wird und der Text: das verhindert, dass eine Kopie von Angelegt werden muss, ist natürlich dann mit einem A = B er gibt dann mehr Sinn.

Einmal die Ausführung in Gelb, einmal in Grün. Aber Grün ergibt mehr Sinn. Na okay. Ich weiß was ich zutun habe - neben der Langweile gerade.

 

[foofoobar]

Wir haben bei einem aehnlichen Thema versucht, durch Wiederverwendung von Code-Stuecken die I-Cache miss rate zu reduzieren. Aber im Ergebniss ist sie gestiegen; die Erklaerung dafuer war, dass die schlechtere Ausnutzung der Cache-Lines zu mehr cache misses gefuehrt hat als durch die Wiederverwendung eingespart wurden.

Auf den I-Cache in einer Hochsprache zu optimieren zu optimieren stelle ich mir gruselig vor, weil kleinere Änderungen im Code oder ein neues Compiler-Release den erzeugten Code ziemlich verändern kann.

Und typischerweise sind es ja kleine Schleifen wo die Zeit liegen bleibt.

@foofoobar Rekursion ist aus guten Gründen eher ungern gesehen.

Welches sind diese guten Gründe?

Unkenntnis von ulimit?
Computer und/oder Betriebssysteme aus der Steinzeit die Limitierungen beim Stack haben?

 

[DevPandi]

Welches sind diese guten Gründe?

Das hat weniger mit dem Betriebsystem noch mit Limitierungen beim Stack zutun, als viel mehr, dass dir jede "schlecht" optimierte Rekursion irgendwann auf die Füße fällt, sei es, weil die Rückgabewerte nicht einfach "durchgeschliffen" werden, oder man bei Baumstrukturen quasi bis in die tiefste Ebene geht und der Speicher vollläuft.

Deswegen gibt es ja die ganzen Hilkfskonstrukte, dass man zum Beispiel einen Baum in ein "eindimensionales" Array überführt, in dem man mit einer "Hilfsinformation" anzeigt, in welcher Ebene man ist. Oder dass man - wie in meinem Beispiel - mit weiteren Parameter arbeitet, die man einfach übergibt, damit man am Ende einfach zurück läuft oder, wenn man auf solche Hilfskonstrukte verzichtet, dass man eine maximale Tiefe festlegt, bis zu der die Rekursion ausgerführt wird.

Auf den I-Cache in einer Hochsprache zu optimieren zu optimieren stelle ich mir gruselig vor, weil kleinere Änderungen im Code oder ein neues Compiler-Release den erzeugten Code ziemlich verändern kann.

GENAU deswegen macht man solche "händischen" Optimierungen heute nicht mehr, sondern überlässt das dem Compiler und beschränkt sich selbst auf Optimierungen, die man im Code selbst direkt vornehmen kann.

Zum Beispiel eben unnötige Rekursionen auflösen, komplexe Baumstrukturen auf eine Dimension mit Hilfsvariablen/Daten reduzieren. Der Compiler erstrellt daraus dann komplexe Graphen, anhand er dann die Optimierungen vornimmt.

Und gerade, wenn man die eigenen Programme möglichst ohne großen Aufwand auf verschiedene Zielplattformen (Hardware) bringen will, lässt man erst recht von solchen "Mikrooptimierungen" heute die Hand. Im besten Fall gewinnt man in der regel nicht nennenswert an Geschwindigkeit. Im schlimmsten Fall versaut man alles für den Compiler.

 

[foofoobar]

Das hat weniger mit dem Betriebsystem noch mit Limitierungen beim Stack zutun, als viel mehr, dass dir jede "schlecht" optimierte Rekursion irgendwann auf die Füße fällt, sei es, weil die Rückgabewerte nicht einfach "durchgeschliffen" werden, oder man bei Baumstrukturen quasi bis in die tiefste Ebene geht und der Speicher vollläuft.

State auf dem Stack braucht mehr Speicher?

Deswegen gibt es ja die ganzen Hilkfskonstrukte, dass man zum Beispiel einen Baum in ein "eindimensionales" Array überführt, in dem man mit einer "Hilfsinformation" anzeigt, in welcher Ebene man ist. Oder dass man - wie in meinem Beispiel - mit weiteren Parameter arbeitet, die man einfach übergibt, damit man am Ende einfach zurück läuft oder, wenn man auf solche Hilfskonstrukte verzichtet, dass man eine maximale Tiefe festlegt, bis zu der die Rekursion ausgerführt wird.

GENAU deswegen macht man solche "händischen" Optimierungen heute nicht mehr, sondern überlässt das dem Compiler und beschränkt sich selbst auf Optimierungen, die man im Code selbst direkt vornehmen kann.

Zum Beispiel eben unnötige Rekursionen auflösen, komplexe Baumstrukturen auf eine Dimension mit Hilfsvariablen/Daten reduzieren. Der Compiler erstrellt daraus dann komplexe Graphen, anhand er dann die Optimierungen vornimmt.

Und gerade, wenn man die eigenen Programme möglichst ohne großen Aufwand auf verschiedene Zielplattformen (Hardware) bringen will, lässt man erst recht von solchen "Mikrooptimierungen" heute die Hand. Im besten Fall gewinnt man in der regel nicht nennenswert an Geschwindigkeit. Im schlimmsten Fall versaut man alles für den Compiler.

Zeig mal ein Beispiel.

 

[mae]

Auf den I-Cache in einer Hochsprache zu optimieren zu optimieren stelle ich mir gruselig vor, weil kleinere Änderungen im Code oder ein neues Compiler-Release den erzeugten Code ziemlich verändern kann.

Compiler werden ueblicherweise in Hochsprachen geschrieben, und da haben wir eben versucht, ob ein Compiler, der Codestuecke wiederverwendet, eine niedrigere I-cache-Miss-Rate hat. Hatte er nicht, sondern im Gegenteil.

Und typischerweise sind es ja kleine Schleifen wo die Zeit liegen bleibt.

Ist bei vielen Programmen so, und da sind I-Cache misses dann eh kein Problem. Es gibt aber auch Programme, bei denen das anders ist, und da haben wir dann versucht, durch Wiederverwendung etwas zu verbessern, hat aber mehr geschadet als genutzt.

Ergänzung (Mittwoch um 09:26)

Ah ja, in den ein + durch ein - getauscht wird

Der Grund, warum ich in meinem Beispiel - verwendet habe: AMD64 kann mit dem LEA-Befehl schon A=B+C in einem Befehl erledigen. Bei anderen Operationen als + geht's aber nicht.

 

[DevPandi]

Zeig mal ein Beispiel.

Ein relativ simples Beispiel - man muss es ja nicht unnötig aufblähen:

funktion printTree(element) {
    print element.name;
    if (has(element.sub)) {
        printTree(element.sub)
    }
}

Gib dem genug Element und entsprechende Tiefe, und das Ding knallt irgendwann weil entweder der Speichervolläuft oder andere Limitierungen greifen und wenn die anderen Limitierungen greifen, dann um genau sowas zu verhindern.

Der Grund, warum ich in meinem Beispiel - verwendet habe: AMD64 kann mit dem LEA-Befehl schon A=B+C in einem Befehl erledigen. Bei anderen Operationen als + geht's aber nicht.

Ja, auch absolut Okay, am Ende hätte ich auch das schreiben können:

// bisher
A = 1;
B = 2;
C = 3;
D = A;

A = A + B;
E = A;
A = D;
A = A + C;

// A = 4
// B = 2
// C = 3
// D = 3

// Mit APX
A = 1;
B = 2;
C = 3;
D = A + B;
E = A + C;

Ist jetzt mein kurzs Beispiel, sammt Text aufgebläht, am Ende wird das Prinzip damit klar, für das Prinzip muss man sich nicht auf die Eigenheiten einer Architektur stützen.

-- Edit - im Übrigen mal als Ergänzung, weil AMD auf GPUOpen echt viele Vorträge und co hat: https://gpuopen.com/learn/ - Einfach mal Videos, Folien und Co ansehen. Auch wenn es da primär um RDNA geht, da werden wichtige Prinzipien beschrieben, die heute als "Entwickler" gelten, sobald man in eine Hochsprache geht: Low-Level-Optimierung auf Operation- und Cache-Ebene machen die Compiler, weil die Compiler-Entwickler entsprechende Regeln aufstellen und den "produzierten" Maschinencode nach und nach, auch mit feineren Regeln optimieren.

Entwickler, die dann C++, RUST und Co verwenden: Algorithmen sowie Datenstrukturen optimieren, eventuell wenn man mMerkt das es kracht, den Datenfluss noch.

 

[mae]

Ein relativ simples Beispiel - man muss es ja nicht unnötig aufblähen:

funktion printTree(element) {
    print element.name;
    if (has(element.sub)) {
        printTree(element.sub)
    }
}

Gib dem genug Element und entsprechende Tiefe, und das Ding knallt irgendwann weil entweder der Speichervolläuft

Wenn der Compiler tail-call Optimierung durchfuehrt (in z.B. Scheme Pflicht), dann passiert das in diesem Beispiel nicht. Man kann aber problemlos Beispiele zeigen, die keine Tail-calls sind.

 

[DevPandi]

@mae Ja, da bin ich dann irgendwo halb abgebogen, dann machen wir es halt noch griffiger - und das lustige ist, sowas sieht man aufgrund der Einfachheit gerade bei der Ausgabe von Baumstrukturen sehr oft:

function parseName(element) {
    returnValue = element.name;
    if (has(element.subs)) {
        foreach (element.subs as sub) {
            returnValue .= parseName(sub);
        }
    }
    
    return returnValue
}

 

[DKK007]

Ja hab grad nochmal geschaut was Moore's law an leaks präsentiert hat und hast wohl recht betrifft wohl mehr die x3d, ansonsten kommt man vor allem neben mehr cores (auch pro CCD) und immerhin auch mehr Cache ohne x3d auf nen deutlich überarbeiteten Speicherkontroller, was bisher bei AMD eher ein Flaschenhals war.

"Non monolyptic Zen 6 products werden "bridge dies" nutzen um sie zu higher speed IOD zu verbinden.

Wobei es da um Medusa geht war das nicht nur die Laptop Varianten?

Die APUs sind aber schon immer anders aufgebaut als die Desktop-CPUs.

 

[Nagilum99]

Ah ja, in den ein + durch ein - getauscht wird und der Text: das verhindert, dass eine Kopie von Angelegt werden muss, ist natürlich dann mit einem A = B er gibt dann mehr Sinn.

Hast du dir das noch mal durchgelesen, bevor du es abgeschickt hast?

 

[eastcoast_pete]

Nein, das ist an der Stelle vollkommen falsch!

APX erweitert die grundlegende x86-ISA um 16 weitere Register, sowie die Möglichkeit, dass viele Operationen ab jetzt nicht mehr zwangsweise ein Register überschreiben.

Für letzteres kurzes Beispiel A = A + B. Das kann nun auch ein A = B + C sein. Das verhindert an der Stellen, dass eine Kopie von einem Register angelegt werden muss - womit man sich eben genau das sparrt und mit den andegen beiden Registern weiter arbeiten kann.

Die Vergrößerung von 16 auf 32 Register wiederum ist für den Compiler primär wichtig, weil weniger Load, Store, sowie eben Copy-Anweisungen im Binary zu finden sind. Auch für die µ-Arch kann das später vorteile haben, weil das Programm wesentlich länger mit den vorhanden Registern arbeiten kann - das "Fehlen" von Load- und Store-Anweisungen entlasstet an der Stelle die Infrastruktur der CPU. Ebenso wird es für OoO und die spekulative Ausführung einfacher, weil zwar weiterhin hier mit Schattenregister und Register-Renaming gearbeitet wird, gleichzeitig sinkt jedoch der Aufwand für dessen Verwaltung.

Damit ist es am Ende auch einfacher für einen Thread einen CPU-Kern wirklich auszulasten, weil man nicht auf Daten im Cache oder schlimmsten Fall RAM warten muss, viel mehr Optionen hat Werte "zwischen" Zulagern direkt im Kern und am Ende die Verwaltung dessen auch einfacher wird.


Nein, es ist nicht kompatibel mit älterere Software, die alte Software kann weiterhin nur die 16 Register nutzen. Damit die Software es nutzen kann, muss sie neu kompiliert werden.

So richtig wird sich APX sobald man auch weiß, ob AMD hier "mitziehen" darf. Bis dahin klingt APX toll und wird bei Software, die APX unterstützt auch dafür sorgen, dass die Kerne besser ausgelastet werden können. Die breite Unterstütztung wird allerdings erst kommen, wenn AMD es auch hat.

Nein, nicht mehr Leistung durch Schalter und auch hier nicht per Software. APX ist eine ISA-Erweiterung und hat entsprechende Auswirkung direkt auf die Hardware, weil die ISA bestimmte, was die Hardware machen kann.

AFAIK müssen sich Intel und AMD jede Erweiterung zur x86 ISA Cross-Lizensieren. War (wieder AFAIK) wichtiger Bestandteil der Abmachungen, die den Rechtsstreit zwischen den beiden Firmen beendete. Und diese Verpflichtungen sind keine Einbahnstraße, denn so kam Intel zu den 64 Bit Erweiterungen (x64), die ja von AMD entwickelt wurden.