Entsteht bei C++ ein theoretischer overhead?

Ringding

Optimizer, verschieben kann man leider nichts in C/C++, weil dann die Pointer darauf ungültig würden.

Das ist mir schon bekannt, aber nicht mein Problem. Hat ja keiner gesagt, dass ich nen C++ GC verwenden muss. :p
Das verträgt sich sowieso überhaupt nicht mit den Pointern. Gibt ja nicht umsonst bei MS managed C++ die Referenztypen für den managed Heap.

Foo^ myFoo = new Foo();

wer's mag...

btw, da gibt es natürlich schon Tricks. Man muss halt dann Pointer auf Pointer nehmen, dann muss man beim Verschieben nur den Pointer anpassen, der direkt auf das Objekt zeigt. Aber solange man an der Adresse rumh4x0rn kann, ist es IMHO nicht sicher, einen GC zu verwenden.

volkard

Ringding schrieb:

volkard schrieb:

ich kann kein .ps.Z lesen.

Kind, du hörst dich nach einem erfahrenen Entwickler an, und dann das?
http://www.visotech.at/~sr/CU-CS-665-93.pdf

thx.
unten hab ich die datei schon mal. kann leider kein .pdf lesen...
naja, ich schätze, den acrobat reader zu installieren, wäre jetzt mal an der zeit.

volkard

Ringding schrieb:

Bzgl GC - overhead gegenüber was? GC ist nicht automatisch langsamer - es ist sehr anwendungsabhängig. Siehe http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html + den ersten Link dort (Memory Allocation Costs in Large C and C++ Programs)

ob mit oder ohne gc. die performance des verwendete allokators ist stark abhängig von der anwendung.
vorhin wurde gesagt, daß man in c viel seltener malluc/free benutzt, weils da nicht so einfach ist. richtig! das hat zur wirkung, daß man in c lieber wenige große speicherblöcke anlegt, während man in c++ gerne für jedes popelobjekt speicher anlegt (sagt so ähnlich auch alexandrescu bei seinem small object allocator in modern c++ design). das hat natürlich krasse wirkung auf den zu verwendenden allokator. für c++ sollte man auf jeden fall nen small object allocator davorspannen.
und natürlich gibts inzwishcen auch einige leute, die zwar die sprache c benutzen aber volle pulle c++-stil. und umgegehrt gibts die leute auch, die gerademal printf/malloc durch cout/new ausgetuascht haben und fleißig c in ihren c++-compiler stecken.
mit nem angemessenen small object allocator kann man schon ne ganze menge raushauen, würde ich sagen. und den kann man ja erstmal sogar abschreiben. dann kommen natürlich uch die allokatoren zum zuge, die man dazukaufen kann. sind aber immer irgendwie stangenware. sie können nicht ganz genau an die anwendung, die man hat, angepaßt werden.
die ganzen stl-container erlauben, daß man nen eigenen allokator denen mitgibt. das ist was feines. da kann man mit fast nullaufwand auch die speicherfreigaben delayen, bis der ganze container stirbt, wenn man das mag. kann ja sein, daß man mal nen relativ kurzebigen container hat. man kann von vorn herein was für die speicherlokalität tun, was kein zugekaufter universalallokator tun könnte. wegen solcher sachen kriegt man vorläufig immer einen tick mehr speed, wenn man den allokator im source zur verfügung hat.

Optimizer schrieb:

Das ist mir schon bekannt, aber nicht mein Problem. Hat ja keiner gesagt, dass ich nen C++ GC verwenden muss. :p
Das verträgt sich sowieso überhaupt nicht mit den Pointern. Gibt ja nicht umsonst bei MS managed C++ die Referenztypen für den managed Heap.
Foo^ myFoo = new Foo();
wer's mag...

Das ist ziemlich cool. Aber es heißt gcnew nicht new. new leagt auf dem normalen Freestore an, gcnew auf dem Heap der CLR.

Allgemein finde ich C++/CLI ziemlich cool.

rüdiger

SideWinder schrieb:

Lass mich auch mal lesen du kleiner Hacker? Oder hab ich dich jetzt missverstanden

Dazu musst du kein großer Cracker sein, da idSoftware die Quellcodes ihrer Spiele nach einiger Zeit unter der GPL veröffentlicht
http://www.idsoftware.com/downloads/

Also ich kann da nichts runterladen...

rüdiger

http://www.idsoftware.com/business/techdownloads/

der_held schrieb:

Das ist ziemlich cool. Aber es heißt gcnew nicht new. new leagt auf dem normalen Freestore an, gcnew auf dem Heap der CLR.

ups stimmt, ich wollte auch schreiben:

Foo^ myFoo = __gc new Foo();

Aber stimmt, neuerdings heißt es sogar gcnew.

Eine kurze Zusammenfassung(korrigiert mich bitte, falls ich falsch liege):

Wenn ich in C++ auch char Arrays anstatt Strings und normale Arrays anstatt Container verwende, dann erreiche ich die selbe Performance wie bei C(virtuelle Methoden vergessen wir erstmal).

operator void

Hm ja. Das heißt zwar nicht, dass es unbedingt schneller ist, aber immerhin ist es das selbe (bis auf die Möglichkeit, in C99 restrict zu verwenden).

rüdiger

Eine kurze Zusammenfassung(korrigiert mich bitte, falls ich falsch liege):

Wenn ich in C++ auch char Arrays anstatt Strings und normale Arrays anstatt Container verwende, dann erreiche ich die selbe Performance wie bei C(virtuelle Methoden vergessen wir erstmal).

Nein, es geht darum, dass ein C Compiler und ein C++ Compiler den gleichen Code gleich umsetzen wird. In C++ benutzt man aber ein anderes Design für seine Anwendungen und wenn man pech hat, kann das Design eben langsammer sein, als das C Design was man wählt.

Mit der STL hat das nichts zu tun.

volkard

Wissensdurstige schrieb:

Eine kurze Zusammenfassung(korrigiert mich bitte, falls ich falsch liege):
Wenn ich in C++ auch char Arrays anstatt Strings und normale Arrays anstatt Container verwende, dann erreiche ich die selbe Performance wie bei C(virtuelle Methoden vergessen wir erstmal).

exakt.

und printf statt cout, denn printf ist schneller, obwohl! technische performancegründe für cout sprechen.
und malloc statt new. falls sie unterschiedlich implementiert sind, ist malloc für c vermutlich angemessener.
normale arrays statt container bringt immer dann speed, wenn man sich für lahme container enschieden hätte (also zu 99% der fälle).
char arrays bzw char zeiger statt strings bringen nix, wüdre ich schätzen. eher nachteile.

aber jetzt egal, was schneller oder langsamer ist, wenn du in den c++-compiler c-code steckst, wird der auch als c-code behandelt. er wird ganz genau exakt gleich schnell sein wie c-code.

darüberhinaus kannste n c++ sogar manche sacken kostenlos kriegen

template<class T,int SIZE>
class Array{
   private:
      T data[SIZE];
      Array(const Array&);
   public:
      Array(){
      }
      T& operator[](int index){
          assert(0<=index && index<SIZE);
          return data[T];
      }
};

ist so ein kamerad, der null performance kostet, also wirklich genau gleich schnell wie ein c-array ist, aber im debugmodus indexgrenzenüberprüfung bietet.
und genau wegen dieser kleinigkeiten muß man einfach nach c++ umschwenken. und wenn man gar keine virtuellen funktionen benutzt, niemals cout, niemals char-arrays oder vector. hin und wieder so ein geschenk muß man einfach annehmen.