Der Preis von Garbage Collection - Vergleich C++ (gcc) und C# (mono)

[Gast]

http://www.geocities.com/carsten_frigaard/the_toll_of_garbage_collection.pdf
:naughty:

[Gast]

GC-Sprachen haben doch meist nur deswegen keine Zeiger(arithmetik), damit es keine versteckten Zeiger auf Objekte geben kann:

Object* a = new Object;
long ah = reinterpret_cast<long>(a)&0xFFFF0000;
long al = reinterpret_cast<long>(a)&0x0000FFFF;
a = 0; // jetzt nur noch ein versteckter Zeiger auf a vorhanden

// [...]

a = reinterpret_cast<Object*>((ah << 16) | al); // jetzt wieder da





Hab die Smilies zur besseren Lesbarkeit deaktiviert

[Demirug]

Für einen vollständigen Vergleich hätte man aber noch ein paar andere C++ Compiler und CLR-Implementierungen heran ziehen müssen.

Speed ist sicherlich nicht die Stärke einer GC. Bei einer 24/7 Anwendung ist ein GC einem C++ Heap in der Regel aber überlegen.

[ethrandil]

... und außerdem: "This page is not available."

Gibt es noch eine alternative Quelle?

- Eth

[Demirug]

Original geschrieben von ethrandil
... und außerdem: "This page is not available."

Gibt es noch eine alternative Quelle?

- Eth

Kopier den Link in ein neues Fenster. Dann geht es.

[marco42]

Original geschrieben von Demirug
Für einen vollständigen Vergleich hätte man aber noch ein paar andere C++ Compiler und CLR-Implementierungen heran ziehen müssen.

Speed ist sicherlich nicht die Stärke einer GC. Bei einer 24/7 Anwendung ist ein GC einem C++ Heap in der Regel aber überlegen.

Hmm, wie meinst du das? Gehst du jetzt von Memory Leaks aus? Es gibt viele 24/7 Anwendungen, die sind in C oder C++ geschrieben. Datenbanken, Webserver, etc.. Ein GC bietet doch vorallem den Vorteil, das man sich um den Speicher nicht mehr kuemmern muss, leider hat man dann auch keinen Einfluss mehr auf das Alignment etc..

[Demirug]

Original geschrieben von marco42
Hmm, wie meinst du das? Gehst du jetzt von Memory Leaks aus? Es gibt viele 24/7 Anwendungen, die sind in C oder C++ geschrieben. Datenbanken, Webserver, etc.. Ein GC bietet doch vorallem den Vorteil, das man sich um den Speicher nicht mehr kuemmern muss, leider hat man dann auch keinen Einfluss mehr auf das Alignment etc..

Ein C++ Heap neigt dazu im Laufe der Zeit zu fragmentieren. Das macht in zum einen immer langsamer und irgendwann ist kein Adressraum mehr verfügbar.

Ein guter GC defragmentiert den Speicher automatisch. Zudem legt er Daten die zeitlich zusammen alokiert wurden auch räumlich zusammen. Bei einem C++ Heap ist das nicht sichergestellt.

Das Alignment sollte man sowieso am besten an der CPU/Platform ausrichten. Wobei das hat ja jetzt nur noch am Rande mit einem GC zu tun.

[marco42]

Original geschrieben von Demirug
Ein C++ Heap neigt dazu im Laufe der Zeit zu fragmentieren. Das macht in zum einen immer langsamer und irgendwann ist kein Adressraum mehr verfügbar.


Da gibt es ja Moeglichkeiten das zu verhindern. Boost und Loki bieten da ein schoene Mechanismen. Das Problem stellen IMHO ja eher die Cachelines da.

Aber das mit dem Adressraum musst du mir ja noch erklaeren. 64 bit ist verdammt gross, wo geht denn da der Adressraum aus? Oder meinst du, dass man keinen Speicher mehr bekommt, der gross genug ist, da alles Fragmentiert ist. Wenn ich mich richtig erinnere gibt es da unter Linux Mechanismen. Wenn das Betriebssystem nicht mehr genug freie Pages findet, dann hilft dir auch dein GC nicht mehr weiter. Andererseits kannst du ja zu Begin mehere grosse Speichebloecke alloziieren und selbst in Pools verwalten. Dann kannst du die Fragmentierung kontrollieren, indem du fuer verchiedene Speicheranfordungsgroessen verschiedene Pools benutzt.

Wenn man wirklich was ernsthaft macht, sollte man IMHO nicht mehr das Standard new und delete benutzten, obwohl es AFAIK auch schon mallocs gibt, die da ganz schoen optimieren.


Original geschrieben von Demirug
Ein guter GC defragmentiert den Speicher automatisch. Zudem legt er Daten die zeitlich zusammen alokiert wurden auch räumlich zusammen. Bei einem C++ Heap ist das nicht sichergestellt.


Memory pools bieten da eine Loesung. Siehe oben. Da aber 24/7 Anwendungen ziemlich viel auf der Festplatten arbeiten um Persistense zu garantieren, spielt das meistens nicht eine so grosse Rolle. Datenbanken sind da eine schoenes Beispiel.

[Demirug]

Original geschrieben von marco42
Da gibt es ja Moeglichkeiten das zu verhindern. Boost und Loki bieten da ein schoene Mechanismen. Das Problem stellen IMHO ja eher die Cachelines da.

Aber das mit dem Adressraum musst du mir ja noch erklaeren. 64 bit ist verdammt gross, wo geht denn da der Adressraum aus? Oder meinst du, dass man keinen Speicher mehr bekommt, der gross genug ist, da alles Fragmentiert ist. Wenn ich mich richtig erinnere gibt es da unter Linux Mechanismen. Wenn das Betriebssystem nicht mehr genug freie Pages findet, dann hilft dir auch dein GC nicht mehr weiter. Andererseits kannst du ja zu Begin mehere grosse Speichebloecke alloziieren und selbst in Pools verwalten. Dann kannst du die Fragmentierung kontrollieren, indem du fuer verchiedene Speicheranfordungsgroessen verschiedene Pools benutzt.

Wenn man wirklich was ernsthaft macht, sollte man IMHO nicht mehr das Standard new und delete benutzten, obwohl es AFAIK auch schon mallocs gibt, die da ganz schoen optimieren.

Ich bezog mich auf 32 Bit Systeme die 64 Bit Systeme kommen ja jetzt erst so langsam im breiteren Markt.

Natürlich kann man mit indem man die Speicherverwaltung selbst übernimmt die meisten Probleme des Standardheaps umgehen. Das stellt aber eben einen nicht unerheblichen Mehraufwand dar.

Memory pools bieten da eine Loesung. Siehe oben. Da aber 24/7 Anwendungen ziemlich viel auf der Festplatten arbeiten um Persistense zu garantieren, spielt das meistens nicht eine so grosse Rolle. Datenbanken sind da eine schoenes Beispiel.

Nicht alle 24/7 Anwendungen arbeiten viel mit der Festplatte. Die an der ich gearbeitet habe macht nach dem Start (Konfiguartion laden) überhaupt nichts mehr auf der Festplatte. Dazu hat sich noch stark schwankende Speicheranforderungen und lauter Objekte unterschiedlicher Grösse. Grausam.

[marco42]

Original geschrieben von Demirug
Ich bezog mich auf 32 Bit Systeme die 64 Bit Systeme kommen ja jetzt erst so langsam im breiteren Markt.


Weil du von 24/7 sprachst, bin ich gleich mal von dicken Servern ausgegangen. Da sind ja 64 bit schon lange Standard.

[SIZE=1]Original geschrieben von Demirug
Natürlich kann man mit indem man die Speicherverwaltung selbst übernimmt die meisten Probleme des Standardheaps umgehen. Das stellt aber eben einen nicht unerheblichen Mehraufwand dar.


Na, so krass ist der auch wieder nicht wenn du zB Boost Pools verwendest. Die Sache ist durch aus verwaltbar, wenn du dann noch Shared Pointer verwendest, wird es IMHO sogar sehr comfortable.

[SIZE=1]Original geschrieben von Demirug
Nicht alle 24/7 Anwendungen arbeiten viel mit der Festplatte. Die an der ich gearbeitet habe macht nach dem Start (Konfiguartion laden) überhaupt nichts mehr auf der Festplatte. Dazu hat sich noch stark schwankende Speicheranforderungen und lauter Objekte unterschiedlicher Grösse. Grausam.

Waren das embedded Sachen oder ein Spiele server? Wann bist du eigentlich zu Spielen gekommen? Mich wuerde das mal interessieren. Mich wuerde die Branche ja eher abschrecken, wenn es da genauso wie in der Filmbranche aussieht(sehr viele Leute mit Halbwissen und sehr grossem Ego). Ausserdem bin ich wohl zu faul dazu.

[Demirug]

Original geschrieben von marco42
Na, so krass ist der auch wieder nicht wenn du zB Boost Pools verwendest. Die Sache ist durch aus verwaltbar, wenn du dann noch Shared Pointer verwendest, wird es IMHO sogar sehr comfortable.

Alles nicht so einfach wenn man massiv COM einsetzt. Da kommen sich leicht die die unterschiedlichen Ansätze ins gegehege.

Waren das embedded Sachen oder ein Spiele server? Wann bist du eigentlich zu Spielen gekommen? Mich wuerde das mal interessieren. Mich wuerde die Branche ja eher abschrecken, wenn es da genauso wie in der Filmbranche aussieht(sehr viele Leute mit Halbwissen und sehr grossem Ego). Ausserdem bin ich wohl zu faul dazu.

Für embedded ist das System eigentlich zu gross und es läuft auch auf ganz gewöhnlichen Rechnern. Es geht dabei um einen Leitwartentechnik für die Industrie. Diese Monitore mit den bunten Bildern die man öfter mal in Berichten sieht. Im speziellen um die Kommunkationsserver welche zwischen den Prozess und den eigentlichen Bedienstationen liegen. Da gibt es eine ganze Menge dumme Anforderungen die man erfüllen muss.

Zu den Spielen bin ich eigentlich schon mit 15/16 gekommen. Damals habe ich meine ersten Spiele programmiert und verkauft. Keine grossen Sachen. Da ich mich dann an grössere Projekte wagen wollte die ich aleine nicht mehr bewältigen konnte suchte ich mir Partner. Dummerweise haben dich mich immer irgendwann im Verlauf des Projekts sitzen gelassen. Dann hatte ich die Schnauze voll und bin auf Industriesoftware umgestiegen. Da mich die alte Leidenschaft aber nie ganz verlasssen hat bin ich am Ende dann doch wieder dabei gelandet.

Ich persönlich finde Industriekunden schlimmer. Aber sowas ist ja immer eine Sache des persönlichen Standpunktes.

[marco42]

Original geschrieben von Demirug
Alles nicht so einfach wenn man massiv COM einsetzt. Da kommen sich leicht die die unterschiedlichen Ansätze ins gegehege.


Ok, COM habe ich nie angefasst. Seitdem ich kein Windows mehr benutzte sind meine Nerven wesentlich besser geworden. UNIX ist auch nicht das allertollste, besondern X11 ist bescheiden. Aber Windows war mir zu black box artig.

Original geschrieben von Demirug
Für embedded ist das System eigentlich zu gross und es läuft auch auf ganz gewöhnlichen Rechnern. Es geht dabei um einen Leitwartentechnik für die Industrie. Diese Monitore mit den bunten Bildern die man öfter mal in Berichten sieht. Im speziellen um die Kommunkationsserver welche zwischen den Prozess und den eigentlichen Bedienstationen liegen. Da gibt es eine ganze Menge dumme Anforderungen die man erfüllen muss.


Oh, das klingt spannend. :-)

Original geschrieben von Demirug
Zu den Spielen bin ich eigentlich schon mit 15/16 gekommen. Damals habe ich meine ersten Spiele programmiert und verkauft. Keine grossen Sachen. Da ich mich dann an grössere Projekte wagen wollte die ich aleine nicht mehr bewältigen konnte suchte ich mir Partner. Dummerweise haben dich mich immer irgendwann im Verlauf des Projekts sitzen gelassen. Dann hatte ich die Schnauze voll und bin auf Industriesoftware umgestiegen. Da mich die alte Leidenschaft aber nie ganz verlasssen hat bin ich am Ende dann doch wieder dabei gelandet.

Ich persönlich finde Industriekunden schlimmer. Aber sowas ist ja immer eine Sache des persönlichen Standpunktes.

Ich persoenlich wuerde gern gute, intelligente Lernsoftware schreiben, aber der Markt ist ja schon immer sehr scheintod gewesen.

Computerspiele finde ich mittlerweile einfach zu bloed. Alles soll in 5 min begreifbar sein, und so spielen sie sich auch. Da suerfe ich lieber auf Wikipedia. Ich weiss noch, wie wir damals Carrier Command gespielt haben. Ueber ein Nullmodem Kabel fuer den Amiga hat das wirklich Spass gemacht.

Aber andauernd nur Leute abmurksen ist einfach nur noch langweilig. Ich denke da immer nach 5 min, ob man da nicht ein Script schreiben koennte, dass das fuer mich erledigt. :-)

[Demirug]

marco42, wir werden Offtopic.

[Trap]

Ich mag microlevel-benchmarks nicht. Vor allem dann nicht wenn die Benchmarks garnichts sinnvolles machen. Das ist dann nämlich kein Benchmark mehr wie schnell ein in dieser Programmiersprache implementierte Problemlösung ist, sondern nur wie schnell Feature-XYZ in der Programmiersprache implementiert ist. Ohne zu berücksichtigen welche Funktionalität die Sprachen in dem Feature bereitstellen.

Daher sind mir solche Benchmarks egal. In meinen Augen sinnvolle Benchmarks gibt es z.B. bei: http://www.sac-home.org/index.php?p=.%2F26_Case_Studies
Oder von mir aus auch http://dada.perl.it/shootout/ wobei das fast schon zu lowlevel ist, ich find anspruchsvollere Anwendungen aussagekräftiger.
Interessant find ich auch: http://www.flownet.com/gat/papers/lisp-java.pdf / http://www.norvig.com/java-lisp.html

[HellHorse]

Original geschrieben von Trap
...
Interessant find ich auch: http://www.flownet.com/gat/papers/lisp-java.pdf / http://www.norvig.com/java-lisp.html
Kriegt man da irgendwoher die Aufgabenstellung und die "Lösungen"?

[Trap]

Stimmt, ist etwas Arbeit das wieder zu suchen. Eine Draftversion des Originalpaper hab ich auch http://page.mi.fu-berlin.de/~prechelt/Biblio/ gefunden, das Nachfolgepaper mit TCL oder co ist zwar verlinkt aber der Link kaputt.

Merkwuerdig, dass kaum solche Studien an Unis gemacht werden.