Jammer-Thread

[antisteo]

Ja, fürs nächste mal ziehe ich das konsequent von anfang durch...

Nimm dir am besten die Zeit, deinen kompletten Quellcode noch mal durchzulesen und überall das Koordinatensystem anzupassen. Solches Refactoring ist wichtig, wenn du an einem Projekt mehrere Jahre Freude haben willst. So verhinderst du, dass sich Altlasten ansammeln, die du nicht wieder losbekommst.

[joggel]

Ja, fürs nächste mal ziehe ich das konsequent von anfang durch...

Nimm dir am besten die Zeit, deinen kompletten Quellcode noch mal durchzulesen und überall das Koordinatensystem anzupassen. Solches Refactoring ist wichtig, wenn du an einem Projekt mehrere Jahre Freude haben willst. So verhinderst du, dass sich Altlasten ansammeln, die du nicht wieder losbekommst.

Haha. Ich würde auch jeden diesen Rat geben.
NUR:
Das soll mir eben nicht mehrere Jahre Beschäftigung geben.
So hatte ich nämlich am Anfgang gedacht.
"Ach, schreibst mal schnell nen kleinen Sternen-Scroller.
Ok, jetzt paar Asteroiden die sich da bewegen... und noch ein Schiff was man steuern kann.
Und wenn ich gleich dabei bin, baue ich paar Gegner ein..."

Weißt, hier ist es wirklich trivial das noch anzupassen. Aber das ist so ein grundsätzliches Problem beim SW-Design.
Man designed etwas, und denkt es reicht für seine Ansprüche. Im laufe des Projektes kommen weitere Anforderungen dazu bzw, es ändert sich etwas oder so, und schon muss man umschreiben.
Und man muss da echt konsequent und diszipliniert sein, und sich die Zeit nehmen, um es ordentlich zu machen... :x

Ich habe mal bei jemanden gearbeitet die haben das so gemacht, dass sie sich gegenseitig den Quellcode angeschaut haben, um ihn auf verständlichkeit zu prüfen (Clean-Code). Das Projekt sollte da auch viele Jahre bearbeitet und erweitert werden....

Naja, aber wie gesagt:
Hier ist es wirklich was sehr triviales, und ich werde das noch anpassen...sauber!!!^^

[antisteo]

Ja, fürs nächste mal ziehe ich das konsequent von anfang durch...

Nimm dir am besten die Zeit, deinen kompletten Quellcode noch mal durchzulesen und überall das Koordinatensystem anzupassen. Solches Refactoring ist wichtig, wenn du an einem Projekt mehrere Jahre Freude haben willst. So verhinderst du, dass sich Altlasten ansammeln, die du nicht wieder losbekommst.

Haha. Ich würde auch jeden diesen Rat geben.
NUR:
Das soll mir eben nicht mehrere Jahre Beschäftigung geben.
So hatte ich nämlich am Anfgang gedacht.
"Ach, schreibst mal schnell nen kleinen Sternen-Scroller.
Ok, jetzt paar Asteroiden die sich da bewegen... und noch ein Schiff was man steuern kann.
Und wenn ich gleich dabei bin, baue ich paar Gegner ein..."

Weißt, hier ist es wirklich trivial das noch anzupassen. Aber das ist so ein grundsätzliches Problem beim SW-Design.
Man designed etwas, und denkt es reicht für seine Ansprüche. Im laufe des Projektes kommen weitere Anforderungen dazu bzw, es ändert sich etwas oder so, und schon muss man umschreiben.
Und man muss da echt konsequent und diszipliniert sein, und sich die Zeit nehmen, um es ordentlich zu machen... :x

Dirty Code zu schreiben ist mmn absolut legitim, um schnelle Ergebnisse zu produzieren.
Beispielsweise habe ich bei gwX zuerst eine herunterfallende Kugel hartgecodet, um eine grafische Ausgabe zu haben.

Wichtig ist nur, dass man, sobald man auf dem Code aufbaut, kontrolliert, dass er spätestens dann sauber geschrieben ist. Also so spät wie möglich, aber trotzdem noch reichtzeitig.

[Krishty]

Aber das ist so ein grundsätzliches Problem beim SW-Design.
Man designed etwas, und denkt es reicht für seine Ansprüche. Im laufe des Projektes kommen weitere Anforderungen dazu bzw, es ändert sich etwas oder so, und schon muss man umschreiben.
Und man muss da echt konsequent und diszipliniert sein, und sich die Zeit nehmen, um es ordentlich zu machen... :x

Deine Komponenten sind einfach nicht wiederverwendbar bevor du sie nicht in mindestens drei unterschiedlichen, voneinander unabhängigen Projekten einsetzt – ganz egal, wie viel Mühe du dir beim Entwurf machst. Wenn du meinst, schon beim ersten Schreiben alles einkalkulieren zu müssen, wird das Ergebnis normalerweise noch schlimmer (premature reuse ist das deutlich größere Problem als premature optimization). Also sorg einfach dafür, dass du den Quelltext noch verstehst, wenn du ihn in 6 Monaten überarbeiten musst.

[Krishty]

Ich habe zwei Core i7: einer ein Jahr alt, und einer drei Jahre alt.

Meine Baumtraversierung (single-threaded) schließt auf dem *neuen* i7 in 270 Sekunden ab.

Auf dem *alten* Core i7 ist sie nach 300 Sekunden erst bei etwa einem Prozent, und er verbringt fast die gesamte Zeit in einer float-basierten-Verzweigung. Die Leistung liegt damit kaum über meinem 6 Jahre alten Intel Atom (mit 1,2 GHz und 2-stufiger Pipeline).

So viel zum Thema „Die Chips werden eh nicht mehr schneller, programmiert in 1000 Threads!!!!!“.

Wieder ein gigantischer Pipeline Stall und Prefetch Fail, der zwar nicht mehr bei neuen CPUs auftritt, den ich aber jetzt suchen darf damit das Programm auf meinem Produktivsystem in endlicher Zeit abschließt.

[dot]

Kommen dir irgendwo NaNs oder Denormals rein?

[Krishty]

Sehr gute Idee! (Soweit ich weiß dauert Arithmetik auf Denorms „hunderte“ Takte statt einer Handvoll; es würde also gut ins Bild passen.)

Ich sichere normalerweise meine Mathe-Funktionen via Assertion dagegen ab; es kann aber gut sein, dass ich eins vergessen oder irgendwo händisch Quelltext dupliziert habe. Heute abend weiß ich hoffentlich mehr.

[dot]

Exakt, afaik ist Intel in jüngeren Generationen den mit Denormals verbundenen Overhead unter SSE teilweise losgeworden...

[Krishty]

Grrrrrnnnnngh man darf unter Visual C++ einfach keine for-Schleifen mehr benutzen …

  for(auto it = begin; it < end; ++it)
    …

kompiliert zu

  auto count = ((char const *)end - (char const *)begin) / sizeof *begin; // Integer-Division!
  if(0 != count) { // Abhängigkeit von vorheriger Zeile IN EINEM SPRUNG!
    auto it = begin;
    do {
      …
      ++it;
    } while(count-- != 0); // Zwei Iteratoren statt einem; ein Register mehr belegt; 32-Bit-Code kotzt!
  }



Ich weiß nicht was sie da geritten hat, zwei Iteratoren zu benutzen, und wie das schneller sein soll als die wörtliche for-Übersetzung – aber ich muss jetzt immer schreiben:

  if(begin != end) {
    auto it = begin;
    do {
      …
    } while(++it < end);
  }

diese Version übersetzt Visual C++ dann unverändert. Was mich daran verblüfft, ist: Ich hatte hier schonmal aufgezählt wie pervers Visual C++ for-Schleifen mutieren lässt, und da hatten sie ebenfalls einen zusätzlichen Zähler eingeführt, aber der hat aufwärts gezählt. Sie haben also mindestens zwei Versionen der Schleifen„optimierung“ drin:

• Schleifen mit Zählern werden erweitert zu Aufwärtszähler plus Iterator;
• for-Schleifen mit Iteratoren werden erweitert zu Abwärtszähler plus Iterator;
• do while-Schleifen werden niemals erweitert. Zum Glück, denn sonst müsste ich meine Schleifen nur noch via goto schreiben.

[Krishty]

Kommen dir irgendwo NaNs oder Denormals rein?

Das ist es scheinbar nicht. Ich habe testweise sowohl Flush-to-Zero als auch Denormals-are-Zero eingeschaltet, und nichts hat sich geändert.

Der Fehler muss woanders liegen: Die Release-Version braucht auf dem alten 3-GHz-i7 doppelt so lange wie auf dem 1-GHz-Atom (!!!); die Debug-Version ist schneller (aber immernoch langsamer als Release auf Atom). Ich gehe von nicht initialisierten Variablen oder Pufferüberläufen aus, die mich bei der Traversierung falsch abbiegen lassen … :-(

[hagbard]

Grrrrrnnnnngh man darf unter Visual C++ einfach keine for-Schleifen mehr benutzen …

  for(auto it = begin; it < end; ++it)
    …

kompiliert zu

  auto count = ((char const *)end - (char const *)begin) / sizeof *begin; // Integer-Division!
  if(0 != count) { // Abhängigkeit von vorheriger Zeile IN EINEM SPRUNG!
    auto it = begin;
    do {
      …
      ++it;
    } while(count-- != 0); // Zwei Iteratoren statt einem; ein Register mehr belegt; 32-Bit-Code kotzt!
  }



Ich weiß nicht was sie da geritten hat, zwei Iteratoren zu benutzen, und wie das schneller sein soll als die wörtliche for-Übersetzung – aber ich muss jetzt immer schreiben:

  if(begin != end) {
    auto it = begin;
    do {
      …
    } while(++it < end);
  }

diese Version übersetzt Visual C++ dann unverändert. Was mich daran verblüfft, ist: Ich hatte hier schonmal aufgezählt wie pervers Visual C++ for-Schleifen mutieren lässt, und da hatten sie ebenfalls einen zusätzlichen Zähler eingeführt, aber der hat aufwärts gezählt. Sie haben also mindestens zwei Versionen der Schleifen„optimierung“ drin:

• Schleifen mit Zählern werden erweitert zu Aufwärtszähler plus Iterator;
• for-Schleifen mit Iteratoren werden erweitert zu Abwärtszähler plus Iterator;
• do while-Schleifen werden niemals erweitert. Zum Glück, denn sonst müsste ich meine Schleifen nur noch via goto schreiben.

Gilt dass eigentlich auch wenn du in der for()-Variante auf != statt auf < prüfst? Und optimiert der Compiler wirklich do while anders als while ... ?

[Krishty]

Gilt dass eigentlich auch wenn du in der for()-Variante auf != statt auf < prüfst?

Habe gerade keine Zeit zu testen; mittlerweile hoffentlich nicht mehr. CodingCat hatte aber vor einigen Jahren deswegen einen Fehler gemeldet (Schleifen wurden nicht abgerollt wenn durch != statt < verglichen wurde), also war dafür zumindest zu Visual C++ 2008-Zeiten noch fallabhängige Optimierung am Werk.

Und optimiert der Compiler wirklich do while anders als while ... ?

Ja; aber do while und while sind ja auch semantisch unterschiedlich (do while hat zumindest einen Durchlauf; while könnte komplett übersprungen werden) und erzeugen dementsprechend unterschiedlichen Maschinentext – darum sehe ich das nicht unbedingt als Problem.

————

Assimp hat ein Flag um das Modell in den Koordinatenraum [-1, +1] zu skalieren. Das ist okay wenn man nur einen Viewer schreibt, aber falls man irgendeine Art von Weiterverarbeitung macht wird es schon wieder knifflig. Die Division, die die Koordinaten in diesen Bereich bringt, liegt bis zu 0,5 ULPs daneben. (Ich hoffe mal, dass es eine Division ist, und keine Multiplikation mit der Inversen, die weitaus weniger genau ist.) Viel sinniger wäre eine Division durch die nächsthöhere Zweierpotenz (die bei Gleitkommazahlen nur eine Änderung des Exponents bedeutet, aber die kostbare Mantisse nicht berührt).

Dann wäre die größte Seitenlänge irgendwo zwischen 0,5 und 1, und die Koordinaten hätten kein einziges Bit Genauigkeit eingebüßt. Ich persönlich überlege, die Seitenlänge zu 2^62 zu skalieren – je größer das Modell, desto länger kann man damit herumrechnen bevor denormalisierte Zahlen und Unterläufe auftreten (man gewinnt also in Zwischenergebnissen ein Drittel oder Viertel eines Bits an Präzision). Der Exponent 62 rührt daher, dass das Quadrat der maximalen Distanz durchs Modell immernoch unter FLT_MAX (und damit unter einem float-Überlauf) läge.

Wenn man höhere Genauigkeit braucht sollte man sowieso auf double umsteigen, aber das wäre Brute Force und mir gefällt der Gedanke, stattdessen ein Dreiviertel Bit durch klügere Ausnutzung bestehender Mittel herauszuholen.

[Krishty]

error : out-of-line definition of 'SetSymbol' does not match any declaration in 'Symbol'
note: type of 11th parameter of member declaration does not match de…

wenn ich sowas schon im Ausgabefenster sehe

Jammert außer mir eigentlich niemand mehr? Habt ihr Heroin für euch entdeckt?

[joggel]

Ich finde es scheisse, dass ich Heroinabhängig bin :(

[Schrompf]

Mir geht's aktuell zu gut. Mein einziger wirklicher Ärger ist, dass ich mehr Verpflichtungen als Zeit habe und niemanden enttäuschen will. Aber daraus wird es zwangsweise hinauslaufen.

[eXile]

Recode

Und genau das passiert, wenn Microsoft faul herumsitzt und Edit&Continue nicht für x64 implementiert. Aber irgendwann, bestimmt.

[Schrompf]

Mit VS2013 ist Edit&Continue jetzt auch für 32Bit-Software bei mir unbrauchbar. Ich bin wirklich bereit, Geld für das Feature auszugeben. Soweit ist es mit mir schon gekommen...

[Schrompf]

Code: Alles auswählen

Vector3D v = 0.5f * v; 

Kompiliert warnungsfrei mit VS2013. WasDerBeischlaf?

[Artificial Mind]

Vielleicht möchtest du ja genau die Hälfte von dem was vorher an der Speicher/registerstelle stand? :)

[Krishty]

Das ist um sowas abzudecken wie

   WINAPI_KRAM kram = { sizeof kram, 0, FOO | BAR };

oder

  GraphNode infinity = { &infinity, &infinity }; // before & next

Darum kann man da nicht pauschal warnen sondern erst mit Whole Program Analysis.

[Artificial Mind]

Wie kann man performant DirectX Texturen zwischen Applikation sharen wenn einer die Texturen befüllt (produced) und der andere konsumiert?
Microsoft hat hier eine Antwort die sich auch gut anhört: http://msdn.microsoft.com/en-us/library ... s.85).aspx (Ungefähr Mitte bei "Open a Consumer")

Und nun googlet mal nach den dort beschriebenen Klassen "IDXGIXSurfaceProducer", "IDXGIXSurfaceConsumer", "IDXGIXSurfaceQueue".
Mit ein bisschen Glück gibt es in ein paar Tagen diesen Thread hier als zweites Ergebnis :(

[Krishty]

Hmmmm. Der Inhalt des Artikels sieht schon ziemlich betagt aus; wahrscheinlich stammen die Schnittstellen noch aus einer sehr frühen Version. Der Keyed Mutex war bisher auch die einzige Art, die ich kannte.

Können wir jetzt bitte virtualisierten Grafikspeicher haben? Dann könnte man die Textur teilen wie alles andere auch – in eine temporäre Memory-Mapped File legen …

[Artificial Mind]

Gerade ein paar Programme von DATEV (Unternehmen Online, Steuer/Buchungskrams) installiert. Der Installer hat den Inhalt meiner PATH Variable in UPPERCASE umgewandelt. Jetzt funktioniert z. B. git nicht mehr.

[Krishty]

Deutscher IT darf man keine Admin-Rechte geben … am besten nur in einer VM ausführen.

[CodingCat]

Ich warte noch darauf, dass Windows endlich mit eingebauter Installer-Virtualisierung geliefert wird, deren Changes man reviewen, ändern, ablehnen oder annehmen kann bevor sie unwiderruflich sind.

[Chromanoid]

+1 Das sollte doch nicht so schwer sein. Aber bitte nicht nur für Installer sondern für alle ausführbaren Dateien. Ich will einen hübschen Dialog, der die Änderungen Schritt für Schritt auflistet und mir den Dialog bei jeder neuen Änderung [auch einzelne Netzwerkzugriffe] nach vorne holt (mit der Möglichkeit "... für diese Sitzung immer zulassen"). Auf diesen binären "zulassen"-Dialog würde ich gerne verzichten. Alles was rollback-fähig ist will ich dann am Ende der Ausführung zurücksetzen können (gerne mit Expertenmodus für das anklicken einzelner Änderungen).

Gibt's das eigentlich schon für Linux? Da finde ich die Änderungen immer ziemlich schwer zu überblicken (sicher auch weil ich selten Linux einsetze, ich könnte deshalb wahrscheinlich auch nur wenig mit den Änderungen anfangen)...

[Artificial Mind]

Gibt's das eigentlich schon für Linux?

Das ist in den meisten Fällen Aufgabe des Package-Managers. Die Frage ist also ob aptitude/apt-get/dpkg/emerge/... das können.
Bei emerge (Gentoo) weiß ich, dass das geht. Da wird das komplette Paket erstmal in einem Temp-Verzeichnis gebaut und dann kann man optional sehen welche Dateien kopiert und welche Skripte (zum installieren) ausgeführt werden. Die meisten Konfig-Dateien sind "geschützt", was bedeutet, dass man sie manuell mergen muss (git-style) falls sich etwas verändert.

[Chromanoid]

Und bekommt man damit auch einigermaßen komfortabel Laufzeit Sachen wie URL Zugriffe mit? Die meisten Anti-Virenprogramme können solche Späße nur sehr dürftig erkennen.

[Artificial Mind]

Ne, das nicht, ich hatte jetzt nur an "Installer" gedacht.

[CodingCat]

Können wir jetzt bitte virtualisierten Grafikspeicher haben? Dann könnte man die Textur teilen wie alles andere auch – in eine temporäre Memory-Mapped File legen …

So ein Zufall, ab 17 Uhr läuft die Keynote der von NVIDIA veranstalteten GTC:

March 25th, 9:00 AM
It's time again for NVIDIA CEO Jen-Hsun Huang to open the annual GPU Tech Conference with a 2-hour keynote. The show's on from 9:00am to 10:50am.

- Preview of the new 20nm high-end Maxwell GPU architecture (GM10x/GeForce 8xx) with unified virtual memory.
- Amazing real-time graphics demos (as always).
- More DirectX 12 goodness.
- OpenGL goodness.
- Demos of the to-be-released CPU-optimized GeForce driver
- GameWorks demos.
- Exciting announcements.

Live Stream
http://www.twitch.tv/nvidia

Related links:
http://www.gputechconf.com