Jammer-Thread

[Chromanoid]

Ich weiß ich krieg gleich wieder auf die Mütze, aber mich würde wirklich mal interessieren, was C++ Freunde mal abgesehen von Java als Abhängigkeit und Groovy als Sprache von Gradle halten. Für Java läuft das Buildsystem schon echt gut und ich benutze es recht gerne. Vielleicht hat ja jemand mal Lust das ganze mit seinem Projekt auszuprobieren: http://www.gradle.org/docs/current/user ... aries.html

BTW das Gradle für C++ ist noch nicht produktionsreif, aber der generelle Gradle Ansatz gefällt mir. Vielleicht hat ja der ein oder andere Spaß dran, das ganze mal auszuprobieren.

Nur mal ein Nachtrag: Unity3D wird jetzt intern mit Gradle gebaut bzw. das Buildverfahren wird von Make auf Gradle umgestellt.

[Krishty]

Ich habe angefangen, in meiner Engine SIMD zu benutzen. Ich benutze SSE schon länger für Spezialfälle wie Conditional Move, schnelle Quadratwurzel, usw – aber immer nur eine Spur der Register für kleine serielle Dinge. Ich habe mich lange gesträubt, über vier floats gleichzeitig drüberzurutschen (vor allem aus Gründen der Lesbarkeit und Portierbarkeit); aber nun habe ich dennoch einen beherzten Versuch gewagt.

Tatsächlich messe ich 10 % Beschleunigung durch zwei Stellen in einer inneren Schleife, die nun mit drei floats parallel arbeiten (Vertex-Transformationen und Backface Culling). Die EXE ist um 0,5 % geschrumpft.

Das waren aber nur 20 Zeilen. Überall sonst ist der Effekt genau umgekehrt. SSE für Vektor-Normalisierung? Langsamer als seriell und 1 % größeres Programm. SSE für Kreuzprodukt? Bricht total ein. Ich habe eben drei Stunden vor einer SSE-Matrixmultiplikation verbracht, und sie erreicht gerade mal die Leistung der seriellen Variante. Alle vorherigen Versuche gingen total nach hinten los.

Die Katastrophe war dann, alle Vektorberechnungen auf Multimedia-Register umzustellen. Ich habe mich zwei Stunden lang durch Maschinenbefehle gewühlt, und letztendlich war trotzdem alles langsamer auf fetter. Dir Rückgabe ist die Pest; Visual C++ verschüttet die Rückgabewerte dauernd auf den Stapelspeicher. Zwar werden die Register drei Mal so effizient ausgenutzt (habe leider nur X, Y, & Z), aber dafür bewirkt das Shuffling dermaßen viele temporäre Werte, dass der Registerdruck dennoch steigt. Irre. Da weiß man sofort, warum andere Befehlssätze hunderte Register haben.

Außer 20 Zeilen für zwei Hotspots ist das also total für die Katz’. ryg hat’s ja gesagt.

Mit SSE3/4 könnte das anders sein, aber die Erfahrungsberichte lesen sich nicht sehr euphorisch. Mit AVX sinkt der Overhead von Shuffling und horizontalen Summen beträchtlich, und allein durch die Befehlskodierung kann man schon mit Leistungsverbesserungen rechen. Aber da kann ich nochmal 15 Jahre warten, bis das jeder Anwender unterstützt. Bah.

[dot]

Dir Rückgabe ist die Pest; Visual C++ verschüttet die Rückgabewerte dauernd auf den Stapelspeicher. Zwar werden die Register drei Mal so effizient ausgenutzt (habe leider nur X, Y, & Z), aber dafür bewirkt das Shuffling dermaßen viele temporäre Werte, dass der Registerdruck dennoch steigt. Irre. Da weiß man sofort, warum andere Befehlssätze hunderte Register haben.

Auch mit __vectorcall?

[DerAlbi]

Also ich finde das auch merkwürdig. Wenn man überlegt, dass z.B. ein I7 bis zu 29 Instruktionen pro Takt schafft (kA, ob das für alle cores gilt, oder für einen o_O Ist egal. Selbst wenn man das durch 8 teilst isses doch =4). Wenn man wirklich mit der vorhanden Rechenleistung datenverarbeitung betriebt und rechnet KANN man doch gar nicht schneller sein. Man ist doch unweigerlich speicherbandbreiten begrenzt, oder? Sequenzielle daten mögen gerade noch gehen.. aber wenn man ü erlegt wie arschlahm RAM eigentlich ist... gerade bei Adresswechsel. paah.
Ich glaube, dass SIMD was bringt hängt extrem vom Datenlayout ab. Ich persönlich habe mega gute erfahrungen auf einer Platform gemacht, die nativ 32bit hat und wo SIMD dann auf 4x 8bit angewendet worden ist. Damit konnte man zumindest farbvektoren im Software-3D Renderer wesentlich besser verarbeiten oder 64bit-Vektoren, wenn diese auf 4x 16Bit Fixpoint basieren. Pro texturierten Pixel hatte ich nur noch 17 Takte benötigt. (RISC)
Aber da war von vorn herein auch alles darauf ausgelegt parallelisiert zu werden. Datenlayout ist da halt wichtig. wenn man Anfängt aufnicht-ausgerichteten adressen zu arbeiten oder die floats erst zusammensucht, um sie parallel zu verarbeiten... näääh geht nich. Aber gut. Als RISC-Mensch... bei mir ist das alles deterministischer :-D

[Krishty]

Dir Rückgabe ist die Pest; Visual C++ verschüttet die Rückgabewerte dauernd auf den Stapelspeicher. Zwar werden die Register drei Mal so effizient ausgenutzt (habe leider nur X, Y, & Z), aber dafür bewirkt das Shuffling dermaßen viele temporäre Werte, dass der Registerdruck dennoch steigt. Irre. Da weiß man sofort, warum andere Befehlssätze hunderte Register haben.

Auch mit __vectorcall?

Habe ich garnicht erst versucht, weil sich das vor allem auf sowieso geinlinete Funktionen bezog. Es findet kein Funktionsaufruf mehr statt, aber trotzdem sind da sechs movaps zum und vom Stapel. WTF.

Aber da war von vorn herein auch alles darauf ausgelegt parallelisiert zu werden. Datenlayout ist da halt wichtig. wenn man Anfängt aufnicht-ausgerichteten adressen zu arbeiten oder die floats erst zusammensucht, um sie parallel zu verarbeiten... näääh geht nich. Aber gut. Als RISC-Mensch... bei mir ist das alles deterministischer :-D

Auf das Layout habe ich quasi keinen Einfluss mehr, das ist verlorener Posten. War halt nicht mein Design :( Und ein Neu-Design lohnt sich erst, wenn Visual C++ irgendwann mal Address Of Label implementiert.

Ich habe hier eine Stelle, wo ich die Größe des Arbeitssatzes (also RAM-Durchsatz) gegen Layout abwägen muss: Ein Batzen Vertices liegt in 16-Bit-shorts vor. SSE 2 kriegt es um’s Verderben nicht auf die Kette, die effizient zu float zu konvertieren. Alles, was mit 16-Bit-Zahlen zu tun hat, läuft nur noch über die MMX-Register, die in x64 sowieso nicht mehr ansprechbar sind. Vier ints zu vier floats konvertieren? Als ob – den Befehl gibt es nur als skalar oder als 2er-Vektor (!). Ach die schönen Legacy-Befehle. Und wenn ich alles mit 32-Bit-ints aufziehe, pumpe ich in der innersten Schleife doppelt so viele Daten durch die CPU. Ganz zu schweigen davon, dass ich dann immernoch zwei Loads pro Element brauche, weil es ja keine 96-Bit-Operationen gibt. WTF. Als ich anfing, zwei 16-Bit-Zahlen im 64-Bit-Allzweckregister aufzupusten um das durch den Speicher in zwei floats der SIMD-Einheiten zu aliasen, habe ich hingeschmissen, weil der Scheiß ja Endian-abhängig ist und ich die Stelle niemals wieder finde wenn ich mal für ARM kompiliere. Bah. Und über die Umwege wär’s dann sowieso lahmer gewesen als drei skalare Konvertierungen, die zwar hintereinander laufen, aber zumindest direkt durch Register, mit Daten, die halb so viel RAM schlucken.

[DerAlbi]

Tjaaah wer floaten will muss loaden ^_^
Ich weiß noch nicht ganz wieso das aufpusten auf die doppelte größe ein so großes gegenargument ist. Wichtig ist, dass man das nur während der cpu-internen arbeiten macht, das lesen und rausschreiben wird davon beeinflusst... aber wenn man eh 64bit register hat... man schleppt die bits in der Pipeline ja eh ungenutzt mit rum. der cache ist auch mindestens so breit angeschlossen. letztlich hat es doch schon fast weniger sinn, auf weniger als 64bit zu arbeiten, oder? Also aufpusten, lokal in der pipeline/cache rechnen, schrumpfen, zurückschreiben.
Sry, nicht dass ich da tieferes wissen habe. Lass mich doch naiv daherlabern :-)
btw: _mm_cvtpi32x2_ps

[Krishty]

Na wegen der, wie du selber gesagt hast, Speicherbandbreite. Alles doppelt so groß machen bedeutet auch die doppelte Belastung auf dem RAM-Bus, wenn man die Dinger verarbeitet, und effektiv halb so viel Cache. Und das limitiert ja eh immer.

Bzgl _mm_cvtpi32x2_ps: Das ist nichts weiter als der doppelte Aufruf des Intrinsics. Die Parametertypen, __m64, sind auf x64 zwar deklariert, aber nicht als Registertypen verwendbar. Was auch immer ich übergebe, muss also erstmal auf den Stack geschrieben werden und von dort lädt es das Intrinsic. Ich habe also die Wahl zwischen (Pseudo-Assembler):

  MOV EAX, WORD PTR [foo.x]
  MOV EBX, WORD PTR [foo.y]
  MOV ECX, WORD PTR [foo.z]
  MOVD XMM0, EAX
  MOVD XMM1, EBX
  MOVD XMM2, ECX
  CVTSI2SS XMM0, XMM0
  CVTSI2SS XMM1, XMM1
  CVTSI2SS XMM2, XMM2

was seriell ist, aber dafür direkt über die Register rutscht, oder via _mm_cvtpi32x2_ps

  MOV EAX, WORD PTR [foo.x]
  MOV EBX, WORD PTR [foo.y]
  MOV ECX, WORD PTR [foo.z]
  SHL RAX, 32 ; X und Y in einem Register kombinieren
  OR RAX, RBX
  MOV QWORD PTR [localInt64], RAX ; Einen 128-Bit-Speicherbereich mit X, Y, und Z in 32-Bit-Form anlegen
  MOV QWORD PTR [localInt64+8], RCX
  CVTPI322PS XMM0, XMMWORD PTR [localInt64]
  CVTPI322PS XMM1, XMMWORD PTR [localInt64+8]
  SHUFPS XMM0, XMM1, 0beidezusammenH

was trotz Parallelisierung die Konvertierungen von drei nur auf zwei drückt und dabei einen Umweg über den Speicher macht.

[Schrompf]

Aber Danke für den Link zu ryg - ich habe da gerade eine Stunde mit eskalierender Geek-Neugier verbracht und mich durch seinen Blog geblättert.

[Krishty]

Durch seine Webseite, die ich verlinkt habe, oder wirklich durch seinen Wordpress-Blog?

Er war damals einer der Programmierer hinter .kkrieger, dem 96-KiB-Ego-Shooter. Heute arbeitet er bei RAD, zusammen mit cbloom, dessen Blog mich ein halbes Jahr ausgelastet hat.

[Schrompf]

Beides :-) Aber Danke nochmal für cbloom. Der ist mir vor langer Zeit schon mehrfach im Netz begegnet, und jetzt hab ich mich wieder festgelesen. Wobei ich rygs Philosphierereien zu Prozessorarchitektur spannender finde.

[Jonathan]

Ach Qt und Initialisierung von Objekten. Es ist soo grausam.

Ich benutze den Designer, um das GUI zu erstellen. Der hat die praktische Funktion "promote Widget" mit dem man auch eigene Widgets im Designer benutzen kann. Soweit so toll.

Jetzt habe ich ein Widget, dass mit OpenGL ein bisschen was rendern soll. Dazu speichert es unter anderem einige Infos über die Szene, sowie OpenGL Ressourcen. Und spätestens jetzt fängt der Spaß an. Wo initialisiert man das am besten? Das Widget soll die Szene ja nur anzeigen, also wir sie von außen definiert. Jetzt kann ich aber kein RAII benutzen, d.h. die Szene als Konstruktorparameter übergeben, weil Qt ja seinen eigenen Präprozessor (MOCing) hat und den Code generiert - Konstruktorparameter sind unmöglich.
Man könnte jetzt meinen, das sei nicht so schlimm, man kann ja im Hauptfenster erst setupUi() aufrufen (das den generierten Code zur GUI-Erstellung ausführt) und dann nochmal eine Initialisierungsfunktion. Aber das geht nicht, weil sowas wie Vertex-Buffer ja ein initialisiertes OpenGL voraussetzen. Und OpenGL wird in Qt erst irgendwann nach dem Erstellen initialisiert, und zwar erst nach sämtlichen Konstruktoren, man wird es irgendwann per Event darüber informiert, dass man es ab jetzt benutzen kann. Ich darf also im Konstruktor der Hauptklasse noch nichts erstellen, ich könnte höchstens Werte durchreichen, die das OpenGL Widget zwischenspeichert und benutzt sobald der Kontext erstellt ist. Ich habe dann auch teilweise einfach ein Callback erstellt, damit das Hauptfenster Code ausführen kann, sobald OpenGL im entsprechenden Widget initialisiert ist.
Und im Moment will ich einen Vertexbuffer mit passenden Daten füllen. Diese soll man beim Erstellen setzen können, aber auch hinterher wieder ändern können. Aber beim Erstellen gibt es den Kontext vielleicht noch gar nicht, daher kann ich höchstens die Parameter zwischenspeichern. Wenn ich aber später die Werte nochmal ändern will, muss ich den Vertexbuffer ja direkt verändern (weil kein weiteres 'initialisiert'-Event kommen wird), ich brauche also entweder eine Abfrage, ob OpenGL schon initialisiert ist, oder muss zwei verschiedene Funktionen anbieten, die man dann jeweils nur beim Initialisieren oder Ändern aufrufen darf.

Letztendlich führt es also dazu, dass man die Klassen sehr viel umständlicher und unübersichtlicher programmieren muss, nur weil Qt irgendeine bescheuerte Initialisierung erzwingt. Nichts das irgendetwas davon sonderlich schwer umzusetzen wäre, aber ich hasse es, wenn ich nicht selber daran schuld bin, wenn mein Code hässlich ist...

[Jonathan]

glm ist ein exakter Nachbau der glsl Matheklassen. Das ist super. Aber soweit ich das sehe gilt:

Der mat4 Konstruktor in glsl ist Column-Major, der mat4 Konstruktor ist Row-Major.

meh, warum??

Ist ne Lüge, siehe unten.

[dot]

[...] der mat4 Konstruktor ist Row-Major.

Das wäre mir neu... ;)

[Jonathan]

Jup, habe mir das eben nochmal genauer angesehen und es ist in der Tat Column-Major. Ich war nur verwirrt, weil ich dachte, die Matrix müsste anders aussehen und es müsste Row-Major sein, damit es so funktionieren kann. Glück gehabt :)

[dot]

glm ist dennoch imo ziemlicher Mist, allein dass ich tatsächlich immer voll-qualifizierte Funktionsnamen benutzen muss weil es kein ADL supported...passt also schon in den Jammer Thread... :P

[Schrompf]

Öhm.... vielleicht hab ich da ja was verkackt, aber bei mir war in GLSL der mat4-Konstruktor aus 16 float wirklich row major, während die Standard-Storage column_major war.

[dot]

Kanns sein, dass du Vektor * Matrix rechnest statt umgekehrt? Dann kommst du mit der so verkehrten Matrix nämlich zum richtigen Ergebnis... ;)

[marcgfx]

ist mal wieder typisch, da benutzt man ein richtig geiles neues feature in der webaudio api und was sehe ich heute per zufall in der console: deprecated. nachgekuckt und irgendwie hat irgendwer gefunden das ding sei nicht gut. reg mich grad tierisch auf.
https://groups.google.com/a/chromium.or ... 1SI1GoHYO8

[Jonathan]

Die Summe aller natürlichen Zahlen ist -1/12 ...

[Artificial Mind]

Die Summe aller natürlichen Zahlen ist -1/12 ...

http://en.wikipedia.org/wiki/1_%2B_2_%2 ... _%E2%8B%AF
Und ich bevorzuge die Formulierung "man kann der divergenten Summe der natürlichen Zahlen die Zahl -1/12 zuweisen und dadurch einige interessante Resultate erzielen".

[Krishty]

Immer die Return Codes prüfen. Habe ein zwei Jahre altes Memory Leak beim Kopieren des Back Buffers gefunden, weil ich UnlockRect() auf dem falschen Surface durchgeführt habe -.-

[Jonathan]

std::ios::binary vergessen. Jedesmal. JEDESMAL!

[Krishty]

Ach, all die Windows-APIs … ich freue mich schon drauf, das eines Tages alles auf Java zu portieren.

WinAPIs.png (4.23 KiB) 7860 mal betrachtet

So sehr ich auch Abwärtskompatibilität verteidige, so sehr bin ich Feind davon, jedes Jahr eine neue API für den selben Scheiß rauszubringen. … und nur um ein Dreieck auf den Bildschirm zu kriegen muss man von COM bis GDI alles einbinden -.-

[Chromanoid]

Ich liebe geek & poke. Die Comics sprechen einem manchmal echt aus der Seele :) Hier mal meine Lieblinge der letzten Zeit:

[Krishty]

Ich dachte, das seit einigen Jahren hinter mir gelassen zu haben, aber … Visual C++ 2012 unterscheidet bei float noch immer zwischen pass-by-ref und pass-by-value. In der Größenordnung von einem Drittel mehr Memory Roundtrips in float-lastigen Funktionen. Schreibt für eure Mathe besser keine Templates, die ihre supergenerischen Parameter via T const & nehmen.

Ich hatte das vor einigen Jahren mal getestet, weil Visual C++ 2010 lächerlich schlimm drunter litt, und da sah es gut aus. War wohl zu synthetisch. Bestimmt ist da wieder ein Fehler, dass bei einer bestimmten Anzahl lokaler floats, die nicht als Parameter kommen, und deren Name mit q beginnt, bei der Anwesenheit eines SSE-Befehls im rechts-rechts-linken Unterzweig des Syntaxbaums alles auf den Stapel geklatscht wird, falls eine Überladung der Funktion zwei Zeilen weiter oben eine Referenz erwartet.

[Krishty]

long ist der nutzloseste Datentyp evar.

[Schrompf]

Und trotzdem gefährlich, weil auf GCC 64bit mit 64bit-Architekturen, auf Visual C++ nur 32bit auf allen Architekturen. Eine der Freuden, wenn man eine Programmiersprache nutzt, die nun schon 30+ Jahre auf dem Buckel hat. Wobei long wohl noch aus C-Zeiten stammt, also nochmal 10 Jahre älter ist.

[Top-OR]

Da kommt hier schon wieder einer ins Forum, registriert sich und "sucht" mit dem ersten Post nen Grafiker für das X-te NICHT beschriebene Luftschloss-Projekt und sagt NIX drüber (ich habe Furzgeräusche gehört, die mehr Informationsgehalt haben) und ich kann nichtmal ne kodderige Gegenfrage druntersetzen, weil der Thread gesperrt ist.

Mimimimimimimi... Ich will jammern!

Leute, wenn das Projekt Fleisch auf den Knochen hat und kein Luftschloss ist, dann ZEIGT doch auch was, wenn ihr Leute wollt, die sich da engagieren wollen sollen.
Ohne zu wissen, worums geht, rennt doch da keiner (bzw. die wenigsten) los...

[Spiele Programmierer]

Ich bin ein Freund von size_t, int32_t, int64_t und Konsorten.
Das Spart den "long" und co. Ärger für alle von Anfang an. (In exotischen System kommen durchaus noch andere Konstellationen vor)

[Schrompf]

Da kommt hier schon wieder einer ins Forum, registriert sich und "sucht" mit dem ersten Post nen Grafiker für das X-te NICHT beschriebene Luftschloss-Projekt und sagt NIX drüber (ich habe Furzgeräusche gehört, die mehr Informationsgehalt haben) und ich kann nichtmal ne kodderige Gegenfrage druntersetzen, weil der Thread gesperrt ist.

Jo, der ist dieses Mal besonders dreist. Nichtmal die eigene Webseite verraten wollen, aber nur "Bewerbungen" mit "Link auf Portfolio" akzeptieren. Aber nuja, es sind ja gar keine Links drin. Deswegen können wir das Ding einfach dem wohlverdienten Tod durch Desinteresse überlassen.