Re: Resourcemanager - was verstehe ich da falsch?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On 26 Sep 2006 06:53:30 -0700, "Frank Dzaebel"
<tcnt.Dzaebel@xxxxxxxxxxxxxxxxxxx> wrote:

[Performance Analysis of Generics in Scientific Computing]
http://www.csd.uwo.ca/~watt/pub/reprints/2005-synasc-scigmark.pdf#search=3D=
%22MSDN%20magazine%20generics%20performance%22


*LOL* !!!

Selten so gelacht, heute abend. Mittlerweile macht sich aber nur noch
Ärger breit, das sowas veröffentlicht wird.

Aus diesem Papier kann man rein gar nichts über die
Performancevor/Nachteile von irgendwelchen Generics-Ansätzen
entnehmen.

Nur ein Beispiel:

"Our experience with Aldor has shown that procedure inlining and data
structure elimination are two essential optimizations for
high-performance generics"

Also: inlining vermeidet den overhead durch den Aufbau/Abbau von
Stackframes beim Funktionsaufruf, indem der betreffende Code literal
eingesetzt wird (vereinfachte Darstellung). Sowas macht heute jeder
Compiler durch die Bank komplett automatisch, und - wenn man's richtig
anstellt - auch noch viel mehr.

Wenn man natürlich dem Compiler dies verbietet, indem man die Routinen
in unterschiedlichen Übersetzungseinheiten anordnet, darf man sich
nacher nicht wundern, dass es eben kein inlining gibt. Dies ist
einfach durch das (sicher diskussionswürdige) Übersetzungsmodell von
C++ bedingt. Jeder ernsthafte C++ Programmierer, der wissenschaftliche
Anwendungen macht, weiß das, und handelt entsprechend.

Normalerweise steht hinter solchen Vorgehen pure Absicht (meist durch
Java-Befürworter, die die Performanz ihrer Anwendungen durch solche
Tricks in die Nähe von C++ rücken wollen) - im vorliegenden Pamphlet
kann man aber einfach von mangelnder Sprachkenntnis der Autoren
ausgehen.

Und zwar deshalb, weil im Text immer wieder - z.B. vor allem dort, wo
Speicherverwaltung angesprochen wird - eklatantes Nicht-Wissen
demonstriert wird. So genieren sich die Autoren z.B. nicht, etwa
Folgendes zu schreiben:

"In C++ the use of stack allocated objects is much faster than the
heap allocated objects. Code similar to Java, where each object ist
heap allocated, will sometimes result in worse performace for C++ than
Java."

Wahrscheinlich hat er tausende kleine Objekte in C++ allokiert und
wieder freigegeben, so wie es eben in Java üblich ist. Während jedoch
die Java Speicherverwaltung für sowas optimiert ist, müsste man das -
so man es überhaup machen will - durch eine eigene C++
Speicherverwaltung abdecken, um die in solchen Fällen katastrophale
Performanz des generischen Allokators in C++ zu vermeiden.

Also: Wir vergleichen hier eher die Effizienz der sprachinternen
Speicherverwaltungen als die Effizienz von Algorithmen oder gar ganzen
Sprachen. Merke: C++ ist nicht von sich aus schnell, sondern bietet
nur die Möglichkeit, schnellen Code zu schreiben. Dies ist ein
Unterschied. Analoges gilt insbesondere auch für C# / .NET und in
begrenztem Maße für Java,

So, das ist jetzt länger geworden als beabsichtigt - musste aber sein.


Grüße - Paule



P.S.
Vielleicht auch mal zur besseren Vorstellung:
"durch Kenntnis des Typs sind manchmal erst
Optimierungen m=F6glich"


Dies ist eine immer korrekte Aussage. Durch Kenntnis (und Verwendung!)
des Typs können bessere Optimierungen und weniger Konvertierungen
erreicht werden. Und genau hier ist z.B. noch eine der Domänen, in
denen C++ Vorteile hat.



.