- Ich habe Visual Studio 11 RC installiert und die Scheiße stellt sich per Default auf Deutsch ein.
- Ich versuche, dass Ganze auf Englisch einzustellen, aber es geht einfach nicht.
- Ich installier mir grad Visual Studio 11 RC explizit auf Englisch, damit ich es auch so nutzen kann.
Jammer-Thread
Re: Jammer-Thread
- Artificial Mind
- Establishment
- Beiträge: 802
- Registriert: 17.12.2007, 17:51
- Wohnort: Aachen
Re: Jammer-Thread
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.
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
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
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 :)
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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:
Also, das sollte die ultimative Antwort sein, warum der Compiler type_info::name() nicht zur Übersetzungszeit auflöst. Einfach unfassbar.
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
Also, das sollte die ultimative Antwort sein, warum der Compiler type_info::name() nicht zur Übersetzungszeit auflöst. Einfach unfassbar.
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
Die ultimative Antwort ist: typeid verwendet man genausowenig wie dynamic_cast :P
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
… sagt der Mensch, der zur Übersetzungszeit eindeutige Typ-IDs brauchte.
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
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.
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Richtig. Wenn ihr es macht, ist es eine Lösung; wenn es in der Sprache drin ist, ist es ein No-Go.
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
typeid in CUDA C? :lol:
Bevor das kommt, sollen die lieber mal eine annähernd ordentliche Toolchain liefern...
Bevor das kommt, sollen die lieber mal eine annähernd ordentliche Toolchain liefern...
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
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
Trotzdem ist das Ganze vermutlich immer noch 10x effizienter als alles, was C# an (Property) Reflection bietet.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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. :-/
Zuletzt geändert von Krishty am 02.06.2012, 20:04, insgesamt 1-mal geändert.
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
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:
Re: Jammer-Thread
Ich frage mich so langsam, wie ich Windows 8 jemals produktiv einsetzen soll. Fassen wir mal zusammen:
- Systemeinstellungen sind nun über drei verschiedene Menüs verteilt.
- Die Metro-Apps haben den Funktionsumfang einer gehobenen Armbanduhr.
- Diese ganzen Seitenleisten ploppen immer im unpassendsten Moment auf.
- 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.
- 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.
- Es wirkt alles nicht durchdacht. Das Metro-System fühlt sich an wie ein artifizieller Fremdkörper im Windows-System.
- Direct3D 11.1, was für mich den Wechsel notwendig macht.
- Task-Leiste nun auch über mehrere Monitore
- ?????
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
Genau so stelle ich mir das vor.
Wie, das muss es doch auch auf Win 7 geben?!Direct3D 11.1, was für mich den Wechsel notwendig macht.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Jammer-Thread
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).
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:
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.
Re: Jammer-Thread
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...
Re: Jammer-Thread
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.
- Artificial Mind
- Establishment
- Beiträge: 802
- Registriert: 17.12.2007, 17:51
- Wohnort: Aachen
Re: Jammer-Thread
Vielen Dank, genau den Link haben wir gesucht.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- dot
- Establishment
- Beiträge: 1745
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
Willkommen in der Welt der GPGPU Programmierung ;)
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Jammer-Thread
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.
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
- Establishment
- Beiträge: 8316
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
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 …
Da stand für mich fest, das niemals benutzen zu wollen. To today I can't even …
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
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).
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Jammer-Thread
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.
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.
Re: Jammer-Thread
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
foreach
Best Android Apps ;)[/b]
König der Mathematik | King of Math
Der Bro Kodex | The Bro Code
Kompetente Firma: Troubi Entertainment
König der Mathematik | King of Math
Der Bro Kodex | The Bro Code
Kompetente Firma: Troubi Entertainment
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Jammer-Thread
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.
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 :-)
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.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.
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 :-)
Re: Jammer-Thread
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 :-)
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
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).
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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Aramis
- Moderator
- Beiträge: 1458
- Registriert: 25.02.2009, 19:50
- Echter Name: Alexander Gessler
- Wohnort: 2016
- Kontaktdaten:
Re: Jammer-Thread
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.
Einen Flamewar darueber wuerde ich aber nicht fuehren wollen :-)
- Chromanoid
- Moderator
- Beiträge: 4273
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
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 :).
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 :).