Jammer-Thread

[joggel]

Mal den ollen Jammer-Thread rauskramen:

Ich brauch einen neuen PC!!
Besser gesagt:
- Mainboard
- CPU
- RAM
- HD
:(

Muss wohl in den saueren Apfel beißen, und nun endlich mal investieren...

[Krishty]

Ich werde nie wieder Funktionen überladen, wenn enums im Spiel sind. Ich musste die Überladung für enum umbenennen und darf jetzt aus zweitausend Zeilen vierhundert Funktionsaufrufe raussuchen und je höchstpersönlich dafür sorgen, dass er die richtige Funktion entweder für unsigned int, int oder enum aufruft. Erstmal alle Funktionen, die Parameter akzeptieren, zu denen sich enum explizit umschnippeln lässt, geht natürlich auch nicht, weil ja auch int und unsigned int untereinander kompatibel sind. Ich hasse hasse hasse enums und ihre implizite Konvertierung / Promotion / Leckmichdoch.

[Top-OR]

... Ich hasse hasse hasse enums ... .

Mist: Und ich habe unserem Azubi vor 2 Monaten genau das Gegenteil gesagt ... :shock: :-(

[Krishty]

Meine Meinung ändert sich vielleicht wieder mit C++0x’ stark typisierten enums … aber bis mein Lieblingshasscompiler die implementiert, bleibt enum gewiss verflucht.

[Jonathan]

OpenSceneGraph unter Windows macht Spaß...

Das cmake Skript kann ich nicht benutzen, weil es ~20 Bibliotheken braucht die ich alle nicht habe und die ich vermutlich alle einzeln runterladen, kompilieren und installieren müsste und dann noch alle Pfade setzen muss.
Gut, es gibt fertige Binaries, sogar von VC2010, und ich hab es nach langem rumprobieren endlich geschafft, das Qt Beispiel zu kompilieren und das sagt einfach nur, dass kein Plugin gefunden wurde um die Beispieldatei zu laden. Achja und im Releasemodus stürzt es einfach so ab, keine Ahnung warum.
Toll auch, das als DOkumentation nur ein doxyfile dabei war, was auch nicht laufen will, weil es irgendwelche komischen Variablen benutzt, die vermutlich durch das CMake Skript gesetzt würden oder so. JUHU! ...

[Schrompf]

Krishtys Schimpfereien sind inzwischen in ziemlich esoterischen Bereichen angekommen :-) Deswegen sollte man jetzt keine enums meiden, nur weil die Überladung von Funktionen mit int und unsigned int-Parametern mehrdeutig wird.

[Krishty]

nur weil die Überladung von Funktionen mit int und unsigned int-Parametern mehrdeutig wird.

Wird sie ja noch nicht einmal. Wird nur scheiße schwer wartbar; wenn man mal einen unglücklichen Funktionsnamen ändern muss, kann man schlimmstenfalls alles neu schreiben.

Und schuld ist dieser unsägliche implizite Müll, der die Sprache von vorn bis hinten undurchschaubar macht, weil vor hundert Jahren mal irgendwelche Pfosten, die nichts von dem Ganzen verstanden haben, zwei explizite Konvertierungen in ihrem Quelltext sparen wollten. Diese ganze beschissene enums bieten keine Arithmetik an aber die wäre irgendwie cool, also lass eine Promotion von enum zu int einbauen damit ich Grün = Blau - Gelb; schreiben kann-Philosophie. Und in dieser verrotteten Gedankenkotze darf ich jetzt in jeder Zeile aufs Neue rumplanschen. Vollidioten.

[Schrompf]

Nunja, das ist allerdings lästig. Wird wahrscheinlich eher für NeueFarbe = Grün | Blau | Gelb gewesen sein, oder um Enums als Array-Index benutzen zu können - aber das Prinzip ist schon lästig. Waren halt andere Zeiten damals...

[Chromanoid]

Wie wäre es mit einer eigenen "enum" Klasse für solche Zwecke - eine Art Kapselung würde ja reichen...? Und kann man das nicht per search & replace erledigen?

[Schrompf]

Das ist durchaus üblich. QT hat mit seiner QFlags-Templateklasse eine typsichere Enum-Kapselung geschaffen und mit den üblichen Operationen für Flag-Kombinationen ausgestattet. Ist ganz praktisch.

[Aramis]

Dem schliesse ich mich an, enums waren hier offenbar das falsche Tool.

[Krishty]

Und kann man das nicht per search & replace erledigen?

Nö – Funktionsüberladung bedeutet ja, dass eine Funktion für unterschiedliche Parametertypen denselben Namen hat. Ich kann zwar den Funktionsnamen ersetzen, aber ich kann nicht ausschließlich den Namen jener Überladung ersetzen, die enum akzeptiert. Und wenn ich die Überladung fürs enum umbenenne, promotet der Compiler ohne Mucken alle Aufrufe mit dem enum an die Überladung, die int akzeptiert und das ganze Programm ist schrott.

Man könnte ja denken, dass man dann einfach die Überladung für int umbenennt (int zu enum wird ja schließlich nicht promotet), dann eine Reihe Fehlermeldungen gelistet bekommt, wo man den Funktionsnamen der int-Überladung ersetzen muss und dann die enum-Überladung mit dem alten Namen suchen und ersetzen kann.

Aber das ging auch nicht, weil ich ja noch eine Überladung für unsigned int hatte. Dann hat der Compiler eben von enum über int zu unsigned int promotet. (Oder direkt dahin. Lass das PDF zu, Aramis.)

Also musste ich erstmal alle Überladungen außer der enum-Überladung umbenennen, alle nun als fehlerhaft gemeldeten Aufrufe ersetzen und konnte dann den Namen der enum-Überladung ändern, weil der als einziges unberührt blieb.

Ist Refactoring nicht was Schönes!

enums waren hier offenbar das falsche Tool.

Dann bietet C++(’97) halt kein Richtiges. Zusätzlich zu Legacy-Kack. Macht es auch nicht besser.

Über die Klasse denke ich ewig schon nach. Nur: Der Compiler initialisiert wieder zur Laufzeit, sobald das Objekt einen K’tor hat, und mit VCnext kommen eh stark typisierte enums; dann fliegt sie wieder raus. Und ich müsste die Klasse wieder damit begründen, dass das Komitee die letzten zwanzig Jahre zu blöd dafür war. KA.

[Aramis]

Oder direkt dahin. Lass das PDF zu, Aramis.

Eine Variante waere gewesen, dem enum einen einzelnen Dummy-Eintrag ausserhalb des Wertebereich eines unsigned int zu geben, dann waere laut PDF naemlich nur eine Promotion nach long moeglich.

Ach moment, du willst natuerlich nicht dass dein Enum 8 Bytes beansprucht :-)

PS: Wenn wir schon gerade dabei sind - wenn dich implizite Konversionen stoeren, wieso laesst du denn ueberhaupt Integral Promotions in deinem Quellcode zu? Ein explizit spezialisiertes Template verhindert jegliche Promotion - damit kannst du sogar auch einzelne, ansonsten der Promotion zum Opfer fallende Typen, abfangen - schliesslich hat ein Template fuer dessen Aufruf keine Konversion erforderlich ist, einen besseren Konversionsrang als eine gewoehnliche Funktion fuer deren Aufruf eine Integral Promotion erforderlich ist.

[Krishty]

Eine Variante waere gewesen, dem enum einen einzelnen Dummy-Eintrag ausserhalb des Wertebereich eines unsigned int zu geben, dann waere laut PDF naemlich nur eine Promotion nach long moeglich.

Okay. Das hatte ich übersehen. Hätte mir tatsächlich Arbeit ersparen können.

PS: Wenn wir schon gerade dabei sind - wenn dich implizite Konversionen stoeren, wieso laesst du denn ueberhaupt Integral Promotions in deinem Quellcode zu? Ein explizit spezialisiertes Template verhindert jegliche Promotion - damit kannst du sogar auch einzelne, ansonsten der Promotion zum Opfer fallende Typen, abfangen - schliesslich hat ein Template fuer dessen Aufruf keine Konversion erforderlich ist, einen besseren Konversionsrang als eine gewoehnliche Funktion fuer deren Aufruf eine Integral Promotion erforderlich ist.

Das ist extrem verlockend, aber auch furchtbar ineffizient. Wie gesagt: Sobald ein K’tor da ist, wird nicht mehr statisch optimiert. Stell dir vor, dass alle Konstanten in deinem Programm nicht mehr „reinkompiliert“ werden, sondern erst beim Programmstart bzw. bei der ersten Benutzung initialisiert werden. Wenn ich das tue, brauche ich nie mehr irgendwas optimieren :) (Ist wirklich so schlimm. Jedes Mal, wenn ich die statische K’tor-Liste im voll optimierten Release-Build durchgehe, schwirrt mir ein K’tor entgegen, der nichts anderes tut als eine Konstante mit dem julianischen Datum des 1. Januar 2000 in Empfang zu nehmen und 1:1 ins Attribut meiner Festkomma-Klasse zu kopieren.

000000013FCA3680 mov rax,0C544455600000000h
000000013FCA368A mov qword ptr [Cric::chronology::J2000 (13FCAC1C0h)],rax
000000013FCA3691 ret
000000013FCA3692 int 3
000000013FCA3693 int 3
000000013FCA3694 int 3
000000013FCA3695 int 3
000000013FCA3696 int 3
000000013FCA3697 int 3
000000013FCA3698 int 3
000000013FCA3699 int 3
000000013FCA369A int 3
000000013FCA369B int 3
000000013FCA369C int 3
000000013FCA369D int 3
000000013FCA369E int 3
000000013FCA369F int 3

)

[Krishty]

Gerade bald bekloppt geworden, weil sich die Adresse eines Objekts nach Abschluss seines K’tors zu ändern schien. Was war los? Das Objekt hat seinen this-Zeiger in eine Liste eingetragen. Die war im Prototyp als statisches Array hingehackt und wurde danach auf einen vector umgestellt. Und dabei hatte ich was vergessen:
++manager.list.append(copyOf(this));
Irgendwann muss ich mal append() dazu veranlasst haben, eine Referenz aufs neu eingefügte Element zurückzugeben -.-

[Krishty]

Hmm. Das hier noch länger ertragen

oder jedes Mal, bevor und nachdem ich zocke, das Catalyst Control Centre starten um Antialiasing ein- und wieder auszuschalten (weil Profile ja einfach … nichts bewirken)?

…

Da ertrage ich definitiv lieber weiter Grafikfehler bei allem, was ich tue
(Java-Anwendungen sehen noch deutlich schlimmer aus. Da kann man dann nicht einmal mehr Kacheln erkennen.)

Eins muss man AMD ja lassen:
Sie schaffen es echt immer wieder, mir vor Augen zu führen, wie jämmerlich ich in meiner Annahme bin, alles sollte einfach nur funktionieren

[CodingCat]

Geteilte Datenstrukturen in einer parallelen Ausführungsumgebung sind echt die Hölle und produzieren mit Abstand den unschönsten Code, den ich seit langem geschrieben habe. Zudem diese ganzen Double Checks, die beim Sparen von Synchronisationsaufrufen duch Lazy Synchronization notwendig werden, die impliziten gegenseitigen Ausschlüsse und atomaren Get-Check-CompareExchange-Spins um Locks zu sparen... Und wenn man dann endlich möglichen parallelen Methodenkombinationen gefunden und durchgespielt hat, alle Race Conditions behoben sind, fragt man sich, ob das denn nun wirklich sicher ist - einfach so testen, oder gar mit wenigen Blicken durchschauen und verstehen lässt es sich ja nicht, wenn die Hälfte des Codes schonmal aus Zusicherungen und Kommentaren zu abstrusen parallelen Grenzfällen besteht. Zum Glück handelt es sich hier um das Job-System, also die Verteilung einer Hierarchie von Jobs auf einen Thread-Pool, inklusive möglicherweise anfallender Synchronisation. Mit etwas Glück muss ich mich ab sofort also nicht weiter damit befassen, *wenn* das System denn sicher ist.

[j.klugmann]

Job-Pools kommen aktuell bei mir an zwei Stellen zum Einsatz( später noch in anderen Modulen ). Zum einen meine Asynchrone IO-Lib, die automatisiert Aufrufe auf bestimmte Threads verteilt und dann mein Mathe-Modul, welches Aufrufe an Monaden(naja, Monaden-ähnliche Strukturen) bindet, die dann je nach Abhängigkeiten an die verschiedenen Threads verteilt wird. Bis jetzt funktioniert eigentlich alles, Probleme mit der Synchronisation hatte ich noch nicht, allerdings werde ich wohl bald von den POSIX-Threads wegkommen, um dann endlich mal richtige Userspace-Threads/Software-Threads zu nutzen, die ja generell mehr Möglichkeiten für Synchronisation bieten. Allerdings funktionieren POSIX-Threads auch ziemlich gut.

Viel ärgerlicher war die letzten Tage mal wieder ein kleiner Fehler in meinem Objekt-Modul. Das Objekt-Modul verwaltet einfach eine große Anzahl von Objekten und stellt Basis-Klassen zur Verfügung. Alle Objekte werden (wenn gewollt) in einer Hash-Table gespeichert, um eine mehr oder weniger eindeutige Identifikation zu erlauben, die Hashes erstelle ich mit CRC32, optional auch mit sha1, aber das geht meiner Meinung nach zu stark in die Performance.

Momentan liege ich bei 0.39 - 0.6 Sekunden um 250'000 Objekte mit CRC32 zu hashen und entsprechend in eine Tabelle einzuordnen. Da ich einen B-Tree innerhalb der Hash-Table nutze, wird mit jeder Einfüge-Operation auch immer erst eine Such-Funktion ausgeführt, die bestimmen soll, ob der entsprechende Schlüssel schon besteht. Ich kann aktuell leider schlecht abschätzen, wie viele Objekte man in einem ausgereiften Spiele oder Simulationsprojekt brauchen würde, allerdings denke ich, dass die Performance aktuell noch ausreicht. Such-Operationen sind eigentlich relativ billig, es werden nur Strings verglichen, wenn ein Schlüssel mehrere zugeordnete Objekte hat. Auch wenn CRC32 herzlich wenig mit dem Inhalt der Daten zu tun hat, ist CRC32 meiner Meinung nach ausreichend. sha1 wäre mir aktuell noch zu teuer, aber wenn man das noch ein bisschen mit SIMD optimiert, sollte das auch passen.

[CodingCat]

Hat es einen Grund, warum du ausgerechnet CRC32 als Hash-Funktion verwendest? Normalerweise wählt man Hash-Funktionen ja möglichst simpel so, dass sie gute Eigenschaften speziell für Hash-Tables aufweisen. Und wozu nutzt du den B-Baum in deiner Hash-Tabelle, zur Kollisionsauflösung? Oder implementierst du gar verteilte Hash-Tables? Und ich gehe mal davon aus, dass du nicht jeden Zeitschritt deiner späteren Simulation 250000 Objekte in eine Hash-Tabelle einfügen wirst?

[Chromanoid]

http://sites.google.com/site/murmurhash/ ist glaube ich zu empfehlen.

[j.klugmann]

Hat es einen Grund, warum du ausgerechnet CRC32 als Hash-Funktion verwendest? Normalerweise wählt man Hash-Funktionen ja möglichst simpel so, dass sie gute Eigenschaften speziell für Hash-Tables aufweisen. Und wozu nutzt du den B-Baum in deiner Hash-Tabelle, zur Kollisionsauflösung? Oder implementierst du gar verteilte Hash-Tables? Und ich gehe mal davon aus, dass du nicht jeden Zeitschritt deiner späteren Simulation 250000 Objekte in eine Hash-Tabelle einfügen wirst?

Ich will zum einen möglichst Kollisionen vermeiden und zum anderen bei Kollisionen möglichst effizient vorgehen. B-Bäume eignen sich gut für Kollisionen und haben bei guter Implementierung auch sehr schnelle Insert sowie Search-Funktionen. Ich kenne mich mit dem Thema auch nicht so gut aus, aber letztendlich ist das aus meiner Sicht der beste Weg. Eine verteilte Hash-Tabelle ist aber nicht Sinn der Sache, da dabei ja auch die Datenspeicherung an sich im Vordergrund steht. Aktuell möchte ich aber einen Kompromiss aus Performance und Sicherheit haben. CRC32 war eigentlich die erste Funktion, an die ich da gedacht hatte. Ich werde mich letztendlich nochmal über andere Hash-Funktionen informieren, die ich dann bis zum ersten Release meiner Lib eingebaut haben werde.

[Chromanoid]

Wenn du IDs im 4 byte Bereich hast, dann ist Murmur hash ne gute Wahl. Murmur hash ist in dem Bereich kollisionsfrei, sehr gut verteilt und sehr schnell. Projekt hardoop nimmt den glaube ich auch an einigen Stellen für Normalisierung von Keys. Ganz sicher weiß ich es bei der Standard Hashfunktion von JBoss Infinispan.

[Chromanoid]

Nur als Warnung :) http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php damit niemand jammert :)

[Aramis]

Waaaaaaaaa :-)

[anonym]

Programming Language Inventor or Serial Killer? gesehen in Über Programmiersprachen-Designer und andere Verbrecher

[Top-OR]

Juhuuu Mist, nur 8 of 10. [Das ist ja der Jammer-Thread ;-) ]

[Krishty]

CreateFileMappingW() failed: Der Datentr├ñger einer Datei wurde extern so ge├ñndert, dass die ge├Âffnete Datei nicht mehr g├╝ltig ist.

wat

Die liegt right here auf meiner Festplatte

Windows findet sie, öffnet sie (nur lesend!), schneidet sie auf 0 B und wirft mir den Fehler an den Kopf?!?

Ich Hirnsparlampe habe die Datei zum Schreiben statt zum Lesen geöffnet … dennoch eine unkonventionelle Art mir mitzuteilen, dass er Dateien mit 0 B Größe nicht in den Speicher kriegt.

[Krishty]

Na ihr Portabilitätsfreaks, habt ihr Langeweile? Dann habe ich was für euch:

Kramt mal eure alte 32-Bit-x86-Kiste raus, installiert Visual Studio 2010 drauf und kompiliert darauf euer x64-Projekt. Wie ich nämlich eben herausgefunden habe, verhält sich der x64-auf-x86-Cross-Compiler wieder ein bisschen anders als der native x64-Compiler (akzeptiert z.B. kein unsigned long long als Parameter für operator new sondern ausschließlich size_t-typedefs). Spaß garantiert!

Damit hat MS also einen x86-on-x86-Compiler, einen x64-on-x86 und einen für IntelliSense. Verstehe garnicht, warum die es so schwer haben, die ganzen C++0x-Features zu integrieren.

[Chromanoid]

Besitzt Intellisense eigentlich wirklich einen richtigen Compiler oder ist das eher eine Art Parser? Wenn das ganze eher ein Parser ist, dann ist das AFAIK eher best practice. Zumindest haben eclipse und netbeans schon länger recht komplexe Parser für code assistance eingebaut.

[Krishty]

Kommt drauf an, was du als „richtigen“ Compiler verstehst. Die Maschinentext-Erzeugung und -Optimierung ist sicher nicht drin; da aber C++ durch einfaches Parsen nicht verifizierbar und IntelliSense äußerst nah am tatsächlichen Verhalten der Sprache ist, würde ich schon von einem vollständigen Compiler-Frontend sprechen.

Und ich habe oben den x64-on-x64-Compiler vergessen.