Qualität von HotSpot Compilern

[zweipunktnull]

Simon2 schrieb:

Undertaker schrieb:

...
soviel auch zu simon's beitrag, dass angeblich ...

Red' keinen Quatsch.

Top Diskussionsbeitrag !!
maximale Emotions- und minimaler Informationsgehalt !

[Simon2]

zweipunktnull schrieb:

...

Wusste, dass Dir das gefällt !
... und danke, dass Du Undertakers Anwalt spielst: Wird ihn freuen.

[Jester]

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.

[zweipunktnull]

Die Entscheidung ob Stack oder Heap hat eigentlich garnichts mit Geschwindigkeit zu tun. Wenn es Heap sein muss, dann Heap, sonst Stack.

[rüdiger]

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

[Simon2]

rüdiger schrieb:

...
@Simon2,Undertaker....

Er hat angefangen, er hat angefangen !!!

Naaaaa guuuuut .....

Gruß,

Simon2.

[Artchi]

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.

[hustbaer]

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?

[Simon2]

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.

[zweipunktnull]

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"

[Undertaker]

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öschen

keine 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.