ZFX + Developia

CodingCat hat geschrieben:isnan() gibt false zurück, wenn ich mir die Daten auf die CPU hole, steht QNAN drin.

Dann gibt isqnan() bestimmt true zurück :mrgreen:

Nope, es gibt nur isnan(), was laut Doku auf beides prüft. Nach Berechnungen funktioniert es übrigens. Der Compiler nimmt wohl an, dass im Speicher niemals NANs liegen, und optimiert es deshalb einfach mal weg.

Der Optimizer an sich funktioniert ja gar nicht mal so schlecht (wobei Krishty uns hier auch schon eines Besseren belehrt hat, so genau schaue ich da lieber gar nicht erst hin). Aber die Annahmen über den Wertebereich einzelner Variablen sind oftmals schlichtweg falsch, womit ein korrektes Ergebnis bei komplexeren Shadern zur reinen Glückssache wird. Ich muss mittlerweile an einigen Stellen eine Shader-Konstante namens Zero addiere, nur um diesen Wertebereich zu brechen und so vollständigen und korrekten Code zu erzwingen.

CodingCat hat geschrieben:Eine ordentliche IDE für clang müsste man noch schreiben. Am besten gleich mit ordentlichem UI Framework, zwei der größten Mängel in der Industrie mit einer Klappe beseitigt.

Da mich Eclipse mit CDT immer mehr ankotzt (das Ding kann genauso "viel" wie Notepad ...): Was waeren da deine Wunsch-Features und Vorstellungen?
Vielleicht auch in einem extra Thread. Ich hab angefangen, mir libclang in (g)vim zu integrieren fuer Code Parsing und Completion :mrgreen:

Einfach clang als wählbare Compileroption bei VS reinhängen.

kaiserludi hat geschrieben:Einfach clang als wählbare Compileroption bei VS reinhängen.

Das sollte ja einfach gehen. Man kann schliesslich auch den ICC ins VS integrieren. Hab VisualStudio schon Ewigkeiten nicht mehr benutzt...

glassbear hat geschrieben:

kaiserludi hat geschrieben:Einfach clang als wählbare Compileroption bei VS reinhängen.

Das sollte ja einfach gehen. Man kann schliesslich auch den ICC ins VS integrieren. Hab VisualStudio schon Ewigkeiten nicht mehr benutzt...

GCC geht auf alle Fälle, wird z.B für Android NDK Enwtwicklung in VS ia. vs-android und/oder winDBG oder auch vom Marmalade SDK so für die ARM-builds gemacht, da VC++ nicht für ARM baut. Wenn GCC geht, sollte auch clang machbar sein und schon hat man die beste IDE am Markt mit einem Compiler wie GCC oder Clang kombiniert, der auch für unixoide bauen kann. Einziger Haken ist dann noch, dass man auch die Entwicklung für OS , Linux, BSD und andere Unixe unter Windows machen muss, weil VS nicht wo anders läuft, aber zumindest bei mobilen Zielplatformen läuft die IDE ja eh so oder so nicht auf der Zielplatform.

Naja, ich will clang eigentlich gar nicht so dringend als Compiler, sondern wegen der vielen cooles Features die die IDE damit so einfach umsetzen kann. Damit man für C++ das hat, was Eclipse für Java ist. Ich kann es schon gar nicht mehr abwarten, so etwas endlich in die Finger zu bekommen, seit ich dieses libclang Werbevideo (http://devimages.apple.com/llvm/videos/Libclang.mov - hab ich zwar schonmal gepostet, aber was solls, bevor noch einer suchen muss :D ) gesehen habe.

NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

Jonathan hat geschrieben:Naja, ich will clang eigentlich gar nicht so dringend als Compiler, sondern wegen der vielen cooles Features die die IDE damit so einfach umsetzen kann. Damit man für C++ das hat, was Eclipse für Java ist. Ich kann es schon gar nicht mehr abwarten, so etwas endlich in die Finger zu bekommen, seit ich dieses libclang Werbevideo (http://devimages.apple.com/llvm/videos/Libclang.mov - hab ich zwar schonmal gepostet, aber was solls, bevor noch einer suchen muss :D ) gesehen habe.

Interessanterweise wollen alle Javaentwickler und ehemaligen Javaentwickler die ich kenne, Eclipse nicht mal mit Schutzhandschuhen anfassen.

glassbear hat geschrieben:

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

:shock: 15 GiB Code? Ich glaub ihr macht da was ziemlich falsch. :D

BeRsErKeR hat geschrieben:

glassbear hat geschrieben:

Chromanoid hat geschrieben:NetBeans und Eclipse machen das AFAIK schon lange so für C++. Keine Ahnung wie gut, aber auf jeden Fall besser als VC++.

Funktioniert gar nicht in Eclipse :lol: Zumindest nicht bei 150MiB Source Code (= nur ein Teil unseres Systems). Da funktioniert dann nichtmal mehr einfachste Funktionsaufloesung oder irgendetwas... Die ganzen 1.5GiB will er dann gar nicht erst indizieren, auch mit 16GiB RAM nicht. Netbeans ist ein bischen besser, aber auch nicht wirklich gut...

:shock: 15 GiB Code? Ich glaub ihr macht da was ziemlich falsch. :D

1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.

One does not simply use vector<bool>...

Gibt es denn keine Möglichkeit direkt an eine char*-Repräsentation von einem vector<bool> zu kommen?

&v[0]

Jep, oder ab C++11 die Methode data().

Alexander Kornrumpf hat geschrieben:&v[0]

how about no?
_bool_-vector
Versuch es einfach mal.

std::vector<bool> ist eine Ausgeburt der Hölle, wer das verwendet, ist wirklich einfach nur selber schuld...

Und nein, es gibt keine Möglichkeit. ;)

kaiserludi hat geschrieben:1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.

Sind etwa 20 Jahre * ~200 Engineers ;)
Treiber fuer 5-6 unterstuetzte Generationen von Hardware, mehrere voellig unterschiedliche Karten pro Generation. Dazu die User Software. Laeppert sich.

Wie viele Tage braucht das so zum kompilieren?

Jonathan hat geschrieben:Wie viele Tage braucht das so zum kompilieren?

Kann ich gar nicht so genau sagen. Wir nutzen sogenannte Wink-Ins: Kompilierte Object-Files, die zentral im Netz gelagert werden. Bei einem Compile werden die herangezogen, falls der Code nicht geaendert wurde.

Mit Winkins etwa 3-4h auf einer HP Z800 (16 Cores, 16-32GiB RAM, 10k oder 15k RPM Platten).

Schon zum dritten Mal hat sich mein Bildschirm in Schlieren von Magenta aufgelöst. Wenn ich Pech habe, verabschiedet sich meine Grafikkarte demnächst nach nicht mal einem halben Jahr "Forschungsgebrauch".

CodingCat hat geschrieben:Wenn ich Pech habe, verabschiedet sich meine Grafikkarte demnächst nach nicht mal einem halben Jahr "Forschungsgebrauch".

Und wenn du Glück hast, sind seit dem Kauf noch keine 6 Monate vergangen und du kannst beim Händler auf Gewährleistung pochen, wobei der Händler die Beweislast tragen muss. Nach diesen 6 Monaten dreht sich die Beweislast um, und du hast es sehr viel schwerer. Also nicht die Graphikkarte im Backofen grillen, sondern auf Beseitigung des Mangels bestehen. ;)

Sobald man einen Zuweisungsoperator hinzufügt, hört eine C++-Klasse auf, POD zu sein.

Wäre ja an sich nicht schlimm, wenn da nicht ein winziges Detail wäre: Die Standardinitialisierung ändert sich von nullen zu undefiniert lassen. Und Visual C++ spuckt nirgends auch nur den Hauch einer Warnung aus, dass die Daten, die ich mühsam mit () initialisiert habe, jetzt voll Dreck sind. Wer hat sich diese scheiß Schikane bloß ausgedacht? Wenn ich es nicht initialisiere soll es ruhig undefiniert bleiben, in Ordnung. Aber wenn ich explizit eine Initialisierungsaufforderung hinschreibe?! WTF?

Das hat mich daran denken lassen, dass ich immernoch viel zu wenig Annahmen im Quelltext dokumentiere. Hätte

    static_assert(type_traits<Foo>::is_pod, "Jedes Mal, wenn du eine Mikrooptimierung einbaust, pflanzt irgendwo auf der Welt ein besoffener MS-Programmierer einen Bug in den Optimizer!");

vor der betroffenen Stelle gefunden, hätte ich es sofort gemerkt.

Warum sind die meisten von Mobys Hits nun schon über zehn Jahre her? Ich komme mir so alt vor.

Habt ihr euch mal die Pläne alter Intel-CPUs angeschaut, z.B. des 4004er von 1969? Ich schätze, dass etwa um diese Zeit herum CPUs so kompliziert wurden, dass nur noch Autisten die Funktionsweise bis auf die Transistoren runter verstehen konnten. Mitte der 80er dann so, dass sie menschlich nicht mehr vollständig verstehbar wurden. Ich komme mir so jung vor.

glassbear hat geschrieben:

kaiserludi hat geschrieben:1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.

Sind etwa 20 Jahre * ~200 Engineers ;)
Treiber fuer 5-6 unterstuetzte Generationen von Hardware, mehrere voellig unterschiedliche Karten pro Generation. Dazu die User Software. Laeppert sich.

Ist das dann in Brainfuck oder Malbolge geschrieben? :D Ne mal ehrlich da kann man ja quasi mehrere Betriebssysteme draus machen ... Aber ich kenne solche Riesenteile leider nur zu gut hier von Siemens ...

Die CUDA-OpenGL interop ist echt der letze Dreck...

cudaGraphicsGLRegisterBuffer(..) funktioniert bei 2 von vier Buffern einwandfrei bei den anderen beiden zerschiest es mir den Speicher und ich bekomm ein Race zwischen OGL und CUDA :(

Wenn man ein Feature nicht durchdenkt, kann man viele Stunden damit verbringen, seine Designfehler zu korrigieren.

Closures sind geil zum programmieren, aber schwierig zu implementieren. (Ich schwitze gerde an statisch getypten Closures mit generischen Datentypen)

glassbear hat geschrieben:

Jonathan hat geschrieben:Wie viele Tage braucht das so zum kompilieren?

Kann ich gar nicht so genau sagen. Wir nutzen sogenannte Wink-Ins: Kompilierte Object-Files, die zentral im Netz gelagert werden. Bei einem Compile werden die herangezogen, falls der Code nicht geaendert wurde.

Mit Winkins etwa 3-4h auf einer HP Z800 (16 Cores, 16-32GiB RAM, 10k oder 15k RPM Platten).

Ihr benutzt ClearCase? Das wäre in der Tat ein Grund zu jammern... Gerade die Winkins können einem bei einem recht großen Repo das Netzwerk zu dichtmachen.

Kimmi

kimmi hat geschrieben:hr benutzt ClearCase? Das wäre in der Tat ein Grund zu jammern... Gerade die Winkins können einem bei einem recht großen Repo das Netzwerk zu dichtmachen.

Ja, Clearcase. Das Netzwerk ist auch oft genug "langsam" oder faellt halt mal aus. Sehr lustig, wenn der Backup-Switch nicht anspringt und spontan 200 Leute nicht mehr arbeiten koennen bis HP Ersatz liefert :lol:

Code ist groesstenteils C mit etwas C++ und bischen Java.

Würde mich mal interessieren, wie viel Duplicated Code bei solch einem riesigen Projekt existiert. Ich tippe, ohne je an solch einem Projekt gearbeitet zu haben, auf 15%. :D