ZFX + Developia

Vielleicht kannst Du ja sonst Aliase pro Datei definieren. Keine Ahnung ob das eine gute Idee ist. So ähnlich läuft das ja manchmal bei Namensräumen usw.

BTW keine Ahnung was da mit der URL in Deinem Post los ist.

BTW keine Ahnung was da mit der URL in Deinem Post los ist.

Die enthält einen Umlaut. Löscht man den, geht, es. Ich wollte, dass ihr es seht ;)

————

Ich habe früher schon geschrieben, dass ich meinen Vektoren und Matrizen zwei Layouts verpasst habe – einmal für langfristige Speicherung (z.B. drei floats für X/Y/Z); und einmal für Rechnen/Parameterübergabe/temporäre Werte (z.B. __m128 für direktes Mapping zu SIMD-Register); mit load() und store()-Funktionen, die dazwischen konvertieren. Und dass das die einzige Variante ist, die mein Programm verschnellert hat (nur SIMD verlangsamt weil die Caches mit Padding verschmutzt werden; nur skalar verlangsamt weil man ALU wegschmeißt).

Irgendwann habe ich auch meine Farben darauf umgestellt (drei Bytes für R/G/B im Speicher gegenüber einem int32 im Register – wobei Compiler das teils automatisch machen, aber recht ineffizient).

Jetzt spare ich hier und da ein paar Takte und Bytes durch die Nutzung von int_least16_t bzw. int_fast16_t. Und da dämmert mir: Auch da muss man das eigentlich so machen – eine Klasse für Integer im Speicher; eine für Integer im Register (oder auf dem Stack); Funktionen, um dazwischen zu konvertieren. Das würde viele Fliegen mit einer Klappe schlagen:

1. Das Leistungsproblem, offensichtlich
2. dass man uint16_t nicht einfach durch uint_fast16_t ersetzen kann ohne das Programm zu zerstören
   • denn man kann dann nicht mehr vorhersagen, ob die Variable zu int oder unsigned int promoviert
   • also gehen schlimmstenfalls alle Überladungen im Programm kaputt
   • Klassen promovieren nicht (die chillen nur) – Problem gelöst!
3. das furchtbare Gefrickel mit Endianness bei Dateiformaten
   • deklariere Little-Endian-Dateistrukturen mit int_le32_t
   • die korrekte Überladung von load() und store() konvertiert automatisch
   • dazwischen rechnet man mit höchster Effizienz

… aber dann ist der Code sicher so voll von load() und store(), dass sich die Entwickler wie Assembler-Programmierer fühlen.

Amigas AIFF-Soundfiles haben eine 80-bit long double im Header. Kein moderner Compiler nutzt mehr long double auf x86-64 …

Kunden fragen, warum Asset-Export zu STL so quälend langsam ist. Krishty schmeißt den Profiler an. Krishty sieht die Visual C++-CRT, und nichts anderes.

Über 80 % der Ausführungszeit werden in _stdio_common_vsprintf() verbracht. Um pro Vertex drei floats auszugeben (keine besonders großen, kleinen, langen, oder krummen Werte). Tatsächlich kann meine alte magnetische Gammelfestplatte die Daten fünf Mal so schnell speichern, wie sprintf() sie erzeugt.

Und mit was hast du die Funktion jetzt ersetzt?

Wir gucken gerade, ob wir auf die Binärversion des Formats ausweichen können, damit das Problem erst garnicht entsteht.

Mein letzter Kenntnisstand ist, das schicke Dinge wie Streams einen gewissen Overhead haben und die guten alten, unsicheren C-Funktionen in Sachen Performance quasi ideal sind. Und wenn man bedenkt, dass man beim Exportieren ja auch wirklich jede zahl am Ende in der Datei haben möchte, würde das bedeuten, dass der Export im Grunde genommen eine optimale Laufzeit hat und quasi nicht mehr optimiert werden kann. Was dann wirklich ein nettes Ergebnis wäre.
Verbessern könnte man es dann überhaupt nur noch dann, wenn man etwas fundamental anders macht, wie das angesprochene Verzichten auf Textdateien.

Jonathan hat geschrieben:Mein letzter Kenntnisstand ist, das schicke Dinge wie Streams einen gewissen Overhead haben und die guten alten, unsicheren C-Funktionen in Sachen Performance quasi ideal sind.

Die benutze ich bereits, und wenn 50 % der Ausführungszeit in _iswalpha() verbracht werden, ist das vielleicht doch nicht so pralle implementiert :(

Verbessern könnte man es dann überhaupt nur noch dann, wenn man etwas fundamental anders macht, wie das angesprochene Verzichten auf Textdateien.

Bin gerade unterwegs, aber wenn ich zurück bin baue ich einfach mal ein, dass die float-Koordinaten auf Integer hochskaliert werden und ich schreibe die Integer weg. Mein Gefühl sagt mir, dass das schon deutlich schneller sein wird.

Ja, mit 'C-Funktionen' meinte ich schon das vsprintf.
Rein aus Interesse: Um was für Datenmengen und Zeitanforderungen geht es denn hier? Hätte nicht gedacht, dass Text-Formatieren mal zu so einem Problem werden kann.

Um einen Gigabyte Text geht es ungefähr, und wenn ich mich recht erinnere, war er in knapp zwei Minuten geschrieben. Dass meine Festplatte das fünf Mal so schnell kann, war wohl übertrieben -- bei 25 MiB/s sollten es 40 Sekunden sein -- aber bei meinem Kollegen mit modernem Core i7 und SSD dauerte es immernoch gut 30 Sekunden; das ist einfach nicht zumutbar.

CMake ist case-insensitive. Außer wenn es gerade mal nicht case-insensitive ist.
Aber das macht den Braten jetzt auch nicht mehr fett...

Statt selber nur zu meckern, zitiere ich jetzt einfach mal:

targets are everything in CMake. Unfortunately, not everything is a target though!

If you’ve tried do anything non-trivial in CMake

got stuck in this horrible swamp of confusion

all sorts of exciting limitations to make you forget everything you ever new about dependency management.

What makes it so hard is that there’s not one limitation, but several.

You may live to regret ever letting it in.

I found all of this quite difficult to work out

there is plenty of room for improvement

One can notice your frustration with cmake

Eine schöne Zusammenstellung. Ich bau aktuell mit QMake auf Linux und OSX und MSVC auf Windows. Alles doppelt machen, auch irgendwie doof.

Einen guten hab ich noch übersehen :D

How does this work? Actually it doesn’t!

Gollum hat geschrieben:It’s a shame for mankind, that a language like C++ ended up with CMake as its most popular build tool…

QFT

Was ich wirklich vermisse, ist ein std::sort, das zwei Arrays parallel sortiert, indem es die Werte nur aus dem ersten vergleicht. Ohne kann man einfach keine effizienten Lookup-Tabellen entwickeln. Im Augenblick muss ich mir helfen mit

  std::vector<std::pair<Key, Value>> temp_keysAndValues;
  // merge the arrays here
  std::sort(temp_keysAndValues);
  std::vector<Key> keys;
  std::vector<Value> values;
  keys.reserve(temp_keysAndValues.size());
  values.reserve(temp_keysAndValues.size());
  for(auto & kv : temp_keysAndValues) {
    keys.push_back(kv.first);
    values.push_back(kv.second);
  }
  std::vector<std::pair<Key, Value>>().swap(temp_keysAndValues);

Sollte ein Einzeiler sein. Wer sollte denn auch je was anderes wollen?

Krishty hat geschrieben:Was ich wirklich vermisse, ist ein std::sort, das zwei Arrays parallel sortiert, indem es die Werte nur aus dem ersten vergleicht.

Sollte sich eigentlich recht einfach realisieren lassen, musst ja nur einen entsprechenden Iterator Type definieren... ;)

Stimmt; deutlich einfacher :)

Oder warte mal. sort() funktioniert ja im Kern über swap(*it1, *it2). Wie überlade ich denn dann den Deref-Operator meines neuen Iterators? Der müsste ja beide Werte zurückgeben (was nicht geht), also müsste eine Proxy-Klasse aus zwei Referenzen her, für die swap() überladen wird, beide Werte zu swappen, oder?

Streich das – der Kern ist it1->swap(*it2) (standardisiert als ValueSwappable). Das kann ich tatsächlich einfach im Iterator definieren.

Und ansonsten könnte der unäre operator* ein proxy Objekt returnen, das das dann alles richtig macht. Das wär natürlich dann nimmer so einfach, aber gehen sollt's... ;)

Ich hatte für meine Voxel-Experimente OpenVDB genutzt. Großes Ding; Open Source; Dreamworks nutzen es für ihre Filme (Wolken, Wasser, zerberstende Felsen, etc.).

Falls ihr ebenfalls drüber nachdenkt, hier meine Meinung: Man kann es nur zum Experimentieren nutzen. Für alles, was man mal anderen Leuten zeigen will, nimmt man was anderes.

Setup:

• Abhängigkeiten ohne Ende. Z.B. LucasArts’ Framework, nur weil das Laden & Speichern (das ich nirgends nutze) den half-Datentyp erfordert.
• Eine Abhängigkeit ist Intels Threading-Bibliothek (Kommentar zu Threading weiter unten), die untrennbar mit OpenVDB verwurschtelt ist und für die es keine Visual C++ 2015-kompatiblen Builds zu saugen gibt. VS 2013 muss installiert sein.
• OpenVDB ist total Cross-Platform, aber Visual C++ wird nicht offiziell unterstützt. Hier muss man lobend erwähnen, dass die Versionen 3.0 und 3.1.0 nach einer Handvoll Anpassungen wirklich ihren Dienst verrichten.
• Boost. Überall.
• Am Ende hatte ich ein Repository mit über 20.000 Quelldateien, bevor ich auch nur auf „Build” klicken konnte.

Kompilieren:

• Schmeißt mit Visual C++ auf mittlerer Warnstufe um die 1200 Warnungen. Da alles auf Templates basiert, werden die bei jeder kleinen Änderung (auch am Client!) erneut angezeigt. Eure eigenen Warnungen findet ihr nie mehr.
• Dauert auf meiner zugegebenermaßen alten Kiste um die acht Minuten. Da alles auf Templates basiert, fallen die bei jeder kleinen Änderung (auch am Client!) erneut an.

Umfang:

• Hier gibt’s nichts zu meckern. Man bekommt alles, was man sich vorstellen kann – von Triangulierung bis Flüssigkeitssimulation. Für mich am wichtigsten: Konvertierung Dreiecksmesh -> Voxel und zurück.

Das Jammern beginnt bei der Qualität:

• Der Speicherverbrauch ist immens. Wenn ich auf dem Papier ausrechne, wie viel Speicher ich für eine Szene brauche, muss ich das mit 10 multiplizieren um an OpenVDBs Speicherverbrauch zu kommen. Es ist echt unglaublich; ich musste in den letzten Wochen dutzende Male den Strom abdrehen weil mein Rechner nicht mehr aus dem Thrashen kam.
• Der Aufbau ist typischer OOP-Bullshit mit „Reusable!“-Garnierung. Tausende Instanzen std::map in innersten Schleifen. Mikroallokationen und Overhead überall.
• Entsprechend effizient ist das Ganze. Sie haben versucht, es glattzubügeln, indem sie wild parallelisieren. Der Code sieht nicht für Multithreading ausgelegt aus; viel mehr scheint jemand blind jede for-Schleife durch ein tbb::parallel_for ersetzt zu haben.
• Der Code ist nur an trivialen Stellen kommentiert. Alles, wo tatsächlich wichtige Sachen berechnet werden, ist unkommentiert. Wenn man irgendwo was ändern will, kann man das ohne zwei Wochen Einarbeitungszeit vergessen.
• Die Algorithmen haben subtile Fehler.

Anfangs lief alles ganz gut. Das Dilemma begann, als ich ganz kleine Berechnungsfehler bekommen habe – allerdings nur in Szenen mit 100 Millionen Voxeln aufwärts.

• Sie waren maschinenübergreifend reproduzierbar, es lag also nicht an meiner Maschine oder an Race Conditions.
• Sie traten in Debug- und Release-Versionen auf, mit Speicherdiagnostik wie ohne. Da waren also keine kaputten Zeiger.
• Die Fehler waren nicht reduzierbar. Mit kleineren Datenmengen traten sie partout nicht mehr auf.

Also … Debugging. Habe mir den Inhalt des Voxel Grids in Dateien dumpen lassen.

• OpenVDB stellt extra eine Palette (ich nenne es „Shitload“) von Iteratoren bereit, die den Zugriff auf Voxel beschleunigen sollen, indem sie z.B. Baumtraversierungen cachen. Diese Iteratoren haben alle mindestens drei Template-Parameter (einer davon rekursiv), zwei Basisklassen, und 2000 Zeilen Code. Und sie waren konsequent eine Größenordnung langsamer als direkter Zugriff auf die Rohdaten des Baums. Aber bestimmt habe ich sie falsch verwendet. Jedenfalls waren sie zumindest kommentiert.

Es wurde relativ schnell klar, dass bei der Einordnung in Innen- und Außenbereiche was schiefgeht. Also habe ich in den Code geschaut.

• Die hunderten Zeilen Code, die das betreffen, waren nicht kommentiert. Sie steckten alle in Template-Klassen, die der Intel-Bibliothek als eine Art Lambda übergeben werden, die dann rekursiv anfallende Arbeit auf mehrere Threads verteilt. „Rekursiv“ bedeutet, dass ein Thread auch neue Threads erzeugt, während er gerade Aufgaben verarbeitet. Die Call Stacks waren um die 40 Aufrufe tief (25 davon Smart-Pointer-Operator-Overhead) und Haltepunkte quasi nutzlos.

Weil ich bis heute nicht verstanden habe, was bestimmte Arrays tun, habe ich die Taktik verändert und versucht, zumindest OpenVDBs Ergebnisse mit eigenem Code zu reproduzieren, auch ohne deren Code zu verstehen.

• Ich habe schnell festgestellt, dass sich deren Distance Grid nicht durch einfache Programme beschreiben lässt. Sie sollten etwa *theoretisch* alles bis zu einer bestimmten Distanz vom nächsten Dreieck voxelisieren („Bandbreite“); weil der Algorithmus aber nicht linear durch Voxel geht, sondern in einer Art Clustering an bereits voxelisierte Punkte ansetzt *bevor* er die Distanz berechnet … ach was soll’s: Meine Ergebnisse waren subtil anders und ich bin mir sicher, dass sie auch subtil *richtiger* waren.

Ich habe aber auch einige ganz besondere Juwelen entschlüsselt:

• Wenn sie alle Blattknoten ihres Voxel-Baums abrollen, casten sie das const des Baums weg, speichern alle X-Koordinaten in einem neuen Array; ersetzen sie durch Indizes in ihre interne Liste; rollen ab; setzen die Originalkoordinaten wieder ein; casten das const wieder dran. Offenbar war eine std::map als Lookup dieses Mal zu langweilig.

Ich habe also die letzten zwei Wochen damit verbracht, die wichtigsten Algorithmen selber zu implementieren (Voxeln, weil’s die meiste Zeit frisst; und Flood Fill (Innen- und Außenermittlung), weil’s kaputt war).

• Mein Voxeln war in zwei Threads bereits so schnell wie ihres in acht. Das ist aber auch ein schlechtes Beispiel, weil ich SSE nutze und mein Code nicht unbedingt besser aussieht als ihrer. (Wobei SSE hier nicht einmal doppelte Leistung bringt, weil man aus Genauigkeitsgründen mit double rechnen muss.)
• Mein eigenes Flood Fill (single-threaded) ist so schnell wie ihres (acht Threads), und verbraucht dabei weniger als halb so viel RAM.

Insgesamt bin ich bei einem Viertel des OpenVDB-Verbrauchs – ich als Amateur kann jetzt in gleicher Zeit doppelt so hohe Auflösungen samplen! War wohl nicht so clever von ihnen, den Baum in eine doppelt verkettete dreidimensionale Liste abzurollen. Aber dafür konnten sie mal schlecht nachmachen, was sie in einem Vortrag über „datenorientert“ gesehen haben (alle Dimensionen in einen Gigabyte-großen std::vector stopfen).

Zur gleichen Zeit ist übrigens ihr neuer Release Candidate fertig geworden. Ich habe ihn ausprobiert, und … nichts geht mehr. Kann daran liegen, dass Visual C++ halt nicht offiziell unterstützt ist … aber trotzdem … WTF?! Von einer Version auf die andere habe ich nur noch Schrott in meinem Grid?! Also für Windows-User: Finger weg von 3.2.0.

Ich hätte ja jetzt gern voll toll meine Verbesserungen ins Projekt eingebracht und so, aber … meine Verbesserung ist „wegschmeißen und neu machen“. Das werde ich jetzt auch mit dem Rest tun. Die Baumstruktur werde ich zuletzt ersetzen; davon erhoffe ich mir nochmal zweistellige Prozentgewinne.

Das einzige, womit sie sich noch retten können, ist: Meine Datensätze sind zu klein. Ein paar Gigabyte voxeln, das machen ja sogar aktuelle PC-Spiele. Falls das Ganze für Hollywood-Datensätze von hunderten Gigabyte ausgelegt ist, kann es ja sehr wohl sein, dass mein Code da verkacken würde. Aber für alle, die sich hier im Forum tummeln: Gebt Acht, worauf ihr euch einlasst. Als schneller Fick ganz gut, aber bloß keinen Ring anstecken!

Wichtiges Update AM ARSCH. Banditen elende!

https://support.microsoft.com/de-de/kb/3035583

Das dürfte das üble Mogelding sein wo du mit einem Klick auf den Close Button oben rechts zustimmst und es lustig die Installation beginnt ...

http://www.forbes.com/sites/gordonkelly ... b4317e78b0

Ich mache drei Kreuze wenn die verdammte Aktion mit dem kostenlosen Update endlich rum ist! Ich werd mir mein Win 7 Produktivsystem ganz sicher nich mit nem Windows 10 Update zertrümmern lassen. Die drei Tage Lappygebastel damals haben mir vollkommen gelangt.

While at jammern. Da hatt ich endlich mal wieder Bock und Inspiration nen Song zu schreiben. Und habe nun stattdessen eine Woche mit meiner Musiksoftware rumgeclincht um nach dem Umstieg auf die neueste Version wieder alles zum Laufen zu kriegen. Und nun is die Inspiration wieder weg

Ich war vorgestern (wunderschöner sonniger Tag) in der Bahn und Wasser rieselte aus den Wänden. Nicht aus den Poren, sondern aus den Spalten zwischen den Plastikteilen. Konstante kleine Rinnsäle, direkt aus der Wand und aus der Decke. Haben dann leise geplätschert und in Kurven auch gespritzt. Acht Menschen standen an die Wände gelehnt. Die Tropfen flossen an ihrer Kleidung hinunter; das Wasser ronn über ihre Koffer; der Boden war voller Pfützen, die in den Kurven hin- und herschwappten – aber die Menschen standen wie Statuen drunter und starrten ins Nichts.

Ich habe die Sprechanlage betätigt, um dem Lokführer bescheid zu sagen, aber es kam keine Antwort. Als ich ausstieg, sah er mir in die Augen. Ein abgewrackter Typ mit schulterlangem, grauen, dünnem, wirrem Haar. Wie der Kettensägenmörder in einem Teenie-Horrorfilm.

Das waren vielleicht die surrealsten 20 Minuten meines Lebens. Ich schätze, dass die Klimaanlage auf dem Dach kaputt war und das Wasser auslief, sich in Decken und Wänden verteilte, und von da seinen Weg in den Fahrgastraum suchte.

Ich stelle mein Win32-Framework auf Klassen um. Das ist das erste Mal seit Jahren, dass ich meinen Projekten Klassen hinzufüge statt sie zu löschen.

Ein Grund ist, dass die Abstraktion mittlerweile hoch genug ist, alles typsicher zu gestalten (ich reiche nicht mehr überall rohe HWNDs herum).

Ein anderer Grund ist, dass die Klassen in diesem Fall keine Attribute haben – die Aliasing-Probleme, die mir sonst immer mit Visual C++ den Maschinentext verhageln, werden also nicht auftreten.

Außerdem werden früher oder später Module in Visual C++ ankommen. Dann fällt ein Kontra gegen Klassen – dass man sie nur verwenden kann, wenn die komplette Deklaration und alle abhängigen Typen #includet sind, und deshalb die Kompilierzeit explodiert – weg.

Zu guter letzt sind sie ein Bisschen weniger zu tippen.

Hoffen wir, dass ich es nicht wieder bereue.

Grafikkarten-Treiber Update

Früher: Installer deinstalliert alten Treiber und installiert neuen.
Heute: Installer deinstalliert alten Treiber, Windows erkennt, dass kein Treiber vorhanden ist, Hardwareassistent blockiert Treiberinstallation, während, vermutlich der Microsoft zertifizierte Treiber heruntergeladen wird, den ich nicht will.

Irgend eine Idee, wie man das unterbinden kann?

Alexander Kornrumpf hat geschrieben:Irgend eine Idee, wie man das unterbinden kann?

Vor der Installation den Netzwerkstecker ziehen ;)

Alexander Kornrumpf hat geschrieben:Heute: Installer deinstalliert alten Treiber, Windows erkennt, dass kein Treiber vorhanden ist, Hardwareassistent blockiert Treiberinstallation, während, vermutlich der Microsoft zertifizierte Treiber heruntergeladen wird, den ich nicht will.

Irgend eine Idee, wie man das unterbinden kann?

Falls du eine AMD-Karte hast, könnte es sein, dass du *doch* den Microsoft-Treiber willst. Der installiert nämlich kein Catalyst Control Center (inklusive aller erforderlichen Runtimes), keine Videokonverter-Software, keinen Installationsassistent; zeigt während der Installation keine Werbung an; ist 80 % kleiner; funktioniert am Ende wahrscheinlich genau so gut (oder ist noch stabiler, weil von Microsoft freigegeben).

Bei Nvidia liefert Microsoft leider das Center mit aus, da willst du dann wohl *doch* den von der Nvidia-Seite.

Bis auf das CCC kann man das bei AMD alles abwaehlen waehrend der Installation ;)

glassbear hat geschrieben:Bis auf das CCC kann man das bei AMD alles abwaehlen waehrend der Installation ;)

Das CCC ist ja das schlimmste Übel. Da läuft so ein C#-Hintergrunddienst, der ab Rechnerstart 150 MiB RAM reserviert, damit das Center schneller geladen ist, wenn man denn draufklickt. Da das erheblich mehr Aufwand ist als „wir lassen es einfach immer laufen“, denke ich, dass folgendes Gespräch stattfand:

Die Leute beschweren sich, dass das CCC immer läuft und so viele Ressourcen verbraucht. Dabei sind 150 MiB RAM doch schon minimal für eine Managed-UI! Was sollen wir tun?

Packt es in einen Hintergrunddienst, den die Leute nur sehen, wenn sie den Task-Manager als Admin starten! Dann können sie es auch nur noch über Dienste in der Systemsteuerung entfernen!

Sowas will ich einfach nicht auf dem Rechner haben. Und selbst Microsoft scheint es ja zu peinlich zu sein, sowas zu verteilen.

Jedenfalls habe ich seit 2012 oder so nur noch den Standardtreiber drauf und mein Jammern hat sich fast auf Null reduziert. Antialiasing manuell einstellen und so, das geht ja seit D3D 10 sowieso nicht mehr. Einzige Ausnahme war, dass der D3D-9-Treiber keinen Application Verifier-Durchlauf schafft (wobei ich immer dachte, das wäre Mindestanforderung für ein WHQL-Zertifikat).

Das CCC ist eine QT-App:

AMD said that Radeon Software Crimson has been built from the ground up with a Qt software development framework, which makes launching the application much quicker. The developers were able to do away with Microsoft's .Net Framework by making this change.

Vielleicht mal Treiber aus 2016 probieren, nicht die alten aus 2015 ;)