Wer arbeitet aktuell mit einer .net sprache und dem netframework und wird es in

[audacia|off]

Rustiger schrieb:

Weil Algorithmen Datenstrukturen im Speicher brauchen. Diese müssen verwaltet werden. Wenn diese Verwaltung durch Willkür einer externen Instanz wie einem GC unterworfen wird, geht das Deterministische-Verhalten eines Teil der Arbeit mit den Datenstrukturen verloren.

Nein, warum sollte das so sein? Deinen Datenstrukturen ist die Arbeit des GC egal.

Rustiger schrieb:

Das Ziel ist doch zu jeder Zeit zu Wissen wo mein Programm gerade steht, auch für das Debugging.

Meinetwegen.

Rustiger schrieb:

Dies erreicht man nur durch durchgängigen Determinismus.

Wenn deine Algorithmen von deterministischer Ressourcenverwaltung abhängen, mußt du die Ressourcen explizit verwalten und freigeben (z.B. IDisposable oder Events). Dann spielt der GC sowieso nicht rein. Aber solange es nur um Arbeitsspeicher als Ressource geht, besteht eine solche Abhängigkeit meistens nicht.

Kurzum, von der Anwesenheit eines GC irgendwelche Schlüsse auf die allgemeine Vorhersagbarkeit von Algorithmen zu ziehen, ist sehr fragwürdig (man könnte auch sagen: Trollversuch). Es stimmt, daß der GC das Laufzeitverhalten in schwer absehbarer Weise beeinflußt, was bei zeitkritischen Anwendungen eine Rolle spielen kann (cf. Ethons Kommentar zu Spielen unter Android). Aber die Vorhersagbarkeit der Rechenergebnisse deiner Algorithmen sollte durch den GC nicht beeinträchtigt werden.

[audacia|off]

Alibikommentar zum Thema:

Zurzeit arbeite ich beruflich an verschiedenen Projekten in C#/WinForms. Das Berufliche wird sich in der nächsten Zeit noch ein paar Mal ändern, aber ich finde die Plattform sehr attraktiv und arbeite gern damit (nur WinForms nervt, da verwende ich lieber die VCL).

Von meinen privaten Projekten (die im Idealfall mal zu beruflichen Projekten werden) haben die meisten einen größeren C++-Anteil, aber ich setze auch dort zunehmend C# ein (mit .NET unter Windows und Mono unter Linux).

[asc]

hustbaer schrieb:

Bzw. auch in C# und sogar Java gibt es mehr-oder-weniger-automatische deterministische Finalisierung. Mittels "using" bzw. "try-with-resources". Ist nicht so angenehm zu verwenden wie in C++ und leider überhaupt nicht deppensicher, aber es ist da.

Es ist vor allem deshalb nicht Deppensicher, weil selbst die MSDN-Beispiele häufig kein using enthalten, wo es eigentlich hingehört - und dann muss es auch nicht verwundern das viele andere Beispiele im Netz es nicht besser tun.

Und ich kann dir aus eigener Erfahrung sagen: In C++ mag man zwar erwarten das mit RAII-Objekten "deppensicher" Programmiert werden kann, wenn diese im Team dann aber doch nicht oder gar dynamisch alloziert verwendet werden, nützt dies nichts

[Rustiger]

audacia|off schrieb:

Aber die Vorhersagbarkeit der Rechenergebnisse deiner Algorithmen sollte durch den GC nicht beeinträchtigt werden.

Um die Ergebnisse des Algos geht es auch nicht, sondern es geht darum dass ich die Implementierung Schritt für Schritt verfolgen will um Engpässen oder Fehler zu finden. Der Determinismus ist mir beim Debuggen meiner Implementierung nicht gegeben, wenn ich einen GC nutze.

[audacia|off]

Rustiger schrieb:

Um die Ergebnisse des Algos geht es auch nicht

Aha. Die Anfangsbehauptung war "Nicht-Deterministische Speicherverwaltung mit deterministischen Algorithmen macht doch überhaupt keinen Sinn". Wenn wir uns einig sind, daß die Ergebnisse vom GC unbeeinträchtigt bleiben, sind wir von "überhaupt kein Sinn" schon weit entfernt. Wenn der GC nur dein Debugging-Erlebnis beeinträchtigte, wäre das höchstens noch "im Alltag lästig".

Rustiger schrieb:

sondern es geht darum dass ich die Implementierung Schritt für Schritt verfolgen will um Engpässen oder Fehler zu finden. Der Determinismus ist mir beim Debuggen meiner Implementierung nicht gegeben, wenn ich einen GC nutze.

Immer diese unbelegten Behauptungen über schwammige Begriffe. Du wirst dich wohl kaum von einem Abstraktum wie "Determinismus nicht gegeben" beim Debuggen gehindert fühlen.

Sag doch mal, was sich konkret beim Debuggen verändert, wenn es einen GC gibt. Ein konkretes Beispiel?

[RHBaum]

@RHBaum
Wie so ein GC funktioniert kannst du an vielen Stellen im Netz nachlesen. Wenn man es in 1-2 Sätzen zusammenfasst wird es zu ungenau, und es genau zu erklären würde viel zu lange dauern. Und davon abgesehen ist natürlich auch nicht jeder GC gleich.

Das war nurn Besipiel, ich weiß wien GC grob funktioniert, und das es unterschiede im Detail gibt.

Eher erschreckt mich, wie wenig Sorgen man sich um Speicherverbrauch, Laufzeitverhalten und so macht ... ^^

Ciao ...

[Rustiger]

audacia|off schrieb:

Ein konkretes Beispiel?

Bei jeglicher Optimierung eines Algos. Du weist schon das RAM-Zugriffe zu meiden sind wo es nur geht? Nur was im Cache bearbeitet werden kann ist wirklich schnell, bei allem anderen dreht die CPU Däumchen.

Ich habe aber hier keine Lust dir das Programmieren zu erklären, da gibt es zig Videos auf Youtube die das besser können. Bei einem GC hast du nicht die Kontrolle über den Programmfuß, zu dem auch immer Speicheranforderung und Freigabe gehört. Aus ganz vielen Threads hier kannst du raus lesen, wie gefährlich es ist sich NICHT um die Speicherverwaltung selbst zu kümmern. Da wird auch erklärt warum und dass es eigentlich so gut wie unmöglich ist ein Projekt was sich nie um Speicher gekümmert hat und dann versagt im Nachhinein noch zu kitten. Du kannst eben nicht immer nachvollziehen wie und wann der GC zuschlägt.

Hier hat Xin mal was darüber geschrieben : https://www.proggen.org/doku.php?id=start:cppjava

[audacia|off]

Rustiger schrieb:

Ich habe aber hier keine Lust dir das Programmieren zu erklären

Ich habe um ein Beispiel gebeten. Daß du darauf enerviert und mit einer Herablassung antwortest, deute ich mal so, daß dir keines einfällt

Rustiger schrieb:

Bei einem GC hast du nicht die Kontrolle über den Programmfuß

Schon wieder so eine allgemeine Behauptung. Klar hast du das.

Rustiger schrieb:

Aus ganz vielen Threads hier kannst du raus lesen, wie gefährlich es ist sich NICHT um die Speicherverwaltung selbst zu kümmern.

Das gilt mit GC genau wie ohne. Ein GC bedeutet keineswegs, daß man sich überhaupt keine Gedanken über die Speicherverwaltung machen müßte. Aber die Probleme sind halt andere als ohne GC.

Rustiger schrieb:

Da wird auch erklärt warum und dass es eigentlich so gut wie unmöglich ist ein Projekt was sich nie um Speicher gekümmert hat und dann versagt im Nachhinein noch zu kitten.

Gilt auch ohne GC.

Rustiger schrieb:

Hier hat Xin mal was darüber geschrieben : https://www.proggen.org/doku.php?id=start:cppjava

Xin hat einen guten Ansatz geliefert, aber scheitert an der Realität. Kann ich leider nur bedingt ernstnehmen. Außerdem kann ich mir Pamphlete zu beliebigen Themen auch selber googlen. Ich hab dich (!) nach einem (!) konkreten (!) Beispiel gefragt.

[RHBaum]

Bei einem GC hast du nicht die Kontrolle über den Programmfuß, zu dem auch immer Speicheranforderung und Freigabe gehört.

Aber:

Die cpp Fraktion übertreibts auch oft.
Für Algos wo man wirklich flott sein muss und auch die kontrolle hat/braucht klar.
Aber für nen Grossen Teilbereich kann und braucht man das z.b. nicht.
GUI Programmierung z.b.
Ich würd z.b. nicht behaupten, das ich bei Qt (der wirkliche GUI Teil) die Kontrolle noch hab (implizietes sharing, copy on ... naja irgendwann halt, zwang zur heap allokation, verzögertes löschen).
Das fühlte sich damals schon fast an, wie Java programmieren ^^
Und da sollt man wirklich öfters überlegen, ob c++ noch ne gute Idee ist.

Besser erst mal die 90/10 Philosophie leben:
Erst mal mit der GC Sprache und billig entwickeln, das was schnell gehen muss, kann man (wenn man sauber modularisiert) später auch in was flotteres auslagern.

Ciao ...

[VitC]

Ich weiß nicht wie das C# ist, aber Java-Programme, jetzt auf den Desktop bezogen, sind immer irgendwann am Anfang seeeehr träge und wenn sie länger laufen in der Regel auch. Dazu kommt noch das Java nicht gerade mehr als sicher angesehen wird, obwohl die damaligen Fehler ja wohl recht schnell behoben wurden, aber das bleibt halt hängen, so wie Windows ist instabil und viel unsicherer als OSX usw.

Klar, wenn ich nur eine GUI für irgendwelche Masken brauchen und ein paar DB-Abfragen als Kern meine Anwendung habe, dann kann ich das sogar in Python programmieren. Mich interessieren aber Echtzeit-Grafik und auch Audio, da zählt fast jeder Takt und ich würde die Krise kriegen wenn dann plötzlich, nicht vorhersagbar, die Putzfrau rein kommt um den Speicher sauber zu machen. ICH möchte zu jeder Zeit entscheiden wann dies passiert und ob es überhaupt passiert, oft entscheide ich mich auch erst ganz zum Schluss aufzuräumen, je nach Lage halt.

[audacia]

VitC schrieb:

aber Java-Programme, jetzt auf den Desktop bezogen, sind immer irgendwann am Anfang seeeehr träge und wenn sie länger laufen in der Regel auch.

Also immer?

Ich empfinde auch viele Java-Programme als träge, aber bei näherer Betrachtung liegt das meistens am GUI, nicht an der Runtime. Desgleichen mit C# und WPF. WinForms ist relativ fix.

VitC schrieb:

aber das bleibt halt hängen, so wie Windows ist instabil und viel unsicherer als OSX usw.

Was lustig ist, denn zu der Zeit, als Windows noch instabil war (non-NT und teilweise NT 4), gab es noch kein OS X, und das damalige Mac OS war noch viel schlimmer als Windows

VitC schrieb:

Mich interessieren aber Echtzeit-Grafik und auch Audio, da zählt fast jeder Takt

Na, dann machst du das eben in C++ und benutzt die verwalteten Sprachen nur für nicht reaktionszeitkritische Anwendungen. Right tool for the job.

[VitC]

Ja, für C# und WPF kann ich nicht sprechen. Ich kann nur was zum neuen JavaFX sagen, da muss man sich nur den SceneBuilder mal anschauen und mal so mit zwanzig GUI-Elementen rumspielen, da merkt man schon dass das alles auch mal richtig träge in die Knie gehen kann. Das habe ich auch auf einem dicken i7 Desktop getestet, wo die GPU der 760GTX schon eine Menge abnehmen sollte.

Aber klar, immer das richtige Werkzeug für den richtigen Job. Meine Programmversuche wären bestimmt mit C++ auch sauberer programmiert, aber ich habe C++ immer wieder mal versucht und dann doch wieder aufgegeben. Da gibt es auch viele nette und nützliche Konzepte, aber ich bin halt so an den void Kram gewöhnt. Es fällt mir schwer das gegen die üblen Template-Fehlermeldungen einzutauschen, zu mal das eh alles privates Freizeitzeug bei mir ist.