Jammer-Thread

[Schrompf]

10$ Preis? Dann hol es Dir doch. Oder hab ich da was übersehen?

[Artificial Mind]

Toa-chan hat nicht genügend Mäuse auf seinem Paypal :D

[Toa]

Und ist schwab^^

[glassbear]

Geil, jetzt macht sogar meine Bank auf Kontoauszuegen und im Internet in der Kontouebersicht Werbung zwischen den Posten basierend auf dem, wo ich mein Geld so ausgebe :shock:

Das sind javascript-Dinger, die ich nicht geblockt kriege :evil:

[CodingCat]

Gibt es einen Grund, warum die STL mit algorithm(src, srcEnd, dest) genau dem Gegenteil von memcpy/memmove(dest, src, size) entspricht? Ich halte mich meist an die STL-Reihenfolge und habe es prompt in einem Algorithmus verhauen, indem ich dest und src von memmove verdreht hatte. :evil:

Etwas Anti-Jammer: Zum ersten Mal seit unzähligen Jahren habe ich durchgehende Hot-Swap-Funktionalität, einigermaßen elegant und für alle Ressourcen-Typen und Subsysteme. Um dabei nicht in Objekt-Abhängigkeiten zu ersticken, habe ich ein zentrales Monitoring-Objekt, das die Typen gerade geänderter Komponenten sammelt und abhängigen Subsystemen zur Abfrage bereit hält. Der Austausch alter Ressourcen durch neue Ressourcen erfolgt durch einen einfachen Nachfolger-Zeiger in der alten Ressource, der von der Ressourcenverwaltung bei Veränderung gesetzt wird und von abhängigen Subsystemen ausgelesen wird.

[eXile]

Gibt es einen Grund, warum die STL mit algorithm(src, srcEnd, dest) genau dem Gegenteil von memcpy/memmove(dest, src, size) entspricht? Ich halte mich meist an die STL-Reihenfolge und habe es prompt in einem Algorithmus verhauen, indem ich dest und src von memmove verdreht hatte. :evil:

Jemand hat mir mal erzählt, dass die Reihenfolge von memcpy/memmove die entsprechende Assembler-Reihenfolge aus Gewohnheitsgründen widerspiegelt (also mov eax,0h). Warum aber die Reihenfolge in der STL dann umgekehrt ist, erklärt das aber nicht. Vielleicht ist es die Umstellung von mathematischer Notation (dest = src) auf Zuweisungsnotation der Informatik (src → dest).

[Niki]

Gibt es einen Grund, warum die STL mit algorithm(src, srcEnd, dest) genau dem Gegenteil von memcpy/memmove(dest, src, size) entspricht? Ich halte mich meist an die STL-Reihenfolge und habe es prompt in einem Algorithmus verhauen, indem ich dest und src von memmove verdreht hatte. :evil:

Ich vermute mal, dass die meisten gängigen Programmiersprachen die Reihenfolge (source, destination) benutzen, weil sie "natürlicher" ist. Mit Sicherheit weiß ich das von C# und Java. Wenn man nun Algorithmen, oder gar ganze Engines oder Programme, von einer Sprache in eine andere portieren muss, dann vergisst man schnell mal die Reihenfolge umzudrehen. Mir persönlich ist das bisher nur einmal passiert, aber ich war dabei als eine 2D engine für mobile Geräte erst in Java geschrieben, dann nach C++, und dann von C++ nach C# portiert wurde. Und jedes Mal hat sich diese Reihenfolge umgedreht. Auch Wartung und der Einbau neuer Features mussten immer gleich in 3 Sprachen geschehen. Da hätte man sich manchmal gewünscht, dass diese Reihenfolge überall dieselbe wäre.

Man beachte übrigens wie ich automatisch "von C++ nach C#" (source, destination) geschrieben habe, und nicht "nach C# von C++" (destination, source).

[SunCross]

Jetzt hab ich nen neuen USB-Raketenwerfer, aber irgendwie will der sich nicht untersuchen lassen. Ich hab zwar alle, für die USB-Verbindung zu meinem Programm benötigten Daten bereits gesammelt, was nich so schwer is, stehen im Geräte-Manager, aber mein Computer sagt Nein.

Was ich sehr komisch finde ist, dass ich mich nicht mal mit dem Raketenwerfer verbinden kann, dass ging bis jetzt bei jedem Raketenwerfer sofort.

Das nervt ein wenig.

[CodingCat]

War es früher schon praktisch unmöglich, Qt zum Laufen zu bekommen, so ist dies mit Qt 5 noch einmal konsequent weiterentwickelt worden. Qt 5 - designed not to run - erfordert erstmals Python zur Konfiguration. qmake erbricht sich dann wie gewohnt in einer bunten Mischung aus absoluten und relativen Pfaden. Neu ist, dass die generierten Projektdateien nicht mal mehr in ihrem Originalverzeichnis kompilierbar sind, weil CPP-Dateien mit speziellen Einstellungen jetzt per Custom Build Tool eingebunden werden, wobei die entsprechende cl-Kommandozeile ganz offensichtlich unvollständig ist. Hat man diese Kommandozeilen dann händisch um die vielzähligen projektweiten Präprozessordefinitionen erweitert, libcmt.lib auf die Ignore-Liste des Linkers gesetzt, Manifest-Einbettung deaktiviert und ein totes Kaninchen bei Vollmond vergraben, beglückt einen der Linker ggf. mit einigen Binaries. Kurz darauf stellt man beim Starten der eigenen Qt-Anwendung fest, dass es neuerdings eine Plugin-Architektur gibt, und Unterstützung für einzelne Plattformen jetzt in Plattform-Plugins ausgelagert ist. Diese Plugins verstecken sich in einem weiteren Unterordern des qtbase/src-Ordners, der ebenfalls gebaut werden will. Diese Plugin-Dlls haben dann in einem plugin/platforms-Ordner der ausführbaren Anwendungsdatei zu liegen, wo ich sie soeben hinbugsiert habe. Nun startet meine Anwendung endlich mit folgender vielversprechenden Meldung: Failed to load platform plugin "windows". Available platforms are: windows, minimal. Das ist vor dem Crash.

Nachtrag: Ich hatte versehentlich die Plugin-DLLs aus den pre-built VS2010 Qt Binaries kopiert anstatt der selbstgebauten. Mit den selbstgebauten geht es nun.

[antisteo]

War es früher schon praktisch unmöglich, Qt zum Laufen zu bekommen, so ist dies mit Qt 5 noch einmal konsequent weiterentwickelt worden. Qt 5 - designed not to run - erfordert erstmals Python zur Konfiguration. qmake erbricht sich dann wie gewohnt in einer bunten Mischung aus absoluten und relativen Pfaden. Neu ist, dass die generierten Projektdateien nicht mal mehr in ihrem Originalverzeichnis kompilierbar sind, weil CPP-Dateien mit speziellen Einstellungen jetzt per Custom Build Tool eingebunden werden, wobei die entsprechende cl-Kommandozeile ganz offensichtlich unvollständig ist. Hat man diese Kommandozeilen dann händisch um die vielzähligen projektweiten Präprozessordefinitionen erweitert, libcmt.lib auf die Ignore-Liste des Linkers gesetzt, Manifest-Einbettung deaktiviert und ein totes Kaninchen bei Vollmond vergraben, beglückt einen der Linker ggf. mit einigen Binaries. Kurz darauf stellt man beim Starten der eigenen Qt-Anwendung fest, dass es neuerdings eine Plugin-Architektur gibt, und Unterstützung für einzelne Plattformen jetzt in Plattform-Plugins ausgelagert ist. Diese Plugins verstecken sich in einem weiteren Unterordern des qtbase/src-Ordners, der ebenfalls gebaut werden will. Diese Plugin-Dlls haben dann in einem plugin/platforms-Ordner der ausführbaren Anwendungsdatei zu liegen, wo ich sie soeben hinbugsiert habe. Nun startet meine Anwendung endlich mit folgender vielversprechenden Meldung: Failed to load platform plugin "windows". Available platforms are: windows, minimal. Das ist vor dem Crash.

Nachtrag: Ich hatte versehentlich die Plugin-DLLs aus den pre-built VS2010 Qt Binaries kopiert anstatt der selbstgebauten. Mit den selbstgebauten geht es nun.

Genau aus diesem Grund gibt es Distributoren, die sich darum kümmern, dass aus Quellcode Binaries entstehen, die genau auf dein System zugeschnitten sind. Warum machst du dir die Arbeit selber?

[CodingCat]

Weil es keine Binaries gibt, die auf mein System zugeschnitten sind.

[j.klugmann]

Für Masochisten gibts den ganzen Spaß auch in der VS2012-Version mit extra viel Compiler-Fehlern und Linker-Problemen.

[Krishty]

Ich hatte mal leise aufgeschnappt, dass für C++11 einige Regeln betreffend Aliasing an C99 angepasst worden seien. Kennt zufälligerweise jemand einen guten Artikel dazu oder kann mir erklären, was genau da passiert ist? Vielleicht verwechsle ich das ja bloß mit den C99-Integertypen, die in den Standard gezogen wurden …

[Krishty]

Bah ist Gimp scheiße zu benutzen. Dauernd irgendwelche Knöpfe, die nicht reagieren; Textboxen, in denen ich nicht richtig markieren kann, und Ordneransichten, in denen ich mich nicht zurechtfinde.

Ich denke, dass jeder, der eine plattformunabhängig gleiche GUI baut, ein Vollidiot ist. Diese Kasper, die meinen, dass sich Knöpfe überall gleich bedienen lassen müssen, sind wahrscheinlich dieselbe Gattung Radikaler, die den Java-Gleitkommastandard erfunden haben, und drehen mir die Eingeweide auf links.

Ich benutze Windows. Ich will, dass sich alle Bedienelemente, die ich auf diesem System jemals befummeln muss, so anfühlen, wie ich es von Windows-Bedienelementen gewohnt bin. I'm talking Klickbereich. I'm talking Markierungsfarbe. And I'm talking Verhalten beim Wegziehen. Das gilt für GTK+, für Java-Klickibunti und alles andere da draußen auch.

Wer seine GUI so auslegt, dass sie sich überall maximal vom Rest des Systems unterscheidet und damit argumentiert, dass -1 und +1 wieder 0 ergeben, gehört öffentlich gedemütigt damit er nie wieder auf die Scheißidee kommt, sich an eine Benutzeroberfläche zu trauen.

[dot]

Du sprichst mir aus der Seele...

[Aramis]

Merkwuerdigerweise sind plattformunabhaengige GUIs besser wenn sie primaer unter Windows oder unter Mac OS X entwickelt wurden - auch unter Linux. Mysterioes.

[CodingCat]

Leute! Qt ist ja so ein Framework, das hervorragende Funktionalität bietet und wunderbar natives UI-Verhalten aufweist (ok, ich kenne nur die Windows-Seite). Nun habe ich aber die letzten paar Tage einen sehr großen Teil meiner Zeit damit verbringen müssen Qt 5 zu debuggen. Die eingebaute Docking-Oberfläche, bisher wirklich ein positives Alleinstellungsmerkmal unter all den UI-Frameworks da draußen, ist komplett im Eimer. Und das, was ich beim Durchsteppen sehe, treibt mich Qt-gewohnt in den Wahnsinn. Einfache Logik und Struktur ist nicht erkennbar, das Ganze sieht aus wie das Ergebnis von unzähligen durchsoffenen Trial-&Error-Nächten. Wenn ihr mal sehen wollt, wovon Krishty und sein eifriger Papagei hier sprechen, wenn sie von unendlich ausgedehnten Zustandsräumen und Zustandsproliferation erzählen, dann nehmt euch irgendeine Stelle in der QtGui; genau das ist die in diesem Fall unausweichliche State Hell, die keine Seele heil lässt. Sollte es in diesem undurchdringlichen Haufen nur einen Hauch von Konsistenzgarantien geben, dann liegen diese in einer verschlossenen Schublade des eingestürzten Trolltech-Geheimarchivs und haben ihre Gültigkeit längst eingebüßt.

[CodingCat]

WARUM arbeiten List Views im Jahre 2013 immer noch mit INDIZES?! Ich hatte zunächst geglaubt QModelIndex wäre ein netter Wrapper mit automatischer Aktualisierung; Pustekuchen:

Code: Alles auswählen

Q_FOREACH (QModelIndex idx, this->selectedIndexes())
{
	lean::scoped_ptr<QStandardItem> item( model->takeItem(idx.row()) );
	model->removeRow(idx.row());
	Q_EMIT itemDeleted(item);
}

Vorher:  1 | 2 | 3 | 4
Nachher: 1 | 3

Ich möchte nicht wissen, in wie viel Code da draußen solche Lücken unbemerkt schlummern.

[hagbard]

Der Qt Standardweg für das was du erreichen willst ist aber dass dein abgeleitetes Model eine Methode removeRows() anbietet, denen du einen QModelIndex-Bereich übergeben kannst. Das löschen von Zeilen wird mit beginRemoveRows() und endRemoveRows() markiert. Aber die Model-Item-Klassen von Qt sind auch manchmal etwas unintuitiv und eklig zu debuggen.

[CodingCat]

Fang bloß nicht mit Qt Models an, diese Dinger werde ich in meinem Leben freiwillig nicht mehr anrühren. Aus dieser indexüberladenen Hölle kommt das ganze Übel ja gerade. Zum Glück reicht praktisch immer QStandardItemModel. QAbstractItemModel sicher selbst zu implementieren erscheint mir ein Himmelfahrtskommando; trotz umfassender Doku ist dieses aufgedunsene Schwammgewächs ja nicht mal in seinem intendierten Verhalten voll zu erfassen.

Übrigens hilft removeRows() so oder so nicht - das QStandardItemModel bietet diese Funktion ja auch - die Indizes sind jedoch schlichtweg nicht konsekutiv. Da mir in diesem Müllberg von Framework inzwischen ohnehin alles egal ist, hole ich mir einfach nach jeder gelöschten Zeile erneut die Liste selektierter Indizes.

[Schrompf]

Falsch:

Code: Alles auswählen

 uint64_t muster = (1 << unterstesBit);

Richtig:

Code: Alles auswählen

 uint64_t muster = (1ull << unterstesBit);

Das eine endet in einer Endlosschleife, das andere funktioniert. Ich muss noch viel lernen, bevor ich den schwarzen Gürtel im Bitschubsen erwerben kann.

[Krishty]

Dann warte erstmal unsigned infection ab (wenn dir irgendwann in einer Zeile das Vorzeichen verloren geht weil einer der Operanden unsigned deklariert ist) … C++’ Ganzzahltypen und -Literale sind ein schlechter Scherz.

[Krishty]

Wie bescheuert ist Visual C++ eigentlich? Hier aus meiner binären Suche:

while(toBeginning < toEnd) {
    auto const toSample = toBeginning + (toEnd - toBeginning) / 2;

Die zweite Zeile erzeugt den folgenden Maschinentext:
mov    rax,r8
sub    rax,r9
sar    rax,4
cqo   
sub    rax,rdx
sar    rax,1
shl    rax,4
add    rax,r9

What. cqo? Etwa Convert Quad to Oct, das Visual C++ vor vorzeichenbehafteten Divisionen einsetzt, um das Vorzeichen der Zahl zu replizieren?!

Ja; genau das.

Steht nicht eine Zeile höher, dass das Ergebnis der Subtraktion unmöglich negativ sein kann?

Ja.

*seufz*

Also von Hand:

while(toBeginning < toEnd) {
    auto const toSample = toBeginning + uintptr_t(toEnd - toBeginning) / 2u;

mov    rax,r8
sub    rax,r9
sar    rax,4
shr    rax,1
shl    rax,4
add    rax,r9

Wieder zwei Befehle gespart.

Dabei hatte ich den x64-Compiler von VS2012 ja schon fast gelobt. Aber seit ich für alles nur noch Iteratoren (lies: Zeiger) benutze, und festgestellt habe, dass der mit Zeigerarithmetik absolut nicht zurechtkommt, ist wieder alles beim Alten.

[Krishty]

Warum erzeugt Visual C++ für do while-Schleifen konsequent besseren Maschinentext als für for-? Gibt es da irgendwelche technischen Gründe, dass zusätzliche Invarianten gelten oder so?

[dot]

Steht nicht eine Zeile höher, dass das Ergebnis der Subtraktion unmöglich negativ sein kann?

Wär mal interessant, ob du in dem Fall mit __assume() was erreichen kannst.

Edit: Ok, vermutlich nicht...

Warum erzeugt Visual C++ für do while-Schleifen konsequent besseren Maschinentext als für for-? Gibt es da irgendwelche technischen Gründe, dass zusätzliche Invarianten gelten oder so?

Wirklich generell, oder bei einer ganz bestimmten Form von Schleife?

[Krishty]

Keine Ahnung – ich habe mir vor ein paar Monaten angewöhnt, wieder do while-Schleifen zu verwenden; und eben zum dritten Mal bemerkt, dass dadurch weniger Maschinentext produziert wurde. Könnte auch mit meinem Hang zu Iteratoren zusammenhängen. Testfall …

for mit Zähler (21 Befehle (ja – scheiß Maß; aber das ist halt, was ich beim Drübergucken sehe)):

Code: Alles auswählen

for(auto i = 0u; i < myNumberOfLoDs; ++i) {

	mov         edi,r15d
	cmp         dword ptr [rbx+158h],r15d
	jbe         Shape+12Bh
	mov         esi,0FFh
	nop

	UnsignedInt4B thisLODsParameterUsageFlags = 0u;
	auto toFFFFMark = verifyBytecode<false>(
		myLODs[i].toBeginning,
		myLODs[i].toEnd,
		myLODs[i].XYZLimit,
		thisLODsParameterUsageFlags
	);

	mov         ecx,edi
	lea         r9,[this]
	mov         dword ptr [this],r15d
	lea         rax,[rcx+rcx*2]
	lea         rcx,[rcx+rcx*2]
	mov         rcx,qword ptr [rbx+rcx*8+168h]
	movsx       r8d,word ptr [rbx+rax*8+164h]
	mov         rdx,qword ptr [rbx+rax*8+170h]
	call        verifyBytecode<0>

	if(Opcode::abort != *toFFFFMark) {

	cmp         si,word ptr [rax]
	jne         Shape+154h (014000B174h)

	}
	parameterUsageFlags = parameterUsageFlags | thisLODsParameterUsageFlags;

	mov         eax,dword ptr [this]
	inc         edi
	or          dword ptr [rbx+1C0h],eax
	cmp         edi,dword ptr [rbx+158h]
	jb          Shape+0E0h

}

for mit Iterator (25 Befehle (WTF!)):

Code: Alles auswählen

for(auto toCurrentLOD = myLODs; toCurrentLOD < myLODs + myNumberOfLoDs; ++toCurrentLOD) {

	mov         eax,dword ptr [rdi+158h]
	lea         rax,[rax+rax*2]
	lea         rax,[rax+2Ch]
	lea         rax,[rdi+rax*8]
	cmp         rbx,rax
	jae         Shape+136h
	mov         esi,0FFh
	nop         dword ptr [rax+rax]

	UnsignedInt4B thisLODsParameterUsageFlags = 0u;
	auto toFFFFMark = verifyBytecode<false>(
		toCurrentLOD->toBeginning,
		toCurrentLOD->toEnd,
		toCurrentLOD->XYZLimit,
		thisLODsParameterUsageFlags
	);

	movsx       r8d,word ptr [rbx+4]
	mov         rdx,qword ptr [rbx+10h]
	mov         rcx,qword ptr [rbx+8]
	lea         r9,[this]
	mov         dword ptr [this],r15d
	call        verifyBytecode<0>

	if(Opcode::abort != *toFFFFMark) {

	cmp         si,word ptr [rax]
	jne         Shape+15Fh

	}
	parameterUsageFlags = parameterUsageFlags | thisLODsParameterUsageFlags;

	mov         eax,dword ptr [this]
	add         rbx,18h
	or          dword ptr [rdi+1C0h],eax
	mov         eax,dword ptr [rdi+158h]
	lea         rax,[rax+rax*2]
	lea         rax,[rax+2Ch]
	lea         rax,[rdi+rax*8]
	cmp         rbx,rax
	jb          Shape+0F0h

}

do while mit Iterator (19 Befehle):

Code: Alles auswählen

auto toCurrentLOD = myLODs;
	mov         esi,0FFh
	nop         word ptr [rax+rax]
do {

	// Parse the bytecode. This will return the position of the FFFF mark at the end of a LOD. Furthermore, all
	//	parameters which are used by the bytecode will be flagged so the viewer can show active flags to the user.
	UnsignedInt4B thisLODsParameterUsageFlags = 0u;
	auto toFFFFMark = verifyBytecode<false>(
		toCurrentLOD->toBeginning,
		toCurrentLOD->toEnd,
		toCurrentLOD->XYZLimit,
		thisLODsParameterUsageFlags
	);

	movsx       r8d,word ptr [rbx+4]
	mov         rdx,qword ptr [rbx+10h]
	mov         rcx,qword ptr [rbx+8]
	lea         r9,[this]
	mov         dword ptr [this],r15d
	call        verifyBytecode<0>

	if(Opcode::abort != *toFFFFMark) {

	cmp         si,word ptr [rax]
	jne         Shape+14Fh

	}
	parameterUsageFlags = parameterUsageFlags | thisLODsParameterUsageFlags;

	mov         eax,dword ptr [this]

				++toCurrentLOD;
	add         rbx,18h
	or          dword ptr [rdi+1C0h],eax

} while(toCurrentLOD < myLODs + myNumberOfLoDs);

	mov         eax,dword ptr [rdi+158h]
	lea         rax,[rax+rax*2]
	lea         rax,[rax+2Ch]
	lea         rax,[rdi+rax*8]
	cmp         rbx,rax
	jb          Shape+0E0h  

Visual C++ 2012 x64.

[CodingCat]

Warum erzeugt Visual C++ für do while-Schleifen konsequent besseren Maschinentext als für for-? Gibt es da irgendwelche technischen Gründe, dass zusätzliche Invarianten gelten oder so?

In deinem Testfall dupliziert die for-Schleife die Bedingung einfach, einmal für den Eingang und einmal für die Wiederholung. Ich vermute das geschieht zur Vermeidung von Doppelsprüngen. Deine do ... while Schleife erfordert in der Tat eine zusätzliche Invariante, nämlich dass deine Iterator-Range nicht leer ist. In C++-Code zurückübersetzt führt der Compiler einfach folgendes durch:

Code: Alles auswählen

//von
for (a; b; c) ...
// zu
a;
if (b) do { ...; c; } while (b)

Fazit: Dein letzter Testfall ist semantisch verschieden ("schwächer") und generiert deshalb auch weniger Text. Wirklich traurig an deinen Beispielen ist hingegen, dass myLODs + myNumberOfLoDs stets neu berechnet wird, offenbar kann der Compiler hier kein Aliasing ausschließen?

[Krishty]

Die Katze hat absolut recht; ja! Ich dachte, die Zeiten, in denen Sprungvorhersage Rücksprünge bevorzugt, wären vorbei … und ja; das ist echt traurig. Gut, dass du mich drauf aufmerksam gemacht hast; ich werde meinen Text jetzt so schreiben wie 1985.

[Krishty]

Gut, dass du mir das gesagt hast, Cat – bei genauem Hinsehen fällt mir auf, dass Visual C++ für jedes Attribut innerhalb einer Methode Aliasing oder Wirkung anzunehmen scheint. Manche Schleifen schrumpfen hier um 25 % zusammen, sobald ich die Obergrenze in eine lokale Variable schreibe.

Ich vermute, dass das damals der Grund war, dass der Kompressionsalgorithmus schneller wurde, nachdem ich ihn aus seiner Klasse genommen und in freie Funktionen mit einer struct Context gesteckt habe.

Übrigens noch eine Erinnerung für deine Ranges: Falls du Zeiger auf Anfang und Ende speicherst, implementiere isEmpty() nicht als 0 == count() sondern als begin() == end(). VC kann nämlich nur schwach Zeigerarithmetik optimieren und würde für die erste Version tatsächlich Subtraktion und Division vor dem Vergleich ausspucken. Benutz count() am besten nur, falls es sich nicht vermeiden lässt.

Wie eine Zeitreise zurück zu Visual C++ 6.0, das alles …

[Krishty]

Ich hatte ja schonmal geschrieben, dass ich meine Engine deutlich schneller gekriegt habe, indem ich in Schleifen von Indizes auf Iteratoren (Zeiger) umgestiegen bin. Jetzt wühle ich mich gerade durch alle Schleifen meines Programms, und finde dabei immer wieder solche Stellen. Je nach Schleife liegt die Verbesserung höchstens am Rand des Rauschens; manchmal 0,5 %; manchmal 2. Aber in der Masse wird es ziemlich deutlich spürbar. Und das alles, obwohl der Text mit Iteratoren größer wird als mit Zählern. Ich erreiche bald 60 Hz Full HD auf einem Core 2 Quad statt auf einem Core i7.

Entweder ist dieses ganze Gerede von superskalarer OoO-Ausführung und LEA als Nulltaktanweisung totaler Unsinn, oder meine Schleifen sind allesamt hart Registerlimitiert. Oder die Benchmarks, die was in die Gegenrichtung beweisen, sind alle realitätsfremd. Irgendwas stimmt jedenfalls nicht mit dem, was mir die Leute immer erzählen.

P.S.: 3000stes Gejammer schon … wer das hier liest muss ja echt überzeugt sein, dass die IT am Abgrund steht …

… und noch peinlicher ist, dass ich aktuell knapp über 3200 Nachrichten erstellt habe und hier gerade alles mit mir vollgekleistert ist.