Jammer-Thread

[TDK]

1. Ich habe Visual Studio 11 RC installiert und die Scheiße stellt sich per Default auf Deutsch ein.
2. Ich versuche, dass Ganze auf Englisch einzustellen, aber es geht einfach nicht.
3. Ich installier mir grad Visual Studio 11 RC explizit auf Englisch, damit ich es auch so nutzen kann.

[Artificial Mind]

Haben wir heute morgen auch gemacht. Gleiche Reihenfolge.
Versuch mal den Full Installer (also das Installer Iso) auf Englisch zu bekommen.

Zuletzt waren wir mit einem Proxy über die USA auf der englischen Downloadseite, MSDN auf Englisch eingestellt, er sagt, er würde uns die Englische geben und der Download downloaded VS2012_RC_ULT_DEU.iso.

[CodingCat]

[...]
Bitteschön :)

Dankeschön für diese tiefgehende Analyse. Sollte type_info jemals zum Bottleneck werden, weiß ich jetzt, wo ich ansetzen kann. ;)

[Krishty]

Nullo Problemo.

Ich steige gerade durch type_info::name() durch; unglaublich, was da passiert. Was man sparen würde, wenn das zur Übersetzungszeit geschrieben würde:

• Mutexes um zu verhindern, dass mehrere Threads gleichzeitig einen Namen anfragen;
• malloc() und Konsorten natürlich;
• Das Entschlüsseln des Namens, das nicht über die Windows-Debug-API funktioniert (wo der Debugger den Namen hernimmt), sondern schön objektorientiert in einer Klasse UnDecorator passiert;
• Das Abfangen von Fehlern und Ausnahmen aller Art, die dabei fliegen können; und
• Irgendwelche Sicherheitsprüfungen bis hin zum Dr. Watson-Aufruf, falls dabei was schiefgeht

Aber hey!; wir haben 2 KiB statische Daten in der Exe gespart!!!!111einseinself

Also, das sollte die ultimative Antwort sein, warum der Compiler type_info::name() nicht zur Übersetzungszeit auflöst. Einfach unfassbar.

[dot]

Die ultimative Antwort ist: typeid verwendet man genausowenig wie dynamic_cast :P

[Krishty]

… sagt der Mensch, der zur Übersetzungszeit eindeutige Typ-IDs brauchte.

[dot]

… sagt der Mensch, der zur Übersetzungszeit eindeutige Typ-IDs brauchte.

Abgesehen davon dass wir eine Lösung dafür gefunden haben, war das nicht mein Code :P

[Krishty]

Richtig. Wenn ihr es macht, ist es eine Lösung; wenn es in der Sprache drin ist, ist es ein No-Go.

[dot]

typeid in CUDA C? :lol:

Bevor das kommt, sollen die lieber mal eine annähernd ordentliche Toolchain liefern...

[CodingCat]

Die ultimative Antwort ist: typeid verwendet man genausowenig wie dynamic_cast :P

Die ultimative Antwort ist: Man programmiert am besten überhaupt nicht mehr. Was man auch anfasst, ist Schrott. :-/

Trotzdem ist das Ganze vermutlich immer noch 10x effizienter als alles, was C# an (Property) Reflection bietet.

[Krishty]

typeid in CUDA C? :lol:

Oh; stimmt – hatte ich nicht gelesen. Entschuldige.

Die ultimative Antwort ist: Man programmiert am besten überhaupt nicht mehr. Was man auch anfasst, ist Schrott. :-/

Alles selber machen.

[dot]

typeid in CUDA C? :lol:

Oh; stimmt – hatte ich nicht gelesen. Entschuldige.

Macht ja nix. Ich hab auch nur gepostet weil ich Cat's Posting als implizite Frage ob Alternativen existieren ausgelegt hab. Der CUDA Part war dabei natürlich nebensächlich ;)

[eXile]

Ich frage mich so langsam, wie ich Windows 8 jemals produktiv einsetzen soll. Fassen wir mal zusammen:

1. Systemeinstellungen sind nun über drei verschiedene Menüs verteilt.
2. Die Metro-Apps haben den Funktionsumfang einer gehobenen Armbanduhr.
3. Diese ganzen Seitenleisten ploppen immer im unpassendsten Moment auf.
4. Den Metro/Desktop-Splitscreen kann man auch in die Tonne kloppen. Ich dachte mir vorher, hey, da kann ich ja gleichzeitig PDFs lesen und noch auf den Desktop was machen. Pustekuchen, die Splitscreenbreite kann man nicht beliebig verändern, sondern es gibt nur zwei Voreinstellungen. Auf der einen kann ich keine PDFs mehr lesen, auf der anderen nicht mehr richtig auf dem Desktop arbeiten. Grandios.
5. Der neue Startmenüersatz mit Tiles ist eigentlich ganz nett; sobald man alle Metro-Anwendungen rausgeschmissen hat, kann man sogar halbwegs brauchbar sich was zusammenbasteln.
6. Es wirkt alles nicht durchdacht. Das Metro-System fühlt sich an wie ein artifizieller Fremdkörper im Windows-System.

Auf der anderen Seite steht natürlich:

1. Direct3D 11.1, was für mich den Wechsel notwendig macht.
2. Task-Leiste nun auch über mehrere Monitore
3. ?????

[CodingCat]

Genau so stelle ich mir das vor.

Direct3D 11.1, was für mich den Wechsel notwendig macht.

Wie, das muss es doch auch auf Win 7 geben?!

[eXile]

D3D_FEATURE_LEVEL_11_1

Targets features supported by Direct3D 11.1 including shader model 5 and logical blend operations. This feature level requires a display driver that is at least implemented to WDDM for Windows 8 (WDDM 1.2).

Nun ist nur noch die Frage, wie man das interpretieren soll.

Und dieses Dokument listet auf Seite 7 in der Tabelle auf, dass es kein „D3D11.1“ für Windows 7 gibt. Wieder keine Ahnung wie man das interpretieren soll.

Und aus dem gleichen Dokument hört sich das auch nicht viel besser an:

Down level
An IHV may choose to create a unified driver package that is a WDDM 1.2 driver on Windows 8, but appears like a WDDM 1.1 or 1.0 driver on previous OS releases.

[Andre]

Heute kam endlich mein neuer Arbeitspeicher. Fast 4 Wochen haben die gebraucht um den umzutauschen. Und natürlich bekomme ich gleich ein paar Stunden nach dem Einbauen einen Bluescreen ins Gesicht gedrückt. Wenn der PC einem den Mittelfinger zeigt...

[eXile]

Zuletzt waren wir mit einem Proxy über die USA auf der englischen Downloadseite, MSDN auf Englisch eingestellt, er sagt, er würde uns die Englische geben und der Download downloaded VS2012_RC_ULT_DEU.iso.

Here you go?

[Artificial Mind]

Vielen Dank, genau den Link haben wir gesucht.

[CodingCat]

Die DirectCompute-Dispatch-API ist ein absoluter Krampf, sobald man keine Daten hat, die von Natur aus logisch in Untergruppen unterteilt sind. Also fast immer? Nun sitze ich hier mit meinen Elementzahlen irgendwo im VRAM, und muss vor jedem Dispatch ein weiteres einelementiges Dispatch losrennen lassen, nur um aus der Elementzahl bei gegebener Gruppengröße die Gruppenzahl auszurechnen und in einen UAV zu schreiben, aus dem die Zahl dann für DispatchIndirect in einen weiteren Puffer kopiert werden kann. Ich versinke in Puffern und Shadern. Es kotzt mich nur noch an, ich will auf der Stelle damit aufhören.

[dot]

Willkommen in der Welt der GPGPU Programmierung ;)

[Aramis]

Ich weiss einfach nicht, wer sich in C# (via .net compact framework) diese foreach-Schleife (bzw. genauer: IEnumerator) ausgedacht hat. Jeder Aufruf davon leaked ein Objekt und bei 1 MB Muell schaltet sich der wohl langsamste GC aller Zeiten ein und friert fuer 100ms alle Threads ein. Das laesst sich vielleicht noch loesen, ist aber auch bei weitem nicht das einzige Speicherleck.

Um die Auswirkungen zu entspannen haben wir hier eben begonnen, unsere Datenstrukturen zu ent-OOisieren, sprich dafuer geeignete Objekte auf rohe Datenarrays aufzusplitten (damit M&S schneller laeuft).

Ich assoziiere GCs immer mehr mit einem gewaltigem Monster, das man auf keinen Fall aufwecken darf.

[Krishty]

Ich erinnere mich an einen Old New Thing-Artikel, wo erklärt wurde, dass sie extra für Iteratoren yield return eingeführt haben. Das ist eine return-Anweisung, die die Funktion nicht nur abbricht, sondern dabei ihren internen Zustand speichert und später wiederherstellt.

Da stand für mich fest, das niemals benutzen zu wollen. To today I can't even …

[CodingCat]

Um die Auswirkungen zu entspannen haben wir hier eben begonnen, unsere Datenstrukturen zu ent-OOisieren, sprich dafuer geeignete Objekte auf rohe Datenarrays aufzusplitten (damit M&S schneller laeuft).

Jep, genau das macht mich immer noch sprachlos. Auch in Java hieß für uns Optimierung damals zurück auf eine Sprachebene, die noch klar unter C anzusiedeln ist.

[Ubseht]

Um die Auswirkungen zu entspannen haben wir hier eben begonnen, unsere Datenstrukturen zu ent-OOisieren, sprich dafuer geeignete Objekte auf rohe Datenarrays aufzusplitten (damit M&S schneller laeuft).

Jep, genau das macht mich immer noch sprachlos. Auch in Java hieß für uns Optimierung damals zurück auf eine Sprachebene, die noch klar unter C anzusiedeln ist.

Bitte gibt uns doch eine Erläuterung dieser Sprachebene und welche Optimierungen ihr dadurch denn angeblich erzielt haben mögt.

Ich weiss einfach nicht, wer sich in C# (via .net compact framework) diese foreach-Schleife (bzw. genauer: IEnumerator) ausgedacht hat. Jeder Aufruf davon leaked ein Objekt und bei 1 MB Muell schaltet sich der wohl langsamste GC aller Zeiten ein und friert fuer 100ms alle Threads ein. Das laesst sich vielleicht noch loesen, ist aber auch bei weitem nicht das einzige Speicherleck.

Um die Auswirkungen zu entspannen haben wir hier eben begonnen, unsere Datenstrukturen zu ent-OOisieren, sprich dafuer geeignete Objekte auf rohe Datenarrays aufzusplitten (damit M&S schneller laeuft).

Ich assoziiere GCs immer mehr mit einem gewaltigem Monster, das man auf keinen Fall aufwecken darf.

In der JVM kann man den GC konfigurieren. Man kann verschiedene GC-Strategien wählen und diese zum Teil parametrisieren. Vermutlich bietet auch .net Ähnliches. Dadurch könntest du z.B. das frühzeitige und häufige Anspringen des GC verhindern. Die meisten Anwendungen (außer z.B. Spiele wegen den gewünschten gleichmäßigen Zeitdeltas) funktionieren dann auch hervorragend mit GC.

Du solltest wohl einfach deine Vorurteile ablegen und dich einlesen. Gegen den GC zu arbeiten ist in jedem Fall in Java als auch .net nicht zu empfehlen.

[spobat]

Ich weiss einfach nicht, wer sich in C# (via .net compact framework) diese foreach-Schleife (bzw. genauer: IEnumerator) ausgedacht hat. Jeder Aufruf davon leaked ein Objekt

Wie kommst du darauf, dass

Code: Alles auswählen

foreach

leaked?

[Aramis]

Es "leaked" in dem Sinne dass IEnumerable.GetEnumerator im Normalfall ein frisches Iteratorenobjekt zurueckgibt. Dieser Iterator wird nach Ende der foreach nicht mehr gebraucht. Das sind zwar nur einige Bytes Muell, aber es ist voellig ausreichend um auf Dauer messbar viele GC-Laeufe zu produzieren.

ermutlich bietet auch .net Ähnliches.

Die Konfigurierbarkeit ist schlechter als bei der JVM (jedenfalls ist das meine bisherige Erfahrung). Es geht mir auch weniger um GCs im Allgemeinen (die Diskussion darueber ist ein Stueck weit muessig - ich halte sie fuer ein fehlgeleitetes Konzept, aber es gibt sie nunmal) als um den GC des .net Compact Frameworks. Der kennt keine Generationen (spricht, er scannt bei jedem GC-Lauf ALLES durch) und hat eine fixe Grenze von 1 MB ab der er immer anspringt. Man kann ihn vorzeitig manuell triggern, aber das nuetzt nichts wenn es einfach keinen Zeitpunkt gibt zu dem 140ms Haenger verkraftbar waeren.

Du solltest wohl einfach deine Vorurteile ablegen und dich einlesen. Gegen den GC zu arbeiten ist in jedem Fall in Java als auch .net nicht zu empfehlen.

Um es nochmal zusammenzufassen: hier im konkreten Fall verursachten bereits kleinste Stringkonkatenationen zur Laufzeit messbar viel Muell um nach ein paar Sekunden den GC zu triggern (genau wie die erwaehnten Iteratoren). 100-140 ms Ruckler alle 3 Sekunden sind fuer Programme, die auf wenigstens 25 fps laufen muessen zu keinem Zeitpunkt akzeptabel.

Jede Form sauberer Programmierung geht hier grade den Bach herunter und weicht Optimierungen die teilweise auf Annahmen ueber das interne Verhalten der Speicherverwaltung beruhen. Keine temporaeren Objekte mehr produzieren zu duerfen verringert die Produktivitaet zudem erheblich (es ist davon abgesehen, nicht einmal so als haette ich nicht schon vorher darauf optimiert - ich habe es nur zu wenig getan und einige Bytes Muell durchschluepfen lassen, die sich jetzt aufsummieren).

Ich denke nicht dass ich Vorurteile habe wenn ich mich darueber aergere :-)

[Ubseht]

Vermutlich bietet auch .net Ähnliches.

Die Konfigurierbarkeit ist schlechter als bei der JVM (jedenfalls ist das meine bisherige Erfahrung). Es geht mir auch weniger um GCs im Allgemeinen (die Diskussion darueber ist ein Stueck weit muessig - ich halte sie fuer ein fehlgeleitetes Konzept, aber es gibt sie nunmal) als um den GC des .net Compact Frameworks. Der kennt keine Generationen (spricht, er scannt bei jedem GC-Lauf ALLES durch) und hat eine fixe Grenze von 1 MB ab der er immer anspringt. Man kann ihn vorzeitig manuell triggern, aber das nuetzt nichts wenn es einfach keinen Zeitpunkt gibt zu dem 140ms Haenger verkraftbar waeren.

OK. Über das .net Compact Framework weiß ich nichts. Aber mir war nicht klar, ob du allgemein gegen GC bist oder nur im konkreten Fall. Schließe ich aus Obigen richtig, dass du der Meinung bist, GC wäre im .net Compact Framework kompletter Unsinn und GC in Java und .net ist zwar nicht das, was du gerne hättest, aber tolerabel?

Du solltest wohl einfach deine Vorurteile ablegen und dich einlesen. Gegen den GC zu arbeiten ist in jedem Fall in Java als auch .net nicht zu empfehlen.

Um es nochmal zusammenzufassen: hier im konkreten Fall verursachten bereits kleinste Stringkonkatenationen zur Laufzeit messbar viel Muell um nach ein paar Sekunden den GC zu triggern (genau wie die erwaehnten Iteratoren). 100-140 ms Ruckler alle 3 Sekunden sind fuer Programme, die auf wenigstens 25 fps laufen muessen zu keinem Zeitpunkt akzeptabel.

Sofern es im .net Compact Framework etwas dem StringBuilder oder StringBuffer aus Java ähneldem gibt, wäre dies eine Möglichkeit diese Problem sauber und sprachgerecht zu lösen.

Jede Form sauberer Programmierung geht hier grade den Bach herunter und weicht Optimierungen die teilweise auf Annahmen ueber das interne Verhalten der Speicherverwaltung beruhen. Keine temporaeren Objekte mehr produzieren zu duerfen verringert die Produktivitaet zudem erheblich (es ist davon abgesehen, nicht einmal so als haette ich nicht schon vorher darauf optimiert - ich habe es nur zu wenig getan und einige Bytes Muell durchschluepfen lassen, die sich jetzt aufsummieren).

Wie gesagt kenn ich die Kompaktversion von .net nicht. Jedoch sind zumindest in normalen Java temporäre Objekte einer der Vorteile von GC. Der GC muss schließlich solche Objekte nicht kopieren und hat daher mit Solchen nur wenig arbeit.

Ich denke nicht dass ich Vorurteile habe wenn ich mich darueber aergere :-)

Ob du tatsächlich Voruteile hast, kann ich noch nicht entscheiden. ;) Ärgern darfst du dich natürlich.

[CodingCat]

Um die Auswirkungen zu entspannen haben wir hier eben begonnen, unsere Datenstrukturen zu ent-OOisieren, sprich dafuer geeignete Objekte auf rohe Datenarrays aufzusplitten (damit M&S schneller laeuft).

Jep, genau das macht mich immer noch sprachlos. Auch in Java hieß für uns Optimierung damals zurück auf eine Sprachebene, die noch klar unter C anzusiedeln ist.

Bitte gibt uns doch eine Erläuterung dieser Sprachebene und welche Optimierungen ihr dadurch denn angeblich erzielt haben mögt.

Das Fehlen von Value Types zwang uns dazu, alle Daten in Form von Arrays primitiver Datentypen abzulegen. Aus Arrays von Objekten wurden somit viele Arrays von Objektattributen. Selbst in C kann ich Objekte in Form von structs in Arrays packen, ohne damit das Vielfache an Speicher zu verschwenden. Da obendrein Generics für primitive Datentypen nicht unterstützt werden, mussten wir uns zusätzlich noch eigene (Hash- und Queue-)Container-Klassen schreiben, die wir dann zu allem Überfluss für verschiedene primitive Typen per Copy'n'Paste vervielfältigen durften.

Davon abgesehen ist auch bei uns ein Vorberechnungsalgorithmus auf einem 48-Core-Rechner über 16 Stunden hinweg alle paar Sekunden auf 0% Auslastung gefallen. Woran das lag, konnten wir allerdings Aufgrund des stark eingeschränkten Zugangs zu diesem Rechner nicht weiter analysieren. Mein Tipp wäre auch hier der GC, da die Berechnungen davon abgesehen kaum Synchronisationspunkte enthielten.

[Aramis]

GC in Java und .net ist zwar nicht das, was du gerne hättest, aber tolerabel?

Ja, so koennte man es formulieren :-)

Sofern es im .net Compact Framework etwas dem StringBuilder oder StringBuffer aus Java ähneldem gibt, wäre dies eine Möglichkeit diese Problem sauber und sprachgerecht zu lösen.

Gibt es natuerlich - aber ist voellig nutzlos weil StringBuilder.ToString() eben doch ein neues Objekt erstellt :-) Genau das ist der Punkt: sobald der GC das Bottleneck wird, findet man sich ploetzlich im tiefsten Mittelalter wieder die meisten, an sich gut durchdachten, Sprachmittel und grosse Teile der Standardbibliotheken ploetzlich auf der Blacklist stehen.

Jedoch sind zumindest in normalen Java temporäre Objekte einer der Vorteile von GC. Der GC muss schließlich solche Objekte nicht kopieren und hat daher mit Solchen nur wenig arbeit.

Ich hab erhebliche Zweifel dass ein Mark&Sweep GC die Dekonstruktion vieler temporaerer, hochlokaler Objekte schneller hinkriegt als eine deterministische Speicherverwaltung, die einfach am Ende des Scopes den Speicher freigibt. In beiden Faellen muessen wenige, kleine und vermutlich hintereinanderliegende Speicherbloecke schnell zugewiesen und am Ende wieder freigeben werden - nur dass der GC noch zusaetzlichen Verwaltungsaufwand hat. Ein GC hat hoechstens einen etwas besseren globalen Ueberblick – wobei den auch eine deterministische Heap-Implementierung haben kann (LFH o.ae.).

Einen Flamewar darueber wuerde ich aber nicht fuehren wollen :-)

[Chromanoid]

Bei solchen Problemen ist man leider schnell auf automatische Optimierung durch Hotspot-Optimierung etc. angewiesen. Afaik werden bspw. bei String-Additionen o.Ä. in Java automatisch entsprechende StringBuilder erstellt etc. Wenn das Zeug wirklich so viel Garbage macht, kannst du dann nicht eine normale for-Schleife o.Ä. nehmen? Sicher ist das nervig und man stellt sich nicht vor auf solche Probleme zu treffen, wenn man mit solchen Sprachen entwickelt, aber das kommt halt vor.
Wenn Probleme dieser Art auftreten, sollte man sich immer fragen, ob es auch anders geht und ob die gewählte Sprache das beste Mittel ist, das Ziel zu erreichen. Auch Allzweck-Sprachen sind nicht für jeden Zweck gleich gut geeignet :).