Dankeschön für diese tiefgehende Analyse. Sollte type_info jemals zum Bottleneck werden, weiß ich jetzt, wo ich ansetzen kann. ;)Krishty hat geschrieben:[...]
Bitteschön :)
Abgesehen davon dass wir eine Lösung dafür gefunden haben, war das nicht mein Code :PKrishty hat geschrieben:… sagt der Mensch, der zur Übersetzungszeit eindeutige Typ-IDs brauchte.
Die ultimative Antwort ist: Man programmiert am besten überhaupt nicht mehr. Was man auch anfasst, ist Schrott. :-/dot hat geschrieben:Die ultimative Antwort ist: typeid verwendet man genausowenig wie dynamic_cast :P
Oh; stimmt – hatte ich nicht gelesen. Entschuldige.dot hat geschrieben:typeid in CUDA C? :lol:
Alles selber machen.CodingCat hat geschrieben:Die ultimative Antwort ist: Man programmiert am besten überhaupt nicht mehr. Was man auch anfasst, ist Schrott. :-/
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 ;)Krishty hat geschrieben:Oh; stimmt – hatte ich nicht gelesen. Entschuldige.dot hat geschrieben:typeid in CUDA C? :lol:
Wie, das muss es doch auch auf Win 7 geben?!Direct3D 11.1, was für mich den Wechsel notwendig macht.
Nun ist nur noch die Frage, wie man das interpretieren soll.http://msdn.microsoft.com/en-us/library/windows/desktop/ff476329 hat geschrieben: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).
http://msdn.microsoft.com/en-us/library/windows/hardware/br259098 hat geschrieben: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.
Here you go?Artificial Mind hat geschrieben: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.
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.Aramis hat geschrieben: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).
Bitte gibt uns doch eine Erläuterung dieser Sprachebene und welche Optimierungen ihr dadurch denn angeblich erzielt haben mögt.CodingCat hat geschrieben: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.Aramis hat geschrieben: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).
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.Aramis hat geschrieben: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.
Wie kommst du darauf, dassAramis hat geschrieben: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
Code: Alles auswählen
foreachDie 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.ermutlich bietet auch .net Ähnliches.
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.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.
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?Aramis hat geschrieben: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.Vermutlich bietet auch .net Ähnliches.
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.Aramis hat geschrieben: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.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.
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.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).
Ob du tatsächlich Voruteile hast, kann ich noch nicht entscheiden. ;) Ärgern darfst du dich natürlich.Ich denke nicht dass ich Vorurteile habe wenn ich mich darueber aergere :-)
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.Ubseht hat geschrieben:Bitte gibt uns doch eine Erläuterung dieser Sprachebene und welche Optimierungen ihr dadurch denn angeblich erzielt haben mögt.CodingCat hat geschrieben: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.Aramis hat geschrieben: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).
Ja, so koennte man es formulieren :-)GC in Java und .net ist zwar nicht das, was du gerne hättest, aber tolerabel?
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.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.
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.).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.