Qualität von HotSpot Compilern
-
rüdiger schrieb:
Gibt ja mittlerweile auch bei vielen C++ Compilern die Möglichkeit das Projekt so zu kompilieren, dass das Programm Laufzeit Informationen sammelt, die man beim optimierten kompilieren dann nutzen kann. Das ist natürlich entsprechend aufwendig.
Hast du da was konkretes? Oder gibts da beim VS irgendein Tool?
-
VS *ist* das Tool. Profile Guided Optimization heisst das, und das ist es was die Leute hier mit PGO meinen.
Keine Ahnung ob das in der Express Version mit drin ist, aber die normale Professional hat das.
Ganz im Gegensatz zum Profiler der ja der Team Foundation Dings Version vorbehalten ist *grrr*.
-
Hast du da was konkretes? Oder gibts da beim VS irgendein Tool?
Habe doch die zwei Links gepostet zu den PGO-Infos.
-
Tellerrand schrieb:
Artchi schrieb:
Das macht man dann, wenn man eine Release-Version baut. Und selbst wenn das täglich ist, sowas wird (hoffentlich) automatisiert auf einem Build-Server gebaut. Was sollte ich dadurch "verlieren"?
Netter Versuch! 
Und ich dachte wir reden hier über Optimierungen zur Laufzeit
Sorry, habe gedacht du beziehst dich auf PGO.
-
thordk schrieb:
java verwendet eine sehr viel rigidere syntax als c++. das sorgt dafür, dass ein java "compiler" stärke annahmen darüber treffen kann, was wegoptimiert werden kann und was nicht.
Mir wollten sie was anderes erzählen, dass das nix mit der Syntax zu tun hat usw...
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1332096.html#1332096
Was stimmt denn nun?
-
btw. llvm will ich hier nicht unerwähnt lassen, da es bereits Link-Time-Optimierungen ermöglichst und auch JIT-Kompilierung (und das für alle Sprachen des verwendeten GCC-Frontends) und es ist in aktiver Benutzung, ua. von Apple (die wohl viel Geld in llvm stecken)) und Adobe. Derzeit werden aber leider noch keine C++-Exceptions unterstützt, was sich wohl mit llvm 2.1 (angekündigt für sept 07) ändern wird.
hier ist ein Vortrag über llvm 2.0
-
C++-Exceptions werden schon unterstützt (zumindest kompiliert ein Programm von mir mit Exceptions problemlos), im Vortrag ist aber die Rede von "Zero Cost Exception Handling", was auch immer das heißen mag.
Aber irgendwie ist der Coding-Stil von llvm suspekt. Viel zu viele Zeiger.
-
.filmor schrieb:
C++-Exceptions werden schon unterstützt (zumindest kompiliert ein Programm von mir mit Exceptions problemlos), im Vortrag ist aber die Rede von "Zero Cost Exception Handling", was auch immer das heißen mag.
Aber irgendwie ist der Coding-Stil von llvm suspekt. Viel zu viele Zeiger.
Er spricht ja auch von DWARF. Also dem Debugging-Format. Naja, was genau dahinter steckt weiß ich nicht. Ich habe mich aber auch mit LLVM noch nicht sonderlich auseinander gesetzt.
-
@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?
-
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
-
@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.
-
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
-
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?
-
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
