Auto und Smartpointer Performance
-
TNA schrieb:
volkard schrieb:
auto kostet nur zur compilezeit. zur laufzeit wird da nichts geschaut.
Auto spart sogar zur compilezeit, da nu der Typ rechts der Zuweisung ausgewertet werden muss und nicht auch noch der links davon.
Uih. Klingt voll logisch. Thx.
-
Sewing schrieb:
Was sind denn die Contras gegen einen inflationären Einsatz von auto zur Typableitung?
Doch nur die fehlende Übersicht für den Programmierer oder?Ja.
Andererseits lebe ich in anderen Sprachen ja auch damit, daß ich Variablen mit der ersten Zuweisung automatisch aushebe und daß da dann der Typ nicht steht, stört mich an diesen Sprachen am allerwenigsten.
Vielleicht sollte man volle Pulle nur auto nehmen zum Erzeugen von Variablen. FALLS man den Typen mal deutlich machen will, dann rechts.
auto posX=float(47.11);
-
SeppJ schrieb:
Der Referenzzähler eines shared_ptr ist tatsächlich thread_safe und somit möglicherweise teurer als eine nicht-threadsichere Eigenimplementierung (höchstwahrscheinlich ist der Zähler aber einfach ein atomic Datentyp).
SeppJ schrieb:
Natürlich kostet der mehr als ein unique_ptr. Ist schließlich ein ganz anderes Konzept und keine Zauberei. Aber was soll das mit Threadsicherheit zu tun haben?
Das hat viel mit Threadsicherheit zu tun, weil atomare Operationen einfach viel viel teurer sind als nicht-atomare.
OK, es gibt einige Ausnahmen wie z.B. auf x86 atomare Loads mit Acquire-Semantik bzw. atomare Stores mit Release-Semantik. Die sind nicht teurer, wenn man mal davon absieht dass sie den Optimizer behindern. Alles was read-modify-write ist, ist aber definitiv teurer. Und für Smart-Pointer ist nur read-modify-write interessant.
Konkret: Auf aktuellen "dicken" Intel CPUs (alle Pentium/Celeron/Core i seit Sandy Bridge) kostet eine atomare read-modify-write Operation ca. 20 Zyklen. Das ist viel besser als es noch zu Zeiten von Pentium 4 war (> 100 Zyklen), aber auch viel schlechter als nicht atomare Operationen (meist <= 1 Zyklus).
Der ganze Cache Coherency Tanz der da aufgeführt werden muss kostet einfach Zeit.
ps: Für viele Anwendungen ist das natürlich komplett egal. 20 Zyklen ist zwar im Vergleich mit nicht-atomaren Operationen viel, aber absolut gesehen immer noch relativ schnell. Bitte daraus also nicht ableiten dass man
shared_ptrdeswegen meiden sollte. Woshared_ptrangebracht ist, nimmt manshared_ptr. Die Performance wird dabei nur in den allerwenigsten Fällen eine Rolle spielen.
-
Ich bin dafür, daß husti mir geeignete Drogen bezahlt, damit ich ihn mir chemisch ausblenden kann.
-
hustbaer schrieb:
SeppJ schrieb:
Natürlich kostet der mehr als ein unique_ptr. Ist schließlich ein ganz anderes Konzept und keine Zauberei. Aber was soll das mit Threadsicherheit zu tun haben?
Das hat viel mit Threadsicherheit zu tun, weil atomare Operationen einfach viel viel teurer sind als nicht-atomare.
Ich bezog mich darauf, dass angedeutet wurde, dass shared_ptr deswegen langsamer wäre als unique_ptr, weil shared_ptr threadsicher ist. Dabei hat der shared_ptr vor allem erst einmal mehr/andere Funktionalität als unique_ptr und ist deswegen komplexer.
-
@SeppJ
Also es ging darum denke ichGast3 schrieb:
SmartPointer sind im Normalfall doch threadsafe (interner Counter) oder nicht?
das kostet definitiv - somit sollte ein std::shared_ptr mehr kosten als ein std::unique_ptrUnd aus meiner Sicht ist das halt einfach richtig.
Ich sehe das so:
shared_ptrmuss die Zugriffe auf den internen Counter irgendwie threadsafe machen.unique_ptrmuss das nicht (und hat auch sonst keinen erwähnenswerten Overhead).
Also mussshared_ptrlangsamer sein alsunique_ptr.Das ist und bleibt mMn. einfach wahr, ganz unabhängig davon ob man auch anders zu dem Schluss "muss langsamer sein" kommen kann.
Damit hat der Umstand dass
shared_ptrden Zugriff auf den internen Counter threadsafe machen muss sehrwohl etwas damit zu tun dass er langsamer ist/sein muss.Im Gegensatz dazu muss "ist komplexer" aber nicht automatisch immer "ist langsamer" bedeuten.
-
Die Tatsache, dass shared_ptr überhaupt einen Zähler braucht und unique_ptr nicht, ist dabei nicht erwähnenswert? Das ist doch der Unterschied überhaupt!
-
OK, verstehe.
Doch, klar ist das erwähnenswert.Macht aber die Überlegung von Gast3 mMn. immer noch nicht falsch. Vielleicht unnötig kompliziert, aber nicht falsch.
-
Macht aber die Überlegung von Gast3 mMn. immer noch nicht falsch.
Japp, aber die Konsequenz daraus sollte nicht sein, den shared_ptr als Klasse zu eliminieren, sondern 1 Stufe höher im Design, die Referenz-Zählung an sich.
Nur weil ich Instanzen auch in anderen Klassen verwende muss ich ja auch nicht üeberall Referenzzaehlung verwenden (COM Syndrom ^^ ist aber auch super bequem ! )
Ich muss halt nur nen eindeutigen Besitzer haben und den Lifecycle garantieren ^^ aka das der Besitzer alle Anwender überlebt ^^Ciao ...
-
RHBaum schrieb:
1 Stufe höher im Design, die Referenz-Zählung an sich
Dann hast du einen unique_ptr. shared_ptr haben durchaus eine Berechtigung.
-
Problem ist das es scheinbar keine std::shared_ptr variante im Standard gibt bei der man das counter-locking beeinflussen/überschreiben kann - ergo sind alle std::share_ptr Nutzung in den meisten C++ Umgebungen erstmal threadsafe
ich finde es schade das man sowas im Standard nicht bedacht hat (und Zero Cost Abstraktion komplett ignoriert hat) std::string und std::string_view (in C++17) wäre da ein vergleich einer vom Standard erlaubten resourcenschonendere Nutzung
mein vorheriges Kommentar ziele eher darauf ab das die meisten gar nicht wissen mit welchen Kanonen da geschossen wird - kommt ja aus dem Standard und ist bestimmt alles super-schnell geil
-
kommt ja aus dem Standard und ist bestimmt alles super-schnell geil
Mit der Einstellung kann man sich sicher gut bei Fachzeitschriften (Heise Verlag) profilieren und dann Columnen schreiben, wo rauskommt, das C# die Schnellste Programmiersprache ist, kurz vor Java, und C++ weit abgeschlagen hinter Visual Basic liegt.
Das man ne std::mapstd::string,std::string mit nem Java Dictionary verglichen hat, kann man dann gut mit der "üblichen" Verwendung begründen
Sorry musste sein ...
Dann hast du einen unique_ptr. shared_ptr haben durchaus eine Berechtigung.
genau das mein ich doch
Es gibt durchaus Fälle wo shared_ptr ne Berechtigung haben, genau dann wo es keinen eindeutigen verantwortlichen(Besitzer) gibt ....
Und das sollte doch im Synchronen Context eher die seltene Ausnahme sein ...
Beio Multithreaded kann es sicher häufiger vorkommen, aber da hat der Lock ja dannn auch seine Berechtigung ...Ciao ...
-
Sorry musste sein ...
du hast die einleitende Ironie im Vorsatz aber schon wahrgenommen - der mit den Kanonen und Spatzen - oder?
