Qualität von HotSpot Compilern

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

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.

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.

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.

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?