Warum meinen eigentlich viele, dass C++ genau so schnell sei wie C?
-
Dabei weiß doch jeder, dass das Quatsch ist. C war, ist und bleibt schneller als dieses überladene C++. Nicht dass ich etwas eggen C++ hätte. Es hat alle seinen Nutzen. Ich bin hierbei nur auf die nciht unerheblichen Performanceunterschiede aus. Ich hatte vor wenigen tagen irgendwo einen Artikel (sorry, hab die url leider nciht mehr) gelesen. Da wurde erwähnt, dass C im Durchschnitt um 30% schneller wäre als C++, was ja auch logisch ist. Ich frage mich nur warum es hier viele leute gibt, die selbiges leugnen. Wahrscheinlich weil das ein C++ Forum ist und kein C Forum.
Naja, objektivität kann man hier wohl eher kaum erwarten.
-
Es gab auch schon Artikel (unter anderem in der c't) wonach Visual Basic schneller als C(++) sei. Hängt immer von der Programmierung ab. Wobei es natürlich klar ist, dass du bei einigen C++ Sprachkonstrukten einen kleinen Overhead im Vergleich zu C hast, wobei dieser IMHO aber absolut vernachlässigbar heutzutage ist.
-
nep schrieb:
Es gab auch schon Artikel (unter anderem in der c't) wonach Visual Basic schneller als C(++) sei. Hängt immer von der Programmierung ab. Wobei es natürlich klar ist, dass du bei einigen C++ Sprachkonstrukten einen kleinen Overhead im Vergleich zu C hast, wobei dieser IMHO aber absolut vernachlässigbar heutzutage ist.
Also das mit Visual Basic interessiert mich jetzt. ist da wirklich was dran? Kann ich mir ehrlich gesagt nicht so wirklich vorstellen.
Du nep, dieser kleine overhead, der dürfte sich bei umfangreichen und komplexen berechnungen zum beachtlichen overhead summieren.
MfG, het
-
Okay, kurz meine Meinung: C muss schneller als C++ sein, allerdings ist C Bestandteil von C++, also müsste man das präzisieren! Geschwindigkeit in diesem Bereich 'Programmiersprache C/C++' finde ich, kann man auch nicht verallgemeinern, denn es gibt Bereiche die keinen Nachteil in Bezug auf die Ausführungsgeschwindigkeit haben (Templates) - oder nur sehr gering, wohl aber auf die Codelänge. Da kann man aber auch nicht von Nachteil sprechen, denn summa sumarum, nehmen Templates einem ja nur die Arbeit ab.
Klar ist das Konzept von Polymorphismus durch VMT's etwas rechenintensiver, aber den Vorteil in Bezug auf die Flexibilität und die Komfortabilität des Codes macht das in meinen Augen wieder wett.
Wollte damit nur ein *paar* (genauer: 2
) Themenbereiche von C++ anreißen, da ich glaube, dass aus zu diskutieren, ist sinnlos 
.h3t schrieb:
Du nep, dieser kleine overhead, der dürfte sich bei umfangreichen und komplexen berechnungen zum beachtlichen overhead summieren.
subjektiv oder objektiv?
-
CodeFinder schrieb:
Okay, kurz meine Meinung: C muss schneller als C++ sein, allerdings ist C Bestandteil von C++, also müsste man das präzisieren! Geschwindigkeit in diesem Bereich 'Programmiersprache C/C++' finde ich, kann man auch nicht verallgemeinern, denn es gibt Bereiche die keinen Nachteil in Bezug auf die Ausführungsgeschwindigkeit haben (Templates) - oder nur sehr gering, wohl aber auf die Codelänge. Da kann man aber auch nicht von Nachteil sprechen, denn summa sumarum, nehmen Templates einem ja nur die Arbeit ab.
Klar ist das Konzept von Polymorphismus durch VMT's etwas rechenintensiver, aber den Vorteil in Bezug auf die Flexibilität und die Komfortabilität des Codes macht das in meinen Augen wieder wett.
Wollte damit nur ein *paar* (genauer: 2 ) Themenbereiche von C++ anreißen, da ich glaube, dass aus zu diskutieren, ist sinnlos .h3t schrieb:
Du nep, dieser kleine overhead, der dürfte sich bei umfangreichen und komplexen berechnungen zum beachtlichen overhead summieren.
subjektiv oder objektiv?
Hmm? War eine subjektive Äußerung auf eine objektive Tatsache!
Wenn zB pro schleifendurchlauf in C++ ein paar taktzyclen mehr gebraucht werden, udn man durchläufz dei schleife 569.354.656 mal, dann dürfte man einen ordendlichen performacneunterscheid verzeichnen.
-
naja, es kommt immer darauf an, wie etwas programmiert ist. ein schlau gemachtes programm in basic auf 'nem commodore64 kann schneller sein, als ein dumm programmiertes C programm.
diese 'im durchschnitt 30 % schneller' kommen wohl daher, weil bei C programmen den machern speed oft wichtig ist, während oft bei programmen in anderen sprachen (die sowieso auf fetten kisten mit vielen mega-hertz-und-bytes laufen), geschwindigkeit und speicherverbrauch ziemlich egal sind.
-
<°)))o><
*edit 1* Eine Richtigstellung.
*edit 2* Jetzt habe ich einen Bug gefunden !*edit 3* Bugreport :
Dummerweise haben beide Postings über meinem das gleiche Datum und die gleiche Uhrzeit.Der Fisch zumindest ist nicht für Undertaker !
-
merker schrieb:
<°)))o><
Unterlasse doch bitte solche destruktiven Kommentare. Danke
-
Wenn zB pro schleifendurchlauf in C++ ein paar taktzyclen mehr gebraucht werden, udn man durchläufz dei schleife 569.354.656 mal, dann dürfte man einen ordendlichen performacneunterscheid verzeichnen.
Davon abgesehen, dass ich das Beispiel sinnlos finde (vgl. Undertaker's Kommentar), nenn mir mal ein anwendungsbezogenes Beispiel, indem das relevant ist :p .
@Undertaker: Jo, das sehe ich auch so
. Und u.a. deshalb, macht [ironie-on]so eine Diskussion ja auch ungemein viel Sinn[ironie-off] .h3t schrieb:
Unterlasse doch bitte solche destruktiven Kommentare. Danke
Trifft doch aber den Casus Knacktus
.
-
CodeFinder schrieb:
Davon abgesehen, dass ich das Beispiel sinnlos finde (vgl. Undertaker's Kommentar), nenn mir mal ein anwendungsbezogenes Beispiel, indem das relevant ist :p .
Raytracing, 3D renderer, cryptografie und und und
-
h3t schrieb:
nep schrieb:
Es gab auch schon Artikel (unter anderem in der c't) wonach Visual Basic schneller als C(++) sei. Hängt immer von der Programmierung ab. Wobei es natürlich klar ist, dass du bei einigen C++ Sprachkonstrukten einen kleinen Overhead im Vergleich zu C hast, wobei dieser IMHO aber absolut vernachlässigbar heutzutage ist.
Also das mit Visual Basic interessiert mich jetzt. ist da wirklich was dran? Kann ich mir ehrlich gesagt nicht so wirklich vorstellen.
Du nep, dieser kleine overhead, der dürfte sich bei umfangreichen und komplexen berechnungen zum beachtlichen overhead summieren.
MfG, het
Nein, das war nur ein Beispiel um zu zeigen, dass das vor allem davon abhängt wie etwas in einer Programmiersprache programmiert ist. Wenn ich mich recht erinnere war es im c't Artikel z.B. unter anderem so, dass man den C++ Funktionen die Parameter ganz normal by value (wie es halt defaultmäßig gemacht wird) anstelle by reference übergeben hat. In Visual Basic wird hingegen alles per default by reference übergeben. Das verlangsamt ein C(++) Programm natürlich, wenn man größere Objekte an Funktionen by value übergibt.
Wenn du einfach nur irgendwelche Berechnungen anstellst, dann hängt es eigentlich hauptsächlich davon ab wie diese implementiert sind. Dürfte eigentlich keinen Unterschied zwischen C und C++ geben.
Ein gutes Beispiel sind eben z.B. virutelle Methoden, die einen kleinen Overhead haben, der aber wie gesagt auf normalen PCs heutzutage absolut vernachlässigbar ist.
-
nep schrieb:
h3t schrieb:
nep schrieb:
Es gab auch schon Artikel (unter anderem in der c't) wonach Visual Basic schneller als C(++) sei. Hängt immer von der Programmierung ab. Wobei es natürlich klar ist, dass du bei einigen C++ Sprachkonstrukten einen kleinen Overhead im Vergleich zu C hast, wobei dieser IMHO aber absolut vernachlässigbar heutzutage ist.
Also das mit Visual Basic interessiert mich jetzt. ist da wirklich was dran? Kann ich mir ehrlich gesagt nicht so wirklich vorstellen.
Du nep, dieser kleine overhead, der dürfte sich bei umfangreichen und komplexen berechnungen zum beachtlichen overhead summieren.
MfG, het
Nein, das war nur ein Beispiel um zu zeigen, dass das vor allem davon abhängt wie etwas in einer Programmiersprache programmiert ist. Wenn ich mich recht erinnere war es im c't Artikel z.B. unter anderem so, dass man den C++ Funktionen die Parameter ganz normal by value (wie es halt defaultmäßig gemacht wird) anstelle by reference übergeben hat. In Visual Basic wird hingegen alles per default by reference übergeben. Das verlangsamt ein C(++) Programm natürlich, wenn man größere Objekte an Funktionen by value übergibt.
Wenn du einfach nur irgendwelche Berechnungen anstellst, dann hängt es eigentlich hauptsächlich davon ab wie diese implementiert sind. Dürfte eigentlich keinen Unterschied zwischen C und C++ geben.
Ein gutes Beispiel sind eben z.B. virutelle Methoden, die einen kleinen Overhead haben, der aber wie gesagt auf normalen PCs heutzutage absolut vernachlässigbar ist.Ehm aber keiner zwingt dich in C++ by value zu übergeben. es gibt nur die möglichkeit es zu tun. UNd zum letzteren: mit dem begriff "vernachlässigbar" würde ich vorsichtiger umgehen. Versuch mal ein kleines 3D Spile zu machen mit realtime raytracing. (ok, bei einer sehr niedrigen auflösung
). Dann wird der kleineste overhead nicht mehr vernachlässigbar.
-
Und was soll da dann nun konkret dafür Sorgen, dass die Anzahl der benötigten Taktzyklen vergrößert wird? Hängt doch wohl ganz eindeutig von der Programmierung/Implementierung ab...sorry aber ich finde das sinnfrei.
EDIT: Das ist noch auf Deinen voherigen Post bezogen
.
-
CodeFinder schrieb:
Und was soll da dann nun konkret dafür Sorgen, dass die Anzahl der benötigten Taktzyklen vergrößert wird? Hängt doch wohl ganz eindeutig von der Programmierung/Implementierung ab...sorry aber ich finde das sinnfrei.
EDIT: Das ist noch auf Deinen voherigen Post bezogen
.und wie sind die Implemenationsunterschiede zwischen C udn C++. Bei C++ wird man ganz anders an die Sache rangehen. Alles schön in klassen packen etc um sauberen code zu schaffen. (sauber aus der sicht eines C++ programmierers, um keinen falme z uverursachen). Dadurch wird ein overhear erzeugt.
-
h3t schrieb:
Ehm aber keiner zwingt dich in C++ by value zu übergeben.Dann wird der kleineste overhead nicht mehr vernachlässigbar.
CallByValue hat aber auch Vorteile, da eine Referenzierung beim Ansprechen einer Variable (die wie gesagt, wie Referenz übergeben wurde), auch etwas Zeit in Anspruch nimmt. Deswegen gibt es ja eben auch die Möglichkeit des CallByValues. Finde es da generell besser, wenn man zwischen meheren Möglichkeiten frei entscheiden kann, um es dann der Situation auch ggfs. anzupassen.
Und doch: ich bin der Meinung er ist vernachlässigbar. Und wenn Du meinst, dass Du so hochoptimierten Code brauchst (was bei einem Compiler ja irgendwie nie richtig der Fall ist, da ist ja immer noch Potential *g*), schreibst Du's gleich mit Assembler.
-
CodeFinder schrieb:
h3t schrieb:
Ehm aber keiner zwingt dich in C++ by value zu übergeben.Dann wird der kleineste overhead nicht mehr vernachlässigbar.
CallByValue hat aber auch Vorteile, da eine Referenzierung beim Ansprechen einer Variable (die wie gesagt, wie Referenz übergeben wurde), auch etwas Zeit in Anspruch nimmt. Deswegen gibt es ja eben auch die Möglichkeit des CallByValues. Finde es da generell besser, wenn man zwischen meheren Möglichkeiten frei entscheiden kann, um es dann der Situation auch ggfs. anzupassen.
Und doch: ich bin der Meinung er ist vernachlässigbar. Und wenn Du meinst, dass Du so hochoptimierten Code brauchst (was bei einem Compiler ja irgendwie nie richtig der Fall ist, da ist ja immer noch Potential *g*), schreibst Du's gleich mit Assembler.Nochmal das beispiel von realtime raytracing! Da wird versucht das meiste rauszuholen. Da kommt es eben auf jeden taktzyklus an. Wenn man bedenkt, dass heutzutage die (heim)rechner imernoch zu lahm sind um PC spiele mittels raytracing in ECHTZEIT darzustellen, dann sollte man auf performacne achten. udn das sehr genau. ich meine: versuch mal eine szene in min1024*768 in ehtzeit mittels raytracing zu rendern.
-
h3t schrieb:
und wie sind die Implemenationsunterschiede zwischen C udn C++. Bei C++ wird man ganz anders an die Sache rangehen. Alles schön in klassen packen etc um sauberen code zu schaffen. (sauber aus der sicht eines C++ programmierers, um keinen falme z uverursachen). Dadurch wird ein overhear erzeugt.
Stimmt, aber das kratzt keinen, wenn man die Vorteile in Bezug auf den Code sieht. Wem diese Vorteile natürlich nicht ausreichen/zusagen, der programmiert einfach weiter in C :p .
-
CodeFinder schrieb:
h3t schrieb:
und wie sind die Implemenationsunterschiede zwischen C udn C++. Bei C++ wird man ganz anders an die Sache rangehen. Alles schön in klassen packen etc um sauberen code zu schaffen. (sauber aus der sicht eines C++ programmierers, um keinen falme z uverursachen). Dadurch wird ein overhear erzeugt.
Stimmt, aber das kratzt keinen, wenn man die Vorteile in Bezug auf den Code sieht. Wem diese Vorteile natürlich nicht ausreichen/zusagen, der programmiert einfach weiter in C :p .
ja gut, in diesem thread hab ich mich nur auf die perforamcneunterscheide bezogen und nicht auf ie Vor und NAchteile der Sprachen und Sprachfeatures.
-
h3t schrieb:
Wenn man bedenkt, dass heutzutage die (heim)rechner imernoch zu lahm sind um PC spiele mitels realtime raytracing darzustellen, dann sollte man auf performacne achten. udn das sehr genau.
Das Problem ist allerdings, dass, selbst wenn Du es in C schreibst und damit Deine 5 Taktzyklen raus holst, sind die (Heim-)Rechner trotzdem zu langsam
.
-
h3t schrieb:
ja gut, in diesem thread hab ich mich nur auf die perforamcneunterscheide bezogen und nicht auf ie Vor und NAchteile der Sprachen und Sprachfeatures.
Jupp, das stimmt. Allerdings steht das im Zusammenhang
: Das Eine rechtfertigt das Andere.