Qualität von HotSpot Compilern
-
hustbaer schrieb:
Der Hauptunterschied ist für mich aber immernoch dass man bei Stack Objekten eben den Heap nicht bemühen muss - denn der Heap ist halt langsam. Speziell unter Windows mit MSVC
Du meinst sicherlich die Allokation auf dem Heap, die ist langsam. Der Zugriff ist ja letztlich immer gleich schnell, egal ob Stack oder Heap.
Und ja, ich weiß dass Du das auch weißt... trotzdem haben wir immer wieder Threads, wo Leute aus Performance-Gründen ihre 130MB-Arrays auf den Stack legen wollen, weil's schneller ist.
-
Undertaker schrieb:
...
It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster...
..Naja, eigentlich müsste es heißen:
Es ist für Java-Programmierer sehr viel leichter, in C++ unperformanten Code zu schreiben.
So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.
Gruß,
Simon2.
-
Simon2 schrieb:
So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.
genau die sind alle perfekt.
-
Jester schrieb:
hustbaer schrieb:
Der Hauptunterschied ist für mich aber immernoch dass man bei Stack Objekten eben den Heap nicht bemühen muss - denn der Heap ist halt langsam. Speziell unter Windows mit MSVC
Du meinst sicherlich die Allokation auf dem Heap, die ist langsam. Der Zugriff ist ja letztlich immer gleich schnell, egal ob Stack oder Heap.
Und ja, ich weiß dass Du das auch weißt... trotzdem haben wir immer wieder Threads, wo Leute aus Performance-Gründen ihre 130MB-Arrays auf den Stack legen wollen, weil's schneller ist.Schön dass du weisst dass ich das weiss
Und wo auf der einen Seite Leute 130MB aufn Stack legen wollen, gibt's auf der anderen Seite genug Leute die 4 Byte vom Heap holen
-
zweipunktnull schrieb:
Simon2 schrieb:
So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.
genau die sind alle perfekt.
Top Diskussionsbeitrag !!
maximale Emotions- und minimaler Informationsgehalt !
-
hustbaer schrieb:
...gibt's auf der anderen Seite genug Leute die 4 Byte vom Heap holen
sieht man manchmal im c++ forum: int i = new int;
soviel auch zu simon's beitrag, dass angeblich c++ -coder ein tiefenverständnis von ihrem computer haben
-
Undertaker schrieb:
...
soviel auch zu simon's beitrag, dass angeblich ...Red' keinen Quatsch.
-
Simon2 schrieb:
Undertaker schrieb:
...
soviel auch zu simon's beitrag, dass angeblich ...Red' keinen Quatsch.
Top Diskussionsbeitrag !!
maximale Emotions- und minimaler Informationsgehalt !
-
zweipunktnull schrieb:
...
Wusste, dass Dir das gefällt !
... und danke, dass Du Undertakers Anwalt spielst: Wird ihn freuen.
-
hustbaer schrieb:
Und wo auf der einen Seite Leute 130MB aufn Stack legen wollen, gibt's auf der anderen Seite genug Leute die 4 Byte vom Heap holen
Ein Grund mehr sich zu diesem Thema differenziert zu äußern und nicht bei plumpem "Stack ist halt schneller als Heap" oder ähnlichen Allgemeinplätzen stehen zu bleiben.
-
Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.
-
Jester schrieb:
Der Zugriff ist ja letztlich immer gleich schnell, egal ob Stack oder Heap.
Für den "blanken Zugriff" hast du recht. Aber Pointer behindern den Optimizer, daher kann das Ergebnis doch langsamer sein.
include <iostream> struct A { virtual ~A() { } virtual void foo() { std::cout << "A::foo()\n"; } }; struct B : public A { virtual void foo() { std::cout << "B::foo()\n"; } }; void stack() { B b; b.foo(); } void heap() { B *b = new B; b->foo(); } int main() { stack(); heap(); }bei mir wird mit g++ -fast -mtune=G4 -mcpu=G4 -S das foo bei stack geinlined, während es bei heap einen virtuellen Funktionsaufruf gibt (der ja eigentlich unnötig ist).
Tim schrieb:
Kennt C++ etwa kein restrict?
Im TR1 gibt es dafür glaube ich ein Macro, als temporäre Lösung. Aber der Compiler meiner Wahl beherrscht restrict für C++ schon seit Ewigkeiten. Nur brauche ich das in C++ irgend wie nie, da ich dort selten mit vielen Pointern hantiere. Gibt ja immer noch Referenzen :p
@Simon2,Undertaker
Hört bitte auch hier einen Java-Flamewar aufzuziehen. Im Zweifelsfall werde ich einfach eure Beiträge in die Richtung löschen
-
rüdiger schrieb:
...
@Simon2,Undertaker....Er hat angefangen, er hat angefangen !!!
Naaaaa guuuuut .....
Gruß,
Simon2.
-
zweipunktnull schrieb:
Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.
Nö, wenn dann umgekehrt. Ich versuche Stack-Objekte zu benutzen. Geht es nicht, nehme ich Heap-Objekte.
Das man nicht einfach so immer Stackobjekte nehmen kann, ist klar. Weil sonst würde man keinen Heap brauchen.
-
zweipunktnull schrieb:
Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.
Die Frage ist bloss, wann muss es Heap sein?
boost::function z.B. - ist ganz furchtbar toll, bloss sobald der Functor grösser als ein "gebundener Member-Function Pointer" ist wird es dadurch automatisch "Heap" (1.34 - in 1.33 war sowieso noch alles "Heap", egal wie klein) - was oft nicht nötig ist.
Vor allem wenn man sowieso schon mit Templates hantiert, und nur der Bequemlichkeit halber den Functor in ein boost::function steckt.Auch findet man oft Konstrukte wo - weil's eben "schön" programmiert ist - 3 oder 4 Anforderungen vom Heap erfolgen wo eine ausreichen wäre.
Von daher macht es IMO schon Sinn sich über sowas Gedanken zu machen, ich finde das Thema nicht SO uninteressant.
Jester schrieb:
hustbaer schrieb:
Und wo auf der einen Seite Leute 130MB aufn Stack legen wollen, gibt's auf der anderen Seite genug Leute die 4 Byte vom Heap holen
Ein Grund mehr sich zu diesem Thema differenziert zu äußern und nicht bei plumpem "Stack ist halt schneller als Heap" oder ähnlichen Allgemeinplätzen stehen zu bleiben.
Wieso? Stack IST schneller als Heap, was gibt's daran zu rütteln? Dass auf dem Stack in den wenigsten Fällen 130MB Platz haben ändert daran nichts. Wären 130MB Stack verfügbar wäre es immer noch schneller diese vom Stack zu holen. Minimal schneller, wenn man einrechnet dass die 130MB auch noch irgendwo verwendet werden müssen, und das 100x länger dauert als der Overhead vom Heap, aber schneller dennoch.
Was soll daran also bitte "plump" oder gar falsch sein?
-
Artchi schrieb:
zweipunktnull schrieb:
Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.
Nö, wenn dann umgekehrt. Ich versuche Stack-Objekte zu benutzen. Geht es nicht, nehme ich Heap-Objekte...
Also ich hatte zweipunktnull genauso verstanden: "Wenn es Heap sein muss, dann Heap, sonst Stack"....
Gruß,
Simon2.
-
Simon2 schrieb:
Artchi schrieb:
zweipunktnull schrieb:
Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.
Nö, wenn dann umgekehrt. Ich versuche Stack-Objekte zu benutzen. Geht es nicht, nehme ich Heap-Objekte...
Also ich hatte zweipunktnull genauso verstanden: "Wenn es Heap sein muss, dann Heap, sonst Stack"....
So hab ichs ja auch geschrieben.
Man könnte es auch so schreiben. "Ich versuche Stack-Objekte zu benutzen. Geht es nicht, nehme ich Heap-Objekte"
-
rüdiger schrieb:
@Simon2,Undertaker
Hört bitte auch hier einen Java-Flamewar aufzuziehen. Im Zweifelsfall werde ich einfach eure Beiträge in die Richtung löschenkeine angst. es geht doch hier um hotspot compiler. das thema gehört ja sowieso zu java. ausserdem kann ich mich nicht erinnern, irgendwas negatives über java geschrieben zu haben.
