Jammer-Thread

[kaiserludi]

Also ich bin ja überaus gespannt auf Clang + Eclipse. Sobald das gut läuft, könnte es sehr gut sein, dass ich mich von Visual Studio verabschiede. Jedenfalls wenn dann Eclipse für C++ so gut ist, wie für Java (immerhin ist Eclipse der Grund, aus dem Java erst erträglich geworden ist).

Eclipse ist doch so ziemlich die mieseste IDE auf dem Markt.

[Krishty]

Es wird nur kritisch, wenn der Compiler aus welchen Gruenden auch immer annehmen sollte, ein Map oder Unmap-Aufruf waere seiteneffektfrei und deshalb Lade/Schreiboperationen "ueber" die Funktionsaufrufe zieht. Und das sollte wirklich nicht passieren.

Stimmt, das hatte ich vergessen – vor Aufrufen unbekannter Wirkung muss der Compiler sowieso einen konstanten Zustand herstellen.

da der MS Compiler anscheinend immer noch glaubt es ist eine gute Idee eine 0 per xor zu erzeugen, statt sie als Konstante zu setzen. Das war auf alten Pentium Prozessoren der Fall, bei modernen CPUs ist das aber nicht mehr so.

Sicher? Zumindest von Intel-CPUs weiß ich, dass sie es tatsächlich als Nullen mit Aufbrechen von Abhängigkeiten implementieren und nicht als wirkliches Lesen; XOR; Schreiben. Die xor-Version ist dabei kürzer als die Konstante; es passt also bei gleicher Wirkung mehr Maschinentext in den Cache.

[dot]

Der Fall, den die MSDN nennt, ist aber ein ziemlicher Sonderfall, da der MS Compiler anscheinend immer noch glaubt es ist eine gute Idee eine 0 per xor zu erzeugen, statt sie als Konstante zu setzen. Das war auf alten Pentium Prozessoren der Fall, bei modernen CPUs ist das aber nicht mehr so.

Das bildet sich der MS Compiler nicht einfach nur ein. Wie Krishty schon gesagt hat, ist das ganz besonders bei modernen CPUs genau so der Fall, nicht nur weil die Instruction kleiner ist, sondern auch was Instruction Level Parallelism angeht. Siehe dazu das Intel Software Optimization Manual ;)

[CodingCat]

Soll das ein Witz sein? Ich kann die Anzahl mittels Stream Output geschriebener Primitive nur per SO Query zurück zur CPU lesen, sie aber nicht einfach auf der GPU in einen (Constant) Buffer schreiben? Wie zur Hölle soll ich jetzt Stream Output Buffers im Compute Shader vararbeiten?!?

[Krishty]

sondern auch was Instruction Level Parallelism angeht.

Wo hat denn das Laden einer Konstante (natürlich angenommen, sie füllt das gesamte Register aus!) Nachteile bezüglich Nebenläufigkeit gegenüber einem XOR?

[dot]

mov wird von der CPU nicht als dependency breaking erkannt wie du schon gesagt hast, xor reg, reg schon...

Some micro-ops can execute to completion during rename and are removed from the
pipeline at that point, effectively costing no execution bandwidth. These include:

• Zero idioms (dependency breaking idioms)
• NOP
• VZEROUPPER
• FXCHG

[...]

Instruction parallelism can be improved by using common instructions to clear
register contents to zero. The renamer can detect them on the zero evaluation of the
destination register.

Use one of these dependency breaking idioms to clear a register when possible.

• XOR REG,REG
• SUB REG,REG
• PXOR/VPXOR XMMREG,XMMREG
• PSUBB/W/D/Q XMMREG,XMMREG
• VPSUBB/W/D/Q XMMREG,XMMREG
• XORPS/PD XMMREG,XMMREG
• VXORPS/PD YMMREG, YMMREG

Since zero idioms are detected and removed by the renamer, they have no execution
latency.

[Krishty]

Uff; da muss ich nachforschen. Ich meine gelesen zu haben, dass ein mov reg, mem in ein gesamtes Register sehr wohl die Abhängigkeiten bricht … zumindest für SSE war ich mir absolut sicher. Es erscheint mir auch zu einfach, als dass sie das nicht eingebaut haben (wo ja sonst jede noch so absurde Nischenoptimierung drin ist). Mal suchen gehen.

Nachtrag: Du hast absolut recht.

Furthermore, they do not consume an issue port or an execution unit. So using zero idioms are preferable than moving 0’s into the register.

[dot]

Ich wollte gerade den gleichen Satz posten :D

[Lynxeye]

Ok, da hab ich wirklich falsch gelegen. Auch AMD meint das selbe:

Rationale
AMD Family 15h processors are able to avoid the false read dependency on the XOR instruction.

Acceptable
mov reg, 0

Preferred
xor reg, reg

Ändert aber nichts an der Ursprungsaussage, dass der angeführte =0 Fall der MSDN eher die Ausnahme denn die Regel ist.

Warum diskutieren wir eigtl. die solche Sachen immer im Jammerthread?

[dot]

Wär auch blöd wenn AMD es genau anders rum machen würd wie Intel :D

Warum diskutieren wir eigtl. die solche Sachen immer im Jammerthread?

Gute Frage. Ist wohl so dass die wirklich interessanten Themen beim Jammern hochkommen ;)

[Krishty]

Ich persönlich poste ja kaum noch woanders und kann dementsprechend schwer woanders darüber diskutieren – das erklärt zumindest mir diesen Zufall ;)

[eXile]

Warum lesen sich eigentlich OpenGL-Präsentationen genauso wie damals im Jahre 2003? Die Präsentationen sehen in ihrer Essenz vollkommen gleich aus. Irgendwie hört man immer die gleichen Aussagen, frei nach dem Motto „hurrrr wenn wir weiter so viele Versionen veröffentlichen sind wir bald™ \($10^{100}$\)-mal schneller als alles dagewesene“; jedes Jahr natürlich. Ich glaub' keinem mehr von irgendeiner Seite irgendwas.

(Wobei bindless Texturen eigentlich schon schön wären. Kommt vermutlich erst in Direc3D vNext.)

[CodingCat]

Jedes Mal, wenn ich von Dozenten an der Uni vom Java GC vorgeschwärmt bekomme (und dabei beiläufig C++ runtergeputzt wird), wünschte ich mir, ein gewisses Forenmitglied hätte bereits so viel informatischen Ruhm erlangt, dass ich mit Autorität zitieren könnte:

Ein Garbage Collector ist ein Designfehler.

Traurig, dass C++ mit all seinem Balast und Macken noch immer die einzig mir bekannte Sprache ist, die Ressourcenverwaltung (und damit einhergehend Fehlerbehandlung) sinnvoll ermöglicht.

[eXile]

Jedes Mal, wenn ich von Dozenten an der Uni vom Java GC vorgeschwärmt bekomme

Meinen Dozenten war es nach dem dritten Semester egal, in welchen Programmiersprachen wir die Probleme gelöst haben. In manchen Fällen (Ray-Tracer schreiben) fällt die Wahl ganz natürlich auf C++; welches wir natürlich im Studium nie behandelt haben.

[CodingCat]

Es geht nicht um irgendwelche Aufgaben, es geht um die vermittelte Idealvorstellung und die fehlenden Konzepte für strukturierte und verlässliche Programmierung. Dass Java mit seiner verkorksten Ausnahmebehandlung, und damit einhergehend der misslungenen Ressourcenverwaltung durch den GC, gegenüber C++ als Ideal dargestellt wird, tut einfach in der Seele weh.

[dot]

I feel you man...

[eXile]

Lulz des Tages: Windows 7 kann keine Fonts von einem Netzlaufwerk aus installieren. Es kommt keine Fehlermeldung, sondern es passiert einfach: Nichts.

[CodingCat]

Nur um sicherzugehen, dass ja niemand mehr kostenlos Windows-Desktop-Anwendungen entwickelt, wird das neue Windows SDK auch keinen Kommandozeilencompiler mehr enthalten. Und ich dachte schon, ich könnte vielleicht bei der VS 10 IDE bleiben.

[dot]

Ja, das ist in der Tat sehr traurig. Aber eben eine Marketingentscheidung um Metro zu pushen. Ich bin mir sicher dass sich das nach dem Release von Windows 8 wieder bessern wird...

[glassbear]

Jetzt bin ich von Stuttgart nach Kalifornien (San Diego) umgezogen für einen neuen Job und schon flattert mir von Google eine Email ins Haus, ob ich mich nicht bewerben will, mein CV gefällt ihnen so :?: :?: :?:

[Chromanoid]

Du Armer :)

[Krishty]

Verdammtes Visual C++ zeigt mir falsche Debug-Informationen in Release-Builds an. Jetzt muss ich zusehen, dass ich den Belastungstest irgendwie in der 20× langsameren Debug-Version wiederhole. Sind ja bloß ein paar Stunden. Super.

[eXile]

@pat_wilson @daniel_collin @twoscomplement geom shaders on OSX+AMD aren't weird, they very predictably always run on the CPU!

Sowas kann man sich nicht ausdenken.

[CodingCat]

Im Sumpf von undefined und implementation-defined behavior: Cast zwischen unverwandten Datentypen mit reinterpret_cast oder union?

Nach C-Standard wäre es union C { TypeA a; TypeB b; }; TypeB *b = &((C*)a)->b;. Im neuen C++-Standard wird diese Unterscheidung offensichtlich nicht gemacht, ich bin mir nicht Mal sicher, ob in C++ derlei nicht sogar immer undefiniertes Verhalten ist.

Da die meisten C++-Compiler auch irgendwie C-kompatibel sind, wäre man mit TypeB *b = &reinterpret_cast<C*>(a)->b; wohl auf der sicheren Seite. Tollerweise sind im aktuellen VC++ natürlich nach altem C++-Standard unions von Typen mit Konstruktoren noch nicht erlaubt, was mir letztlich nur ein direktes TypeB *b = reinterpret_cast<TypeB*>(a); lässt.

Oder sollte ich lieber zu albernen Doppelcasts wie TypeB *b = reinterpret_cast<TypeB*>( reinterpret_cast<char*>(a) ); übergehen? Der erste Cast wäre dann laut C++-Standard zwar erlaubt, der zweite isoliert ebenfalls, aber da der entstehende temporäre char-Zeiger tatsächlich weder auf ein Array von char-Objekten noch auf ein Array von TypeB-Objekten zeigt, ist die Kombination wohl ebenfalls verboten. Zumindest spricht der C++-Standard in der entsprechenden Regel immer vom Typ der Objekte, auf die gezeigt wird, und nicht vom Typ des aktuellen Zeigers auf dieselben.

Nachträgliche Anmerkung: Bezüglich erlaubt und verboten spreche ich natürlich immer von einer anschließenden Dereferenzierung des Zeigers mit dem neuen Typ.

[dot]

Cast zwischen unverwandten Datentypen mit reinterpret_cast oder union?

Die erste Frage sollte sein: Wieso überhaupt Cast zwischen unverwandten Typen? ;)

[CodingCat]

Ich glaube, diese Frage habe ich mir jetzt oft genug gestellt. ;) Ich sehe in diesem Fall keinen anderen Weg, Datenpolymorphismus zu kriegen. Letztlich handelt es sich um eine union, nur nicht um eine, die ich zentral definieren kann.

[dot]

Ich verwend dann üblicherweise einen einfachen reinterpret_cast. Denn es gibt afaik sowieso keinen Standardkonformen Weg das zu tun...

[CodingCat]

Naja, das nächste Ziel nach Standardkonformität wäre maximale Kompatibilität. gcc z.B. könnte wohl mit Strict Aliasing und einem einfachen reinterpret_cast Probleme machen. :-/

[dot]

gcc supported afaik offiziell den union Hack...

EDIT: Der portabelste Weg wäre vermutlich memcpy() über einen char Buffer, zumindest was Aliasing angeht...

[CodingCat]

Jap, gcc ist da C-konform. Ich habe es jetzt doch auf einen polymorphen "Basistyp" fester Größe reduzieren können, der einfach ein char-Array enthält. Damit dürfte ich über die Aggretationsregeln auch mit reinterpret_cast C++-standardkonform sein.

Und ja, memcpy geht wohl immer, aber in diesem Fall will ich gerade besonders performant bleiben, sonst würde ich einfach mit polymorphen Heap-Objekten arbeiten.