Wäre Java schneller mit anderer Speicherverwaltung?

übrigens gings anfangs ja auch darum in Java Objekte auf dem Stack anlegen zu können, was ja immer schneller geht als new, weil man nie speicherbereiche suchen oder aufräumen muss.

hustbaer

@DEvent:
Du kannst aber einen Allocator wie tcmalloc verwenden, der ordentlich auf Geschwindigkeit optimiert ist. Und einen Allocator wie den vom MSVC (bzw. HeapAlloc/HeapFree) zu übertreffen (was Geschwindigkeit angeht) ist nicht sonderlich schwer.

@WasIstSchnell: du bist ja ein ganz Schlauer. Es gibt genug Software die CPU limitiert ist.
Gerade wenn "schön" programmiert wird sind Dinge wie ein guter Optimizer und ein schneller Allocator wichtig.

@Wiss0r: Welchen Allocator hat die C++ Variante verwendet? Ohne diese Angabe ist der Hinweis ziemlich wertlos.

DEvent schrieb:

Das ist doch der Vorteil einer JVM. Man kann je nach Bedarf den GC austauschen ohne das Programm neu uebersetzen zu muessen.

es ist sicher kein vorteil wenn der entwickler sich nicht auf das laufzeitverhalten eines GC verlassen kann... wie ich schon sagte.

Gregor

Wiss0r schrieb:

Vielleicht existiert der Thread ja noch, falls ja bitte hier verlinken, würd ihn auch gerne nochmals lesen.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-70097-and-start-is-0.html

raps schrieb:

DEvent schrieb:

Das ist doch der Vorteil einer JVM. Man kann je nach Bedarf den GC austauschen ohne das Programm neu uebersetzen zu muessen.

es ist sicher kein vorteil wenn der entwickler sich nicht auf das laufzeitverhalten eines GC verlassen kann... wie ich schon sagte.

das ist aber einer der grundsätze, nach denen man in java handeln sollte. der GC kann sonstwie implementiert sein und man sollte sich erstens nicht darauf verlassen, dass er in irgendeiner bestimmten art und weise arbeitet und zweitens sollte man sogar nichtmal versuchen, den GC zu überlisten.

hab mal ein schönes beispiel gesehen, das zeigt, wie sehr man in java auf die nase fallen kann, wenn man versucht, schlauer als der GC zu sein. ging um eine bestimmte variante des object poolings. der code wurde durch pooling in der sun 1.1 jvm geringfügig schneller. mit einer neueren jvm version war der code allerdings um mehr als faktor 10 langsamer, als ein code vollständig ohne pooling.

in java ist ein "new" tatsächlich nichts böses, solange die objekte nur kurz genug existieren.

byto

raps schrieb:

DEvent schrieb:

Das ist doch der Vorteil einer JVM. Man kann je nach Bedarf den GC austauschen ohne das Programm neu uebersetzen zu muessen.

es ist sicher kein vorteil wenn der entwickler sich nicht auf das laufzeitverhalten eines GC verlassen kann... wie ich schon sagte.

Doch, denn Java wird wohl zum größten Teil für Business und Enterprise Applications eingesetzt. Dort interessiert man sich idR nicht für das Laufzeitverhalten des GC, weil die Flaschenhälse ganz woanders liegen (meistens bei der Datenbank).

Und wo die Geschwindigkeit des GC nicht ausreichend ist, setzt man halt kein Java ein. Der prozentuale Anteil der Software, wo das der Fall ist, dürfte aber recht gering sein (hardwarenahe Programmierung mal ausgeschlossen).

Konfuzius sagt: Ein Weg zu kennen, ist nicht dasselbe wie Ihn zu gehen.

hustbaer schrieb:

@Wiss0r: Welchen Allocator hat die C++ Variante verwendet? Ohne diese Angabe ist der Hinweis ziemlich wertlos.

Nö, wieso? Jetzt hat Gregor den Thread verlinkt den ich meinte und du kannst dir alles in Ruhe durchlesen

Danke Gregor!

hustbaer

@Wiss0r:
Hm.
Ich kann weder in dem hier verlinkten Thread noch in dem dort wiederum verlinkten Thread jmd. finden der das z.B. mal mit tcmalloc o.ä. probiert hätte.
Dass die Variante mit dem selbstgestrickten small object allocator recht schnell ist ist klar, der verzichtet ja auch darauf new komplett zu ersetzen (=muss mit grössen umgehen können die erst zur Laufzeit bekannt sind), und verzichtet auch auf jegliche thread-sicherheit.

Interessant wäre für mich ein Vergleich zwischen einem generischen Allokator ala tcmalloc und GC. Alles andere als einen fertigen, generischen Allokator einzubinden ist meist einfach zuviel Aufwand. Ausgenommen Fälle wo es wirklich extrem viel bringt und schön weggekapselt werden kann -- wenn man z.b. irgendwelche low-level Libraries schreibt.

hustbaer schrieb:

@Wiss0r:
Hm.
Ich kann weder in dem hier verlinkten Thread noch in dem dort wiederum verlinkten Thread jmd. finden der das z.B. mal mit tcmalloc o.ä. probiert hätte.
Dass die Variante mit dem selbstgestrickten small object allocator recht schnell ist ist klar, der verzichtet ja auch darauf new komplett zu ersetzen (=muss mit grössen umgehen können die erst zur Laufzeit bekannt sind), und verzichtet auch auf jegliche thread-sicherheit.

Interessant wäre für mich ein Vergleich zwischen einem generischen Allokator ala tcmalloc und GC. Alles andere als einen fertigen, generischen Allokator einzubinden ist meist einfach zuviel Aufwand. Ausgenommen Fälle wo es wirklich extrem viel bringt und schön weggekapselt werden kann -- wenn man z.b. irgendwelche low-level Libraries schreibt.

Dafür gibts doch die Boost.Allocators, du weißt in C++ ja wie groß deine Datenstrukturen sind.