Qualität von HotSpot Compilern

[Ben 04]

@rüdiger LLVM sieht sehr interessant aus! Jetzt habe ich erstmal zusammen mit GCC PGO erstmal zwei neue Spielwiesen gefunden.

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

[rüdiger]

Ben 04 schrieb:

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

Theoretisch gibt es keinen Unterschied, außer bei der Erstellung/Löschung. Aber andererseits sorgen Pointer dafür, dass viele Optimierungen nicht durchgeführt werden können.

siehe zB http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

[Artchi]

@ben04! Ja, es macht einen Unterschied. Bei Stack-Objekten muß halt die Speicherverwatung nicht "einspringen". Bei Heap-Objekten muß im Normalfall das Betriebssystem einspringen und einen Speicherbereich "suchen" und deinem new diesen zuweisen. Also, die Arbeit beim Anlegen und Zerstören von Objekten auf dem Heap ist aufwändiger. Beim Stack ist es praktisch kostenlos.

Du kannst new dann schneller machen, wenn du einen anderen Allokator benutzt, speziell für deine Anwendungsfälle. Das geht ja zum Glück bei C++. Die meisten C++-Std-Libs haben aber logischwerweise einen allgemeingültigen Allokator implementiert.

[DEvent]

rüdiger schrieb:

Ben 04 schrieb:

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

Theoretisch gibt es keinen Unterschied, außer bei der Erstellung/Löschung. Aber andererseits sorgen Pointer dafür, dass viele Optimierungen nicht durchgeführt werden können.

siehe zB http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

Die Erstellen/Loeschung ist ja ueberhaupt das was den Stack von dem Heap unterscheidet

[hustbaer]

Pointer Aliasing wurde schon erwähnt, das betrifft nicht nur Heap Objekte sondern Stack Objekte genauso. Sobald mal irgendwo die Adresse des Stack Objektes "rausgegangen ist" (an eine Funktion übergeben die der Compiler nicht analysieren kann oder will) muss er annehmen dass auch andere Zeiger auf das Objekt existieren.

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

[Gast]

Kennt C++ etwa kein restrict?

[Jester]

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.

[Simon2]

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.

[zweipunktnull]

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.

[hustbaer]

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

[Simon2]

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 !

[Undertaker]

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

[Simon2]

Undertaker schrieb:

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

Red' keinen Quatsch.

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