C++ oder C#
-
Mechanics schrieb:
...Im Endeffekt wird C++ schon etwas schneller sein als C#, aber der Unterschied bewegt im einstelligen Prozentbereich. Und da auch nur bei sauberem C++, sonst kann man mit C++ leicht langsamere Programme schreiben.
Nach meiner eigenen Erfahrung (und ich mag C# eigentlich), ist der Unterschied mehr als messbar wenn in dem Programm nicht ständig die gleichen Methoden aufgerufen werden.
Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können, wenn Code sehr häufig aufgerufen wird. Doch in der Praxis gibt es viele Anwendungen bei denen die erstmalige Compilierung mehr Zeit kostet, als spätere Aufrufe retten können. Und Kunden vertröstet auch nur selten ein Spruch wie "Ab den 2ten Aufruf ist es schnell".
Das heißt nicht das ich C# nicht empfehlen kann, aber der Grund liegt eher in den geringeren Entwicklungsaufwand begründet, als in der Performance.
-
asc schrieb:
Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]
Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird. Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss, was natürlich um einiges langsamer ist.
-
Praktisch alles, was C# kann, kann man auch in C++ sehr komfortabel machen. Ausnahmen sind aber z.B. Reflection Emit, was eine massive Runtime wie das .NET Framework voraussetzt (welches mit C# laut Spezifikation nicht unbedingt etwas zu tun hat). Und natürlich kommt der Komfort zu einem gewissen Preis, insbesondere weil er bei C# aufgezwungen wird. Gerade dein Beispiel mit der Speicherverwaltung ist hier schön.
Ich benutze in allen grösseren Projekten mit C++ sehr oft Garbage Collection auf Basis von Smart Pointern und einem Mark/Sweep + Generational Algorithmus - der GC kommt überall zum Einsatz, wo es mir sinnvoll erscheint. Der GC von .NET ist noch sehr viel ausgeklügelter (der Quellcode einer alten Version 2.0 steht offen zur Verfügung), aber seine Benutzung ist zwingend. Und es ist klar, was schneller ist als die beste GC Implementierung: Kein GC. Statischer Speicher und fertig. In vielen Fällen reicht das in C++ sogar aus. Das Argument mit dem Speichermanagement pauschal zieht also nicht wirklich.
lolelotte schrieb:
Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. (...) Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss (...).
Das ist sehr richtig und nicht zu unterschätzen. Und man kombiniere nun diese Enumerator-Geschichte mit der Speicherverwaltung: Jeder Enumerator wird mit allem GC-Komfort in jeder Schleife neu auf dem GC angelegt und irgendwann wieder zerstört. Footprint: Ein Vielfaches eines Pointers, Indirektionen, virtuelle Calls, Verwaltung
PS: Ich liebe C# und in über 90% der Fälle sind diese Punkte irrelevant :p
-
/rant/ schrieb:
Ich benutze in allen grösseren Projekten mit C++ sehr oft Garbage Collection auf Basis von Smart Pointern und einem Mark/Sweep + Generational Algorithmus - der GC kommt überall zum Einsatz, wo es mir sinnvoll erscheint.
Sowas gibts?Statischer Speicher und fertig.
LOL.
Und man kombiniere nun diese Enumerator-Geschichte mit der Speicherverwaltung: Jeder Enumerator wird mit allem GC-Komfort in jeder Schleife neu auf dem GC angelegt und irgendwann wieder zerstört.
Ein GC zerstört nichts. Ein GC behält alles, was noch lebt, und vergisst den Rest einfach (Voraussetzung: Keine Finalizer).
Zerstören muss man in C++.
-
Bashar schrieb:
Sowas gibts?Wieso sollte es sowas nicht geben?
-
Kellerautomat schrieb:
Bashar schrieb:
Sowas gibts?Wieso sollte es sowas nicht geben?
Erwartete Antworten von gut bis dämlich:
- Ja, siehe http://...
- Nein, hab mich geirrt.
- Wieso nicht???ßß
-
lolelotte schrieb:
asc schrieb:
Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]
Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird.
Bitte mache nicht den Fehler dies per se auf die Objektorientierung zu schieben. Ich kann beispielsweise in C++ auch mit Ausnahme der main-Funktion rein Objektorientiert arbeiten, und dennoch muss es nichts kosten. Ausnahmen sind sicherlich virtuelle Funktionen, und die Tatsache das C#/Java jedem Objekt den GC aufzwingt. Aber letzteres hat erst einmal nichts mit dem OO-Paradigma zu tun.
-
Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.
-
lolelotte schrieb:
asc schrieb:
Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]
Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird. Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss, was natürlich um einiges langsamer ist.
Das sind Peanuts und darauf wollte ich nicht hinaus. Ich wollte eher im Gegenteil weg von dieser "xyz ist schneller als yzx" Geschichte, ich kanns echt nicht hören. C# ist schnell genug und die Performance ist in 99% der Fälle kein Thema. Die Unterschiede sind zu 99% und nicht spürbar und nicht messbar. Wenn es explizit um extrem zeitkritische Anwendungen geht, dann würde man eher nicht C# nehmen. Aber ansonsten ist das Gerede über Performance völlig irrelevant und reine Zeitverschwendung.
Weiß nicht mehr wers gesagt hat, aber ich finds immer wieder gut: "The best optimizer is between your ears". Darauf wollte ich eigentlich hinaus. Dass man aus C++ theoretisch 2% mehr Performance herauskitzeln kann interessiert keinen. Unsere C++ Software in der Arbeit ist teilweise echt langsam. Da brauchen Operationen Minuten. Sind zwar komplexe Operationen, aber ganze ist über die Zeit dermaßen auseinandergewachsen, dass da Sachen zig mal berechnet und ausgeführt werden. Hat aber niemand Zeit, das umzubauen. Und das hat jetzt nichts mit der Programmiersprache zu tun. Nicht optimal aufgebaute Software, die man konzeptionell um mehrere Größenordnungen beschleunigen könnte, findet man sehr viel häufiger, als Software, wo die Programmiersprache irgendwas ausmacht.
-
Cyres schrieb:
Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.
Nein sind sie nicht.
-
Zeus schrieb:
Cyres schrieb:
Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.
Nein sind sie nicht.
Wikipedia schrieb:
Programmierer der Sprachen C++, SystemVerilog oder Object Pascal müssen sich explizit mit dieser Thematik auseinandersetzen und entscheiden, welche Methoden sie als „virtuell“ definieren. In anderen objektorientierten Programmiersprachen wie Java, Smalltalk und Python sind automatisch alle Methoden virtuell.
Stackoverflow schrieb:
All methods in java are virtual by default.
Soll ich nach weiteren Quellen suchen?
-
private und finale Methoden sind in Java nicht virtuell.
-
Bashar schrieb:
private und finale Methoden sind in Java nicht virtuell.
> "by default"
> "automatisch"
( Hat er etwas frei übersetzt )
-
Bashar schrieb:
private und finale Methoden sind in Java nicht virtuell.
Du meinst "private Methoden sind nicht virtuell sowie finale Methoden, die keine anderen überschreiben sind nicht virtuell", oder?
-
hustbaer schrieb:
Eine grosse Schwäche von C++ ist, dass die Standard-Library ultra-mini-klein ist (verglichen mit der von Java oder C#). Und diesen Nachteil will das C++ Standard-Kommitee schon ausräumen. Ist nur unrealistisch dass sich in absehbarer Zeit genug tut so dass C++ in dieser Hinsicht wirklich mit Java oder C# mithalten könnte.
Mit Qt gibt es bereits eine solche Library.
-
Die Bibliothek von QT und die STL verfolgen allerdings 2 unterschiedliche Ziele
-
LordJaxom schrieb:
Bashar schrieb:
private und finale Methoden sind in Java nicht virtuell.
Du meinst "private Methoden sind nicht virtuell sowie finale Methoden, die keine anderen überschreiben sind nicht virtuell", oder?
Äh, ja
-
KuhTee schrieb:
hustbaer schrieb:
Eine grosse Schwäche von C++ ist, dass die Standard-Library ultra-mini-klein ist (verglichen mit der von Java oder C#). Und diesen Nachteil will das C++ Standard-Kommitee schon ausräumen. Ist nur unrealistisch dass sich in absehbarer Zeit genug tut so dass C++ in dieser Hinsicht wirklich mit Java oder C# mithalten könnte.
Mit Qt gibt es bereits eine solche Library.
Nein.
-
Ich wollte jetzt eigentlich gar nicht drauf antworten, aber was solls...
Hier tun alle irgendwie so rum, als würden sie die ganze Zeit ausschließlich an ultra-performance kritischen Anwendungen arbeiten, wo die virtuellen Methoden den Ausschlag geben.
Ich bin aber davon überzeugt, dass es in Wirklichkeit eigentlich niemanden interessiert. Und wenn man in der Arbeit doch solche Überlegungen macht, dann ist man fehl am Platz - premature optimization is the root of all evil.
Beim Design einer Anwendung (und ich rede explizit nicht von absolut performancekritischen Teilen, die extrem selten sind) sollte sowas wie virtuelle Methode oder nicht überhaupt keine Rolle spielen. Tut es auch nicht. Man braucht in erster Linie eine saubere, erweiterbare, wartbare Architektur. Dementsprechend designed man das Programm auch. Und dabei kommen auch virtuelle Methoden vor, und pimpl (OMG, ein new!!!) und shared data vielleicht auch mal paar Abstraktionsebenen mehr. Und es ist immer noch alles in 99% der Fälle sehr viel schneller als schnell genug. Und wenn es mal Stellen gibt, wo man sagt, die Software braucht mit sehr großen Datenmengen einfach ein bisschen zu lang und fühlt sich etwas träge an, dann kommt wohl auch niemand daher und sagt OMG, hätt ich doch bloß auf die virtuelle Methode verzichtet! Dann schaut man eher, dass man Berechnungen zwischenspeichert oder nicht mehrfach ausführt, Caches einführt, schlauere Algorithmen implementiert usw.
Mal davon abgesehen kann ein just in time compiler (zumindest theoretisch, ob es in der Praxis auch funktioniert hat mich nie interessiert) virtuelle Methoden auch inlinen.
-
Mechanics schrieb:
C# ist schnell genug und die Performance ist in 99% der Fälle kein Thema. Die Unterschiede sind zu 99% und nicht spürbar und nicht messbar.
Mechanics schrieb:
Und es ist immer noch alles in 99% der Fälle sehr viel schneller als schnell genug.
Du wiederholst dich. Wenn dir Performanzunterschiede von Faktor 2 (mehr kann man mit C++ auch nicht rausholen) egal sind, dann ist für dich vielleicht eine andere Sprache besser geeignet als C++. Im Ernst, wozu C++? In C# ist die Kompilierzeit 100 mal schneller und du kannst schnell die GUI RADen und es ist auch für die weniger erfahrenen Programmierer geeignet.
In C++ kannst du auf Programmierebene die gleichen Abstraktionen nutzen, mit etwas mehr Schreibaufwand, dafür ohne Overhead. Der grosse Vorteil ist aber, dass für die kritischen 1% praktisch optimaler Assemblercode generiert werden kann. Du hast immer die Möglichkeit, bis ans Optimum zu optimieren, bei anderen Sprachen geht das kaum (man kann zwar C-Funktionen aufrufen, aber die Zeit, die man zum Mappen der Datentypen benötigt hebt den Vorteil wieder auf).
Es gibt genug Anwendungen, wo es drauf ankommt. Server, Bildbearbeitung, Simulationen, z.T. Spiele. Es gibt auch genügend Anwendungen, wo es nicht drauf ankommt (deine zum Beispiel).
asc schrieb:
lolelotte schrieb:
C++ [ist] in der Praxis oft schneller [...] C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird.
Bitte mache nicht den Fehler dies per se auf die Objektorientierung zu schieben.
Ich schiebe es auf reine Objektorientierung. Schonmal Event-Handling mit Klassen versucht? Schonmal std::sort in Java (und konsequenterweise ohne Generics) nachprogrammiert, insbesondere mit einstellbarer
SortierfunktionSortierobjekt? Eine gelungene Sprache darf sich eben nicht auf reine Objektorientierung einschränken. Du wirst kaum ein C++-Projekt in etwas was ich "reine OOP" nenne (d.h. ohne freie Funktionen und Templates u.ä.) finden.
