Jammer-Thread

[eXile]

Und was sehen wir? Visual C++ ist absolut beschissen, wenn es um Peephole-Optimization geht. Gebt denen einen schöne Breitseite auf Microsoft Connect, auch wenn sie euch eh ignorieren werden und das nicht vor Visual Studio 2023 fixen werden. Vielleicht ist bis dahin ja Clang mit Polly auch benutzbar.

[antisteo]

Und was sehen wir? Visual C++ ist absolut beschissen, wenn es um Peephole-Optimization geht. Gebt denen einen schöne Breitseite auf Microsoft Connect, auch wenn sie euch eh ignorieren werden und das nicht vor Visual Studio 2023 fixen werden. Vielleicht ist bis dahin ja Clang mit Polly auch benutzbar.

Der Sourcecode von Clang/LLVM ist sehr sauber und aufgeräumt. Man versteht ihn beim normalen Lesen. Der modulare Aufbau der LLVM erlaubt es, auch ohne Wissen über den restlichen Code, eigene Optimierungen einzubauen (selbst schon getätigt). Das Zwischencode-Ausspucken-Feature ist sehr hilfreich, um die Qualität der LLVM-Optimierungen zu bewerten oder Missing-Optimization-Bugs zu posten. Erfahrungsgemäß werden solche Bugs innerhalb von 3 Tagen geschlossen, wenn der Code in inneren Schleifen auftauchen könnte. Warum also nicht selbst Hand anpacken? Das ist doch sicherlich produktiver, als sich über andere Compiler aufzuregen.

[Krishty]

Warum also nicht selbst Hand anpacken? Das ist doch sicherlich produktiver, als sich über andere Compiler aufzuregen.

Weil Clang meine Anwendung nicht erstellen kann, deshalb. Die Win32-ABI-Unterstützung ist so gut wie nicht existent – es reicht nicht einmal fürs Kompilieren eines Release Builds um sich den Zwischentext anzusehen, weil der Compiler beim ersten throw schlicht abstürzt. Wenn ich nicht nur meine Anwendung, sondern auch ihren Compiler erst noch portieren muss, ist das nicht gerade mehr produktiv als über Visual C++ zu meckern …

[Krishty]

Java will mir die Ask Toolbar andrehen. Damit ist es endgültig Malware und wird deinstalliert.



Wo wir gerade beim Deinstallieren sind: Warum sind bei mir 24 Microsoft SQL Server-Produkte installiert?! Ich habe noch nie gesehen, dass jemand Microsofts Produktrichtlinien so krass missachtet wie das Visual Studio-Team. Ich würde die zur Briefmarke falten und entlassen dass noch deren Enkelkindern die Ohren klingeln.

[Chromanoid]

Java will mir die Ask Toolbar andrehen. Damit ist es endgültig Malware und wird deinstalliert.

Das ist so peinlich und schrecklich. Ich hoffe immer noch, dass das ne verzweifelte Aktion von Sun war und Oracle noch nicht aus dem Vertrag rauskommt.

[antisteo]

Warum also nicht selbst Hand anpacken? Das ist doch sicherlich produktiver, als sich über andere Compiler aufzuregen.

Weil Clang meine Anwendung nicht erstellen kann, deshalb. Die Win32-ABI-Unterstützung ist so gut wie nicht existent – es reicht nicht einmal fürs Kompilieren eines Release Builds um sich den Zwischentext anzusehen, weil der Compiler beim ersten throw schlicht abstürzt. Wenn ich nicht nur meine Anwendung, sondern auch ihren Compiler erst noch portieren muss, ist das nicht gerade mehr produktiv als über Visual C++ zu meckern …

Aber nach der Portierung funktioniert es. Und dann hast du so viel Freizeit, dass du dir das nächste Meckerthema suchen kannst ;)
Wir wollen ja alle das Niveau, auf dem wir meckern, steigern.

[Krishty]

Ja und wer portiert den Compiler bitteschön? Ich etwa?! Release sollte außerdem letzten Sonntag sein. Ja; unheimlich produktiv, das. So haben zumindest Cat und Schrompf gemerkt, wie sie ihren Maschinentext verbessern können.

[Chromanoid]

Java will mir die Ask Toolbar andrehen. Damit ist es endgültig Malware und wird deinstalliert.

Das ist so peinlich und schrecklich. Ich hoffe immer noch, dass das ne verzweifelte Aktion von Sun war und Oracle noch nicht aus dem Vertrag rauskommt.

Von Oracle Deutschland auf meine Anfrage: :)

[...] vielen Dank für Ihr Feedback zu Java & Ask-Toolbar!
Ich habe ihren Request/Bitte umgehend an meine Kollegin vom Java Marketing-Team in US weitergeleitet.- dieses Anliegen ist bekannt und ich hoffe das [sic] diese beiden Optionen nicht vorausgewählt bleiben. [...]

[glassbear]

Dreckige miese AMD Treiber. Mit sowas soll ich eure Produkte kaufen? :twisted:
Bitte Nvidia macht die kommende 770 vernuenftig :?

[antisteo]

Mein Telefon hat einen ekelhaften Bug:
Wenn man mit OpenGL ES 2.0 mehr als 50 glDrawArrays-Befehle absetzt, bleibt der Bildschirm leer bzw. Mut der ClearColor gefüllt. Tritt mit Java und Firefox-WebGL auf.
So macht es keinen Spaß und ich verschwende meine Zeit mit Workarounds, die eh nicht funktionieren.

[Krishty]

Telefon und OpenGL in einem Satz.

[Artificial Mind]

Could NOT find Qt4 (missing: QT_QT3SUPPORT_LIBRARY) (found version "4.8.3")

[eXile]

Dreimal dürft ihr raten, welche Visual-Studio-Version noch nicht unterstützt wird:

[dot]

Langsam wirds echt Zeit für einen Facepalm Smiley...

[eXile]

Und kaum habe ich auf den 310.90er WHQL aktualisiert, gibt's im Firefox bei Flash-Videos beim Scrollen wieder Artefakte.

Und wenn ich einen Screenshot machen will, sind sie auf dem Screenshot nicht zu sehen.

[Krishty]

Ich will einen Speichern unter...-Dialog in meine Engine einbinden. Dafür habe ich GetSaveFileName() genutzt und das funktioniert sowohl vorbildlich als auch einfach und schnell.

Nur dummerweise bindet es Comdlg32.dll ein. Das an sich ist schon 460 KiB groß; bindet aber zusätzlich noch Shell32.dll ein – und das mit seinen 10+ MiB sorgt dann endgültig dafür, dass sich der benötigte Maschinentext bei der Ausführung fast verdoppelt, nur für diesen scheiß Dialog!

Nun ist so ein Dialog ja eine endlos zeitaufwändige Sache, weil der Anwender ja erst darauf reagieren muss. Der Plan ist also, Comdlg32.dll erst beim ersten Aufruf des Dialogs zu laden. Jetzt bin ich aber irritiert bezüglich DLL Injection, weil SetDLLDirectory() erst mit XP SP1 eingeführt wurde, und ich nicht weiß, ob das alle Nutzer haben.

tl;dr: Alles ist fett und aufgeblasen und macht mir damit das Leben schwer

[dot]

Wie genau gibt's das, dass eine dll die Größe deiner Binary dermaßen beeinflussen kann!?

[Krishty]

Nicht die Größe der Binary. Die Gesamtmenge an Programmtext, der zur Ausführung der Binary geladen werden muss.

[dot]

Seh leider immer noch nicht, wo genau das Problem liegt, ich mein Zeug wie Comdlg32.dll und Shell32.dll ist ja wohl ganz sicher schon geladen, lange bevor dein Programm gestartet wird...

[Krishty]

Ich mag mich irren, aber bedeutet Address Space Layout Randomization nicht, dass ich eine private Kopie bekomme, weil die Adressen gepatcht werden? Die statische Initialierung der Dinger wird ebenso wiederholt … außerdem wird im Debug-Build nach Debug-Symbolen gesucht. Überhaupt sind es mehr Allokationen; mehr Komplexität; viel Kram, den ich nicht immer brauche oder will. Ich habe eben nachgeschlagen und an Images werden nun 42.800 KiB geladen statt 27.200; ein Zuckerschlecken ist das nicht gerade …

Ja; es wird gepatcht. Und das hier ist aus einem zusammenhanglosen CLR-Artikel, zeigt aber gut, warum viele DLLs schädlich sind:

This can be a very expensive operation because the loader has to update all addresses referring to locations within the DLL based on the new address where the DLL is loaded. From a performance point of view, this is bad because the OS loader has to read every page that contains an address, and once a page is written to, it becomes private to that process: the page now needs to be backed by the page file. In addition, cold startup time is impacted because there is a CPU cost associated with updating the DLL addresses, and there is more disk access because more pages must be touched.

[j.klugmann]

ALSR ist multidimensional und deckt viele Schichten ab:
* Zufällige Platzierung von Stack/Heap im Prozessspeicher
* PEB/TEB werden zufällige platziert
* PE-Dateien können unabhängig vom eigentlichen Code an jegliche Stellen in den virtuellen als auch physischen Speicher geladen werden.

Unter Windows 7 und 8 bildet ein Lagged Fibonacci Zufallsgenerator die Basis des ganzen Systems.

Um weitere Nebeneffekte von zusätzlichen Bibliotheken zu blocken, solltest du Dir vielleicht folgende Funktion angucken:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

Edit: Base Relocation ist üblicherweise sehr fix. Referenzierung einer Page normalerweise ebenso.

[Krishty]

Netter Trick. Meine DLLs werden aber vor der Ausführung meines Texts geladen; und dann werden auch alle Threads erzeugt …

Wo wir gerade bei Threads sind: Ich arbeite mit reserviertem Stack, weil ich fast alle Allokationen darauf tätige. Nervig ist, dass die anderen Threads meines Prozesses (Windows’ Thread Pool; der Grafiktreiber; …) mit derselben reservierten Größe starten, und deshalb 130 MiB draufgehen, obwohl nur ca. 20 benutzt werden. Das ist kein Leistungsproblem, weil der ungenutzte Stapelspeicher niemals berührt wird. Trotzdem igitt …

[dot]

Ich mag mich irren, aber bedeutet Address Space Layout Randomization nicht, dass ich eine private Kopie bekomme, weil die Adressen gepatcht werden?

Ja; es wird gepatcht. Und das hier ist aus einem zusammenhanglosen CLR-Artikel, zeigt aber gut, warum viele DLLs schädlich sind: [...]

Und das Zitat da bezieht sich wirklich auf ASLR oder einfach nur auf Relocation allgemein? So wie ich das im Moment verstehe, funktioniert ASLR in Windows nämlich so, dass der Loader jedes Modul beim ersten Laden für eine zufällig ausgewählte Addresse relocated. Am Ende kann man sich das effektiv dann mehr oder weniger einfach so vorstellen, als ob die Preferred Base Address für jedes Image dynamisch beim ersten Laden gewählt würde, anstatt statisch in Form von mehr oder weniger informiertem Raten seitens des Programmiers. Wenn man diesem Herren glauben darf, hat dies sogar tatsächlich den netten Nebeneffekt, kompaktere Addressräume zu produzieren und ich könnte mir vorstellen, dass es gleichzeitig auch die Wahrscheinlichkeit von Base Address Konflikten senkt und damit sogar hilft, Image Relocation zu vermeiden. Es wird jedenfalls nicht jedes Image für jeden Prozess neu relocated und daher gibt's auch keine privaten Kopien und what not. Abgesehen davon ist der Windows Loader afaik so intelligent, nur die Pages eines Image, die auch tatsächlich gerade benötigt werden, erst on the fly beim Mappen zu relocaten und ins Page File muss da prinzipiell auch nix, weil ich die Page auch einfach neu relocaten kann...

Für mich siehts jedenfalls im Moment eher so aus, dass ASLR der Systemperformance sogar potentiell förderlich ist...

Die statische Initialierung der Dinger wird ebenso wiederholt [...]
[...] außerdem wird im Debug-Build nach Debug-Symbolen gesucht.

Die Frage ist halt, inwiefern das eine Rolle spielt...

Ich habe eben nachgeschlagen und an Images werden nun 42.800 KiB geladen statt 27.200; ein Zuckerschlecken ist das nicht gerade …

Tatsächlich neu geladen oder insgesamt gemapped?

Abgesehen davon möchte ich auch noch darauf hinweisen, dass sich die genannten Overheads wohl so oder so nicht vermeiden lassen, ganz egal wie du die Libraries linkest...

Wo wir gerade bei Threads sind: Ich arbeite mit reserviertem Stack, weil ich fast alle Allokationen darauf tätige. Nervig ist, dass die anderen Threads meines Prozesses (Windows’ Thread Pool; der Grafiktreiber; …) mit derselben reservierten Größe starten, und deshalb 130 MiB draufgehen, obwohl nur ca. 20 benutzt werden. Das ist kein Leistungsproblem, weil der ungenutzte Stapelspeicher niemals berührt wird. Trotzdem igitt …

Vielleicht könntest du die Stacksize explizit nur für ausgewählte Threads beim CreateThread() wählen und ansonsten den System Default verwenden!?

[antisteo]

Ausgerechnet jetzt, wo ich updaten wollte, ist der LLVM-Server down for maintainence.

Mit folgendem Script werde ich automatisch wachgerüttelt, wenn der Server wieder da ist

Code: Alles auswählen

until svn update ; do sleep 10 ; done ; printf "\a";sleep 0.1;printf "\a";sleep 0.3;printf "\a";sleep 0.1;printf "\a";sleep 0.1;printf "\a"

[Krishty]

@dot: Du hast recht: Die Basisadressen einer System-DLL sind tatsächlich für jeden Prozess identisch! Feinfein; aber warum verlängert sich dann überhaupt noch die Ladezeit einer Anwendung mit vielen DLLs?

Wo wir gerade bei Threads sind: Ich arbeite mit reserviertem Stack, weil ich fast alle Allokationen darauf tätige. Nervig ist, dass die anderen Threads meines Prozesses (Windows’ Thread Pool; der Grafiktreiber; …) mit derselben reservierten Größe starten, und deshalb 130 MiB draufgehen, obwohl nur ca. 20 benutzt werden. Das ist kein Leistungsproblem, weil der ungenutzte Stapelspeicher niemals berührt wird. Trotzdem igitt …

Vielleicht könntest du die Stacksize explizit nur für ausgewählte Threads beim CreateThread() wählen und ansonsten den System Default verwenden!?

Ja; wäre eine Möglichkeit. Unterscheidet sich der Hauptprozess einer Anwendung irgendwie von Threads, die via CreateThread() erzeugt wurden? Ich müsste dann nämlich tatsächlich die komplette main() in einen eigenen Thread auslagern, und habe keine Lust, dass am Ende irgendwas mit COM / DirectX / Windows-Nachrichten schiefgeht …

[dot]

@dot: Du hast recht: Die Basisadressen einer System-DLL sind tatsächlich für jeden Prozess identisch! Feinfein; aber warum verlängert sich dann überhaupt noch die Ladezeit einer Anwendung mit vielen DLLs?

Ja, das ist eine gute Frage. Wieviel macht es denn zeitlich aus? Lädt deine Anwendung vielleicht viele third-party dlls oder sowas, die eben evtl. erst relocated bzw. halt randomisiert werden müssen!?

Afaik gilt das übrigens nicht nur für System-DLLs sondern funktioniert für alle Images gleich. Wenn du also z.B. mehrere Instanzen deiner exe startest, wird die Binary in allen an die gleiche Addresse gemapped werden. Für den Sicherheitsaspekt des Ganzen ist das aber völlig ausreichend, da nach dem nächsten Reboot ja alles anders sein kann, die Implementierung ist so aber praktisch völlig frei von Overhead...

Wo wir gerade bei Threads sind: Ich arbeite mit reserviertem Stack, weil ich fast alle Allokationen darauf tätige. Nervig ist, dass die anderen Threads meines Prozesses (Windows’ Thread Pool; der Grafiktreiber; …) mit derselben reservierten Größe starten, und deshalb 130 MiB draufgehen, obwohl nur ca. 20 benutzt werden. Das ist kein Leistungsproblem, weil der ungenutzte Stapelspeicher niemals berührt wird. Trotzdem igitt …

Vielleicht könntest du die Stacksize explizit nur für ausgewählte Threads beim CreateThread() wählen und ansonsten den System Default verwenden!?

Ja; wäre eine Möglichkeit. Unterscheidet sich der Hauptprozess einer Anwendung irgendwie von Threads, die via CreateThread() erzeugt wurden? Ich müsste dann nämlich tatsächlich die komplette main() in einen eigenen Thread auslagern, und habe keine Lust, dass am Ende irgendwas mit COM / DirectX / Windows-Nachrichten schiefgeht …

Unter Windows sind afaik alle Threads gleich, d.h. es gibt keinen ausgezeichneten Hauptthread, der speziell behandelt wird, wie das vielleicht unter manch anderen Betriebssystemen der Fall ist. Problem könnte nur sein, dass das OS oder die CRT im Caller der main() Funktion ein implizites ExitProcess() machen, main() also den ganzen Prozess mitnimmt, wenn es returned, sodass du im schlimmsten Fall den Thread terminaten musst, was natürlich auch wieder nicht die feine englische Art ist. Bezüglich COM und so musst du wohl nur aufpassen, dass du CoInitializeEx() etc. im richtigen Thread aufrufst, wenn du also in main direkt in einem neuen Thread weitermachen willst, dann solltest du in main() wohl besser nix andres tun, als nur den Thread erzeugen und auf keinen Fall noch irgendwelche Library Calls oder so absetzen, aber das ist dir wohl eh klar. Und bei Konstruktoren statischer Variablen evtl. auch aufpassen, in welchem Thread die laufen...

[Krishty]

@dot: Du hast recht: Die Basisadressen einer System-DLL sind tatsächlich für jeden Prozess identisch! Feinfein; aber warum verlängert sich dann überhaupt noch die Ladezeit einer Anwendung mit vielen DLLs?

Ja, das ist eine gute Frage. Wieviel macht es denn zeitlich aus? Lädt deine Anwendung vielleicht viele third-party dlls oder sowas, die eben evtl. erst relocated bzw. halt randomisiert werden müssen!?

Bei mir ist es nicht messbar da im Hundertstelsekundenbereich; bei anderen Anwendungen (Stichwort: MFC) ist es aber deutlich spürbar.

Unter Windows sind afaik alle Threads gleich, d.h. es gibt keinen ausgezeichneten Hauptthread, der speziell behandelt wird, wie das vielleicht unter manch anderen Betriebssystemen der Fall ist. Problem könnte nur sein, dass das OS oder die CRT im Caller der main() Funktion ein implizites ExitProcess() machen, main() also den ganzen Prozess mitnimmt, wenn es returned, sodass du im schlimmsten Fall den Thread terminaten musst, was natürlich auch wieder nicht die feine englische Art ist.

Die feine englische Art ist der gesamte Trick nicht, aber da mir die CRT gehört, sollte das kein Problem sein.

Bezüglich COM und so musst du wohl nur aufpassen, dass du CoInitializeEx() etc. im richtigen Thread aufrufst, wenn du also in main direkt in einem neuen Thread weitermachen willst, dann solltest du in main() wohl besser nix andres tun, als nur den Thread erzeugen und auf keinen Fall noch irgendwelche Library Calls oder so absetzen, aber das ist dir wohl eh klar. Und bei Konstruktoren statischer Variablen evtl. auch aufpassen, in welchem Thread die laufen...

Genau; die K’toren könnten zum Problem werden. Aua.

————

Unverwandt:
template < template <typename> class_
stupid stupid Visual Studio won't let me hit Tab

und typename darf ich nicht schreiben, denn dann kommt

    error C2988: unrecognizable template declaration/definition
    error C2059: syntax error : '<L_TEMPLATEDECL>'

Ist es eigentlich sooo schwer, ein Perl-Script zu schreiben, das alle C++-Schlüsselwörter mit zufälligen Variablennamen zufällig aneinanderreiht und dann wochenlang testet, ob für jeden Fall eine Fehlermeldung existiert?

[Krishty]

case WinAPI::MessageType::mouseWheelMoved:
    return ScrollingConcept<Context>::onScrolled(hWnd, wParam, lParam);

error C2039: 'onScrolled' : is not a member of 'Concepts::CursorMovement::DispatchDelta<Context>'
    while compiling class template member function 'SignedAddress WindowWithContext<Context,CursorMovementConcept,ScrollingConcept>::windowProcedure(WinAPI::WindowHandle,const WinAPI::MessageType::Value,const UnsignedAddress,const SignedAddress)'
        with
        [
            Context=ViewerWindow,
            CursorMovementConcept=Concepts::CursorMovement::DispatchDelta,
            ScrollingConcept=Concepts::Scrolling::DispatchDelta
        ]

Häh? In der Zeile steht ScrollingConcept<Context>::onScrolled(). Das ist laut Meldung definiert als Concepts::Scrolling::DispatchDelta::onScrolled(). Warum sucht er in Concepts::CursorMovement::DispatchDelta, das in dem völlig anderen Template-Template-Parameter liegt?!

Nachtrag: Sobald ich den Namen von einer der beiden Klassen ändere, geht es. Ich bekomme gerade die richtig üble Befürchtung, dass Visual C++ immer nur das letzte Stück des Namens nimmt, wenn es eine Überladung sucht …

[Krishty]

FUCK

Code: Alles auswählen

namespace One {

	template <typename T> struct SameName {

	};

}

namespace Two {

	template <typename T> struct SameName {
		static void function();
	};

}

template <
	template <typename> class SameNameA,
	template <typename> class SameNameB
> struct Bad
	: public SameNameA<int>
	, public SameNameB<int>
{

	static void methodWTF() {
		return SameNameB<int>::function();
	}

};

auto * x = &Bad<One::SameName, Two::SameName>::methodWTF;

error C2387: 'SameName<int>' : ambiguous base class
    could be 'One::SameName<T>'
    with
    [
        T=int
    ]
    or 'Two::SameName<T>'
    with
    [
        T=int
    ]
    while compiling class template member function 'void Bad<SameNameA,SameNameB>::methodWTF(void)'
    with
    [
        SameNameA=One::SameName,
        SameNameB=Two::SameName
    ]

Das bedeutet: Visual C++ vergleicht präprozessorähnlich nur den Klassennamen – und nicht das Namespace, in dem die Klasse liegt. Ich will nicht mehr

• why
• for teh luv of gawd
   
   
   
• why

Nachtrag: Und das nur bei Template-Template-Parametern; sobald ich einfache Template-Parameter nutze, geht es …

[dot]

Ist es eigentlich sooo schwer, ein Perl-Script zu schreiben, das alle C++-Schlüsselwörter mit zufälligen Variablennamen zufällig aneinanderreiht und dann wochenlang testet, ob für jeden Fall eine Fehlermeldung existiert?

Da hat MSVC ausnahmsweise mal recht, C++ erlaubt an der Stelle kein typename, sondern nur class... ;)