3. Entsteht bei C++ ein theoretischer overhead?

Entsteht bei C++ ein theoretischer overhead?

  • V

    Jester schrieb:

    Wenn C-Programme das benötigen, was C++ bietet, dann haben sie dabei auch mindestens den gleichen Overhead... und sind doppelt so lang. Schonmal jemand virtuelle Methoden mit Funktionszeigern implementiert? *kotz*

    theoretisch kann man die auch mit switch implementieren. vielleicht mir arg vielen makros?
    ja, der code wird ein wenig groß. aber der code kann schneller werden, als der funktionszeigercode, weil der ganze apparat inline bleiben kann und der optimizer vollen zugriff drauf hat. funktionszeiger und virtuelle funktionen machen den optimierer leider blind an der sprungstelle.
    wenn man sehr viel zeit hat und genau weiß, was man tut, kann man in der tat in c schneller sein, wenn man es mit c++ vergleicht und einem, der es nicht drauf angelegt hat, mindestens so schnell wie der mit c zu sein.

    0
  • ?

    Ich könnte mir vorstellen, dass es (natürlich jetzt konstruiert) mit GC sehr performant wäre, in einer Schleife ständig temporäre Objekte (gerne auch unterschiedlicher Größe) zu erstellen, am Ende aber nur noch ne kleine Anzahl der Objekte zu referenzieren, bevor die Reinigung durchgeführt wird.
    Das Aufsammeln von Garbage kostet nämlich nichts (wenn es keine finalizer gibt()) und es werden bei jeder Reinigung nur die referenzierten Objekte verschoben, womit der ganze Heap wieder frei wird.

    Ich glaub, da könnte so ne verkettete Liste schon richtig abloosen, wenn die Objekte auch noch verschieden Groß sind, das Allokieren auf nem fragmentierten Heap ist nicht das schnellste.

    Jetzt zweifle ich natürlich auch nicht daran, dass du speziell für diesen Fall wieder nen schnelleren Allokator schreiben kannst. ⚠
    Wer's mag. :p

    0
  • R

    volkard schrieb:

    ich kann kein .ps.Z lesen.
    werden da auch anwendungen wie mein html-bauer gemessen? wo es niemals auf speed ankam?

    Kind, du hörst dich nach einem erfahrenen Entwickler an, und dann das?

    http://www.visotech.at/~sr/CU-CS-665-93.pdf
    (leider ist das .ps mit Pixel-Font gemacht, daher schaut das so grauslich aus)

    Was du schreibst, stimmt schon, aber man muss halt auch einen entsprechenden Aufwand reinstecken, wenn man die Sachen wirklich schnell kriegen will. In C kommt man gar nicht erst in Versuchung, so oft malloc/free zu verwenden, weil's mühsam ist. In C++ geht alles so leicht, dass man nicht groß darüber nachdenkt.

    0
  • R

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

    0
  • ?

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

    0
  • ?

    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.

    0
  • V

    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.

    0
  • V

    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.

    0
  • ?

    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.

    0
  • R

    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/

    0
  • ?

    Also ich kann da nichts runterladen... 😉

    0
  • R

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

    0
  • ?

    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.

    0
  • ?

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

    0
  • O

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

    0
  • R

    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.

    0
  • V

    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.

    0
Anmelden zum Antworten