Anti-Jammer-Thread

[CodingCat]

Ja, der übliche Weg mit einem pch der überall inkludiert werden muss ist natürlich völliger Mist, weil damit erst recht jedes File von jedem abhängig wird. Aber zum Glück gibts ja #pragma hdrstop ;)
Hier gibts ne gute Erklärung: http://stackoverflow.com/a/293219

Ich habe in meinem pch natürlich nicht alles inkludiert, sondern nur die externen Abhängigkeiten, die von allen geteilt werden. Neue (veränderliche / projektinterne) Abhängigkeiten werden dadurch keine eingeführt.

Wie das mit dem Pragma funktionieren soll, verstehe ich jedoch nicht. Soll ich für jedes Source-File einen individuellen pch anlegen? Dann werden doch überall immer nur noch individuelle pchs erstellt und erst recht keine mehr zur Beschleunigung genutzt? Im Moment habe ich einen pch mit den grob geteilten externen Abhängigkeiten, die sich praktisch nie ändern. Und trotzdem habe ich diesen gigantischen Overhead pro Quelldatei.

[dot]

Wie das mit dem Pragma funktionieren soll, verstehe ich jedoch nicht. Soll ich für jedes Source-File einen individuellen pch anlegen? Dann werden doch überall immer nur noch individuelle pchs erstellt und erst recht keine mehr zur Beschleunigung genutzt? Im Moment habe ich einen pch mit den grob geteilten externen Abhängigkeiten, die sich praktisch nie ändern. Und trotzdem habe ich diesen gigantischen Overhead pro Quelldatei.

Naja, du musst nicht und vor allen nicht unbedingt für jedes. Du kannst so eben mehrere pch haben. Und Beschleunigung bekommst du wohl vor allem bei inkrementellen Builds, aber eben ohne dass du teuer mit einem globalen pch der alles abhängig macht bezahlen musst.
Ich musst aber gestehen dass ich, seit ich vor einiger Zeit mal zufällig in der MSDN über hdrstop gestolpert bin, noch nicht die Gelegenheit hatte es in einem richtigen Projekt auszuprobieren. Den Stackoverflow Post hab ich gerade erst gefunden und ich muss sagen, dass mir die Methode mit /FI die er in seinem Blog beschreibt noch besser gefällt, da ich den ganzen Kram damit rein ins Buildsystem verlagern kann. Imo sollte man /FI eigentlich gut mit hdrstop kombinieren können, um den Code ganz sauber zu halten. Aber um das auszuprobieren fehlt mir im Moment leider die Zeit...

[eXile]

Matheroutinen (es ekelt mich bei dem Gedanken).

Meiner bescheidenen Meinung nach rufen die eh nur SSE2-Intrinsics auf. In der Liste (unten bei „C Run-Time Routines That Are Not Available in Source Code Form“) der Funktionen, für die es keinen Quelltext gibt, sind entweder nur Funktionen, die sich wohl 1-zu-1 auf Intrinsics mappen lassen, oder exotische Funktionen, die du wohl nicht benutzt.

Inb4 ihr mich alle erschlagen wollt: Und ich finde auch inkrementelles Linken und Edit-and-Continue super, um einige (simple) Codestellen zu fixen.

[Krishty]

Matheroutinen (es ekelt mich bei dem Gedanken).

Meiner bescheidenen Meinung nach rufen die eh nur SSE2-Intrinsics auf. In der Liste (unten bei „C Run-Time Routines That Are Not Available in Source Code Form“) der Funktionen, für die es keinen Quelltext gibt, sind entweder nur Funktionen, die sich wohl 1-zu-1 auf Intrinsics mappen lassen, oder exotische Funktionen, die du wohl nicht benutzt.

Es gibt kein SSE2-Intrinsic für sin(), cos() usw. sqrt() ist die einzige komplexe Mathefunktion, die von SSE angeboten wird.

In Microsofts sin() (oder besser gesagt: in der Unterfunktion, die für Pentium 4 optimiert ist und genutzt wird, falls SSE 2 zur Verfügung steht) finden sich Labels mit sehr aussagekräftigen Namen; weshalb ich denke, dass es sich um handgeschriebenen Assembler-Text handelt.

[eXile]

Es gibt kein SSE2-Intrinsic für sin(), cos() usw. sqrt() ist die einzige komplexe Mathefunktion, die von SSE angeboten wird.

Ah, richtig. Hatte mich zu lange mit der Intel Approximate Math library rumgeschlagen. Dafür gibt's die nämlich; hatte mich von der viel zu ähnlichen Benennung verwirren lassen.

In Microsofts sin() (oder besser gesagt: in der Unterfunktion, die für Pentium 4 optimiert ist und genutzt wird, falls SSE 2 zur Verfügung steht) finden sich Labels mit sehr aussagekräftigen Namen; weshalb ich denke, dass es sich um handgeschriebenen Assembler-Text handelt.

Dann weißt du da gerade mehr als ich. So wie ich das sehe, steckt der Code in der msvcrt.lib, via dumpbin mal aus der msvcr100.dll angeschaut:

Code: Alles auswählen

…
        369  16F 00094980 __libm_sse2_asin = ___libm_sse2_asin
        370  170 00096580 __libm_sse2_asinf = ___libm_sse2_asinf
        384  17E 000A2758 __libm_sse2_sin = ___libm_sse2_sin
        385  17F 000A31A0 __libm_sse2_sinf = ___libm_sse2_sinf
…
       1378  561 00003360 asin = zzz_AsmCodeRange_Begin
       1518  5ED 000039A0 sin = zzz_AsmCodeRange_Begin
       1519  5EE 0000F280 sinh = _sinh
…

Die einzigen Referenzierungen darauf gäbe es in der cmath und math.h. Komische Labels sehe ich da aber nicht :(

[Krishty]

Lsin_smaller:
    …
Lsin_small:
    …
Lsin_piby4_noreduce:
    …
Lsin_reduce:
    …
Lpositive:
    …
Lexplediff15:
    …
Lr_small:
    and r8d,eax
    je Ladjust_region (73514EF0h)
…
(Via Debugger reingesprungen)
Sieht mir schon aus, als sei da ein Mensch am Werk gewesen. Wirklich Ahnung, wo die Labels herkommen, habe ich aber ehrlich gesagt nicht.

[eXile]

Code: Alles auswählen

>2012
>Still not doing everything with LaTeX

Ich habe endlich den rotzigen PDF-Ersteller von meiner Festplatte ausradiert. Um einfach ein paar Scans in ein PDF zu packen direkt das System zukleistern? Bitte mehr davon! Jetzt mache ich alles selbst. Was anderes als pdflatex kommt mir nicht mehr ins Haus.

[Schrompf]

Eigentlich ist die GamePad-Unterstützung unter Windows zum Jammern. Es gibt DirectInput, mit dem man alle möglichen Eingabegeräte ansprechen und auch deren Eingabemöglichkeiten abfragen kann. Laut Microsoft ist das aber deprecated. Dann gibt es XInput, was eine erz-einfache API ist, die aber für nix außer den XBox360-Controllern taugt. Und dann gibt es RawInput, was für alle möglichen Eingabegeräte taugt, aber angeblich keine Abfrage der verfügbaren Eingabemöglichkeiten erlaubt.

Jetzt habe ich OIS, was DirectInput benutzt, immerhin schon zur Abfrage des Controllers bekommen. Jetzt stellt sich heraus, der z.b. der linke Analog-Stick eine Dead Zone hat, in der ich einen Kleintransporter parken kann. Die Achsen gehen bei Vollausschlag bis 0.45, je nach Bedienung aber manchmal nur bis 0.25f. Wenn man den Stick loslässt, schwankt die Null-Stellung dagegen bis zu 0.17. So ein Bullshit habe ich noch nicht gesehen. "Analoges" Rumlaufen wird hiermit aus Splatter wieder rausgebaut, weil die Messwerte des Eingabegeräts es einfach nicht hergeben.

Aber immerhin kann man jetzt mit dem GamePad rumlaufen. Das ist mir nach dieser Odyssee durch die Chaoslandschaft der Eingabe-APIs doch einen kleinen Jubelschrei wert.

[Krishty]

Die x64-Version meines Projekts ist mindestens zehn Prozent schneller als die x86-Version …

… darauf habe ich fast ewig gewartet ~<3

[Krishty]

Ich hatte aus Versehen noch <XAudio2.h> in meinem Master Include … nun sind es nur noch 1,5 s statt 2,4.



Hach; ich möchte <D3D9.h> auch noch raus haben …

[Krishty]

Die innere Schleife einer LZ-Dekompression kollabiert zu einem einzigen rep movsb ~<3

[CodingCat]

Dies ist weder Jammer noch Anti-Jammer, mehr ein Tipp: Solltet ihr die Größe einer Struktur herausfinden wollen, ohne diese extra nachrechnen oder zur Laufzeit ausgeben zu müssen, hilft folgender Code (zumindest in MSVC, vermutlich Compiler-abhängig):

Code: Alles auswählen

template <size_t Size> struct size_error;
size_error<sizeof(StructName)> size_message; // Erzeugt einen Compiler-Fehler, der die Größe als Template-Argument ausgibt

Das neue IntelliSense verleitet zu char sizeArray[sizeof(StructName)]; mit anschließendem Mouse-Hover, um so die Größe im Tooltip ablesen zu können. IntelliSense ist jedoch nicht immer präzise und kompiliert, wenn ich mich recht erinnere, in VS2010 ausschließlich zu x86. (Krishty?)

[Krishty]

IntelliSense ist jedoch nicht immer präzise und kompiliert, wenn ich mich recht erinnere, in VS2010 ausschließlich zu x86. (Krishty?)

Yup.

————

Visual C++’ Linker ist beim Aussortieren von Abhängigkeiten selten sorgfältig; es landet wieder und wieder nutzloser Scheiß im Kompilat. __declspec(selectany) schafft da jedoch Abhilfe, indem auch Daten, deren Initialisierung nicht zur Kompilierzeit aufgelöst werden konnte, aus dem Kompilat fliegen und gefaltet werden, sofern /OPT:REF und /OPT:ICF übergeben wurden.

Da ich schon seit Monaten mit einem String-Hash kämpfe, den Visual C++ trotz Inlining einfach nicht beim Kompilieren ausgerechnet kriegt, und auch sonst sehr viel statisch vorberechne, spart mir das deftig KiB bei einer eigentlich schon ordentlich optimierten Exe.

dem data.png (5.47 KiB) 3570 mal betrachtet

————

Ich würde gern mal ein Programm entwickeln, dessen kompletter Arbeitssatz in den CPU-Cache passt. Mich würde interessieren, ob sich sehr kompakte Datenstrukturen dann lohnen. Nur eins ist klar: Mit Direct3D geht das garantiert nicht.

[eXile]

Lulz des Tages:

Code: Alles auswählen

template<unsigned int N>
void f(const char (&c)[N])
{
    for(auto i = 0u; i < N; i++)
        std::cout << c[i] << std::endl;
}

Womit ich auch 'nen Haufen sizeof(x)/sizeof(x[0]) direkt mal raushauen kann.

[dot]

:ugeek: Warum ist i ein unsigned int wenn N ein int ist? :P

[eXile]

:ugeek: Warum ist i ein unsigned int wenn N ein int ist? :P

Arg, zu viel im Code herumgeschludert. Ist korrigiert. Meinte nicht Krishty auch mal, dass Schleifen mit signed ints performanter wären als mit unsigned ints (weil Visual Studio zusätzliche Vergleiche in den Code zimmert)?

(Gerade getestet: Bei dem Code macht das null Unterschied.)

[Krishty]

Meinte nicht Krishty auch mal, dass Schleifen mit signed ints performanter wären als mit unsigned ints?

Wir befragen dazu unseren Laborcompiler Dr. Clang: In der Tat!

Das gilt nur für Schleifen mit variabler Unter- und / oder Obergrenze. Der Hintergrund ist, dass für unsigned-Typen Überläufe wohldefiniert sind; für signed aber nicht. Der Compiler darf also bei einem signed-Zähler annehmen, dass der Zähler bei mehreren Schleifendurchläufen immer größer wird (i + 1 > i), während das bei unsigned int nicht zwingend gilt.

Clang nutzt diese Möglichkeit definitiv; Visual C++ bestimmt nicht (weil dafür geschriebener Text üblicherweise viel zu sehr auf nicht-standardkonformem Verhalten wie signed-Über- und -Unterläufen aufbaut).

[kaiserludi]

Clang nutzt diese Möglichkeit definitiv; Visual C++ bestimmt nicht (weil dafür geschriebener Text üblicherweise viel zu sehr auf nicht-standardkonformem Verhalten wie signed-Über- und -Unterläufen aufbaut).

Bitte? Seit wann interessiert MSVC der Standard? Der schwert sich da doch weit weniger drum als GCC oder Clang.

[Krishty]

Schreibe ich doch – weil sicher die Hälfte der mit VC kompilierten Programme auf Sachen aufbaut wie, dass signed char(127 + 1) zu -128 überläuft, können sie sowas auch im Gegensatz zu Clang oder GCC nicht mehr zur Optimierung einsetzen. Schon, dass sie den for-Schleifenzähler nach Visual C++ 6 wieder aus dem Scope gekriegt haben, grenzt ja an ein Wunder.

Hat jemand zur Hand, wie groß ein Array in C++ maximal werden darf? size_t-Maximum oder ptrdiff_t-Maximum?

[kaiserludi]

Ah, sorry, hatte mich verlesen und gedacht, du redest davon, dass für diese Möglichkeit geschriebener Text üblicherweise viel zu sehr auf nicht-standardkonformem aufbaut.

Aber Moment. Signed values laufen doch in gcc und clang auch über und auch da gibts genug Programme, die sich darauf verlassen, dass das der Fall ist.

[Krishty]

Dann haben sie schlicht und einfach Glück (oder Pech; je nachdem, von welcher Seite man es sieht):

It is also worth pointing out that both Clang and GCC nail down a few behaviors that the C standard leaves undefined. The things I'll describe are both undefined according to the standard and treated as undefined behavior by both of these compilers in their default modes.

[…]

Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X". While these may seem trivial, these sorts of things are commonly exposed by inlining and macro expansion. A more important optimization that this allows is for "<=" loops like this:

for (i = 0; i <= N; ++i) { ... }

In this loop, the compiler can assume that the loop will iterate exactly N+1 times if "i" is undefined on overflow, which allows a broad range of loop optimizations to kick in. On the other hand, if the variable is defined to wrap around on overflow, then the compiler must assume that the loop is possibly infinite (which happens if N is INT_MAX) - which then disables these important loop optimizations. This particularly affects 64-bit platforms since so much code uses "int" as induction variables.

Ausprobiert habe ich es aber nicht. Der Artikel spricht außerdem von C; ich gehe einfach mal davon aus, dass sich C++ da nicht zu stark unterscheidet.

[kaiserludi]

It turns out that C is not a "high level assembler" like many experienced C programmers (particularly folks with a low-level focus) like to think, and that C++ and Objective-C have directly inherited plenty of issues from it.

Das in dem Zusammenhang zu schreiben, deutet schon darauf hin, dass die folgenden Beispiele auch auf C++ und objC zutreffen.

[eXile]

Oh, and I will also reveal a secret that has never been announced before.

Range-based for-loops ab VC 11 Beta.



(Und der IntelliSense-Compiler wird übrigens von einer externen Firma geschrieben.)

[eXile]

Aus Andrei Alexandrescus Vortrag (variadic variadic template templates):


Mein Gedankengang, das zu verstehen:

[Schrompf]

Ich verstehs nicht, aber die Range-based Loops allein sind mir schon ein leises "Jucheisassa" wert.

Ich habe TAGELANG gewartet, um den einsetzen zu können:

[Bergmon]

Aus Andrei Alexandrescus Vortrag (variadic variadic template templates):

Gibt es den ganzen Vortrag irgendwo im Netz?

Die Klasse sollte eine Liste von Template-Argumenten nehmen, alle mit unterschiedlicher Anzahl/Domäne von Template-Argumenten. Einzige mögliche Klammerung des Terms: variadic (variadic template) templates,
denn (variadic variadic) gibt es (noch? :lol: ) nicht als Operator/Schlüsselwort.

[kaiserludi]

Muss als Compilerentwickler Freude machen, zu debuggen, ob man das Verhalten in solchen Fällen auch richtig implementiert hat :)

[RustySpoon]

Aus Andrei Alexandrescus Vortrag (variadic variadic template templates):

Gibt es den ganzen Vortrag irgendwo im Netz?

Jupp, sehr anschauenswert! http://channel9.msdn.com/Events/GoingNa ... 2012?l=400

Runterladen würd' ich's mir allerdings auch gern, hab dann noch 'ne längere Zugfahrt vor mir. Vorschläge?

[glassbear]

Ich nehm sowas oefters mit einem Screen Capture Programm auf und schaus dann spaeter auf dem Tablet im Zug. Unter Windows geht das zum Beispiel recht einfach mit dem Windows Media Encoder.

Anleitung

Fuer Flash-Videos gibt es zum Glueck Flashgot und aehnliches =)

[CodingCat]

Mein neuer Rechner erinnert mich unweigerlich an Deep Thought. Was immer ich auch tu, das arme Ding langweilt sich nur. Eventuell sollte ich ihm wenigstens einen Fernseher hinstellen.

(Leider ist noch kaum was installiert, und so langweilen wir uns zu zweit, während wir auf Festplatte und Datenhighway warten.)