Speed, Speed, SPEEEED!!!
-
Hi,
ich brauche für mein Projekt so viel speed wie nur möglich, nun da ich in C++ code stell ich mir die frage was schneller ist:
// C Code strcmp (x,y); // C++ Code MyString.compare (y);
sowie weitere fragen stellen sich mir auf: Was ist schneller? structs+funtkionen oder klassen? Hab gehört das Carmack mal gesagt hat das klassen bis zu 10% langsamer sein sollen!!! stimmt das?
Exceptions? Schnell oder langsam?
std::vector vs. linkedlist? was ist schneller?
ist die STL überhaupt schnell oder ist selbstgecodetes schneller?
Frage was ist schneller?
void func (const char* text); void func (const char text[256]); void func (const std::string &text); void func (char* text); void func (char text[256]);
Casts sind generell ja langsam, drum was ist schneller? static_cast oder C-Casts?
was ist schneller?
for (int i=0; i<30; ++i); for (int i=0; i<30; i++); for (unsigned int i=0; i<30; ++i); for (unsigned int i=0; i<30; i++); for (signed int i=0; i<30; ++i); for (signed int i=0; i<30; i++);
sind templates schnell oder ist es schneller wenn man den typ direkt festlegt? z.B. int?
gruß,
iSAK
-
Hallo!
ähnliche Fragen hab ich mir auch gestellt. Schau dir dazu mal meinen thread an:
http://www.c-plusplus.net/forum/viewtopic.php?t=59756
Es heißt, man sollte erst mit einem Profiler messen, wo wirklich die Schwachstellen sind, diese optimieren. Und erst, wenn dann alles wirklich noch zu langsam ist, dann kann man sich an solche low-level-Dinge ranmachen. Aber cih glaub das würde dann nciht mehr viel bringen, zumal der Compiler ja auch schon intern optimiert.
Zur STL:
Es kommt drauf an, was du mit list bzw vector machen willst. List ist schnell, einzelne Elemente in der Liste zu löschen, dauetrt jedoch lange, auf ein bestimmtes Element zuzugrifen, sogfern ses nicht der anfang bzw das ende ist.
Der Vector dagegen erlaub schnellen Zugriff auf einzelne elemente, es dauert jedoch lange, ein Elemente in der Mitte zu löschen.
-
iSAK schrieb:
ich brauche für mein Projekt so viel speed wie nur möglich, nun da ich in C++ code stell ich mir die frage was schneller ist:
Nimm nen Profiler und teste.
Ich entnehme deiner Fragenstellung und den beispielen, dass du nicht sonderlich viel Ahnung von C++ und/oder Optimierungen hast.Vielleicht solltest du erstmal das Programm fertigstellen und dich dann erst mit Optimierung befassen. 'Premature Optimization is the root of all evil'
-
1. hängt das alles von der Implementierung ab und wer generelle Aussagen darüber trifft hat keine Ahnung!
2. macht das wenig Sinn so zu "optimieren". Arbeite da lieber mit einem Profiler
-
iSAK schrieb:
Hi,
ich brauche für mein Projekt so viel speed wie nur möglich, nun da ich in C++ code stell ich mir die frage was schneller ist:
// C Code strcmp (x,y); // C++ Code MyString.compare (y);
strcmp ist schneller, falls compare nicht strcmp benutzt und geinlined wird. Der Compiler ist ja nicht dumm.
iSAK schrieb:
sowie weitere fragen stellen sich mir auf: Was ist schneller? structs+funtkionen oder klassen? Hab gehört das Carmack mal gesagt hat das klassen bis zu 10% langsamer sein sollen!!! stimmt das?
Quatsch. Hier kommt es auch wieder darauf an was man macht und wie der Compiler optimiert.
iSAK schrieb:
Exceptions? Schnell oder langsam?
Exceptions können ein Programm ausbremsen wenn sie falsch benutzt werden.
iSAK schrieb:
std::vector vs. linkedlist? was ist schneller?
std::vector im Zugriff und Linked-Lists beim einfügen von Elementen. Kann man so generell nicht sagen. Gips aba genug Diagramme im Internet wo vector, deque und co. verglichen werden.
iSAK schrieb:
ist die STL überhaupt schnell oder ist selbstgecodetes schneller?
Kommt auf die Implementation der STL an. Normalerweise bringt es nichts selber zu coden, ausser man weiß was man macht.
iSAK schrieb:
Frage was ist schneller?
void func (const char* text); void func (const char text[256]); void func (const std::string &text); void func (char* text); void func (char text[256]);
Alles ungefähr gleich schnell (in der Parameterübergabe).
iSAK schrieb:
Casts sind generell ja langsam, drum was ist schneller? static_cast oder C-Casts?
Wie kommst du darauf dass casts generell langsam sind? Der C-Cast ist ein universeller cast. Er ist quasi immer die Kombination aus reinterpret_cast, static_cast und const_cast die gerade passt und kann deswegen verwirren.
iSAK schrieb:
was ist schneller?
for (int i=0; i<30; ++i); for (int i=0; i<30; i++); for (unsigned int i=0; i<30; ++i); for (unsigned int i=0; i<30; i++); for (signed int i=0; i<30; ++i); for (signed int i=0; i<30; i++);
Langsam nervts. Bei Builtins wird an dieser Stelle i++ zu ++i optimiert. Ist also Pott wie Deckel. signed/unsigned int macht hier keinen Unterschied.
iSAK schrieb:
sind templates schnell oder ist es schneller wenn man den typ direkt festlegt? z.B. int?
Überleg doch mal. Templates werden zur Compilezeit aufgelöst. Dadurch entstehen also null Geschwindigkeitsnachteile.
Am besten kaufst du dir erstmal ein vernünftiges C++ Buch bevor du ein Projekt beginnst wofür du so viel Speed brauchst, dass du sogar simpelsten Code optimieren willst. Meistens (und das wird hier immer gepredigt) sind die Algorithmen bremsend. Man sollte also immer den passenden Algorithmus wählen wenn man speed braucht. Und der Standardspruch in jedem Optimier-Thread: "PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL". Nur, damit der auch mal gefallen ist (Edit: Shade hat ihn schon gebracht. War zu langsam ;)).
-
@strcmp
Nimmt sich beides nicht viel !
Dürfte also keinen Unterschied machen -> obj.compare benutzen@Carmack
Nein.
Falsch angewandtes C kann langsamer sein. Falsch angewandtes C++ kann auch langsamer sein.
Generell schneller oder langsamer ist keines davon !(hat überhaupt nichts mit der Geschwindigkeit zu tun !)@Exceptions
Kommt wieder darauf an wie sie angewendet werden.
Solange keine Exception geworfen wird ist dein Programm mit Exceptions auch nicht langsamer.
(Es entsteht bei Exceptions allerdings ein zu vernachlässigender Overhead für den BackTrace)Auch hier gilt wieder: Falsch angewandt kann es performance kosten -> C und error-check mit ifs kann auch kosten.
Kommt immer darauf an wie man es verwendet.@STL
Ist schon verdammt schnell !
Benutz sie einfach, denn dafür ist sie ja da.
(Ausnahmen bestätigen die Regel)@func(string)
Ist alles das selbe, also gleich schnell !
Trotzdem wenn möglich const nutzen, ist sicherer beim programmieren.@for-schleife
Ist alles das selbe !@templates
Versteh erstmal was templates sind. Bei templates wird der Typ direkt beim benutzen festgelegt, ist also wieder das selbe.@Fazit:
Ich würde sagen du hast noch grosse Probleme die Sprache generell zu verstehen.
Alles was du aufgezählt hast trägt nicht zur Performancesteigerung etc... bei.
Wenn du die Anwendung beschreiben würdest könnte man dir hier aber sicherlich ein paar Tips geben wie man sie schneller macht (maps, Speicherfragmentierung, etc...)
-
@Mastha
auf welcher basis triffst du die Aussagen über die Geschwindigkeit zB. das mit strcmp? Hast du eine Zauber-Kugel? Hast du das an deiner C++-Implementierung gemessen? Oder einfach mal geratten?
-
string s("hallo");
string s2("test");if(s==s2)
dürfte signifikant schneller sein als
if(!strcmp("hallo", "test"))bei der for schleife ist signed auf Intel Architekturen bedeutend schneller als unsigned
also bitte:
- auf sowas nicht so antworten - sondern so wie ich und kingruedi und Maxi
- keinen blödsinn verzapfen
-
Shade Of Mine schrieb:
string s("hallo");
string s2("test");if(s==s2)
dürfte signifikant schneller sein als
if(!strcmp("hallo", "test"))Warum das?
-
Jester schrieb:
Shade Of Mine schrieb:
string s("hallo");
string s2("test");if(s==s2)
dürfte signifikant schneller sein als
if(!strcmp("hallo", "test"))Warum das?
Ein string kennt seine Länge, ich implementiere den op== somit so:
bool operator==(string const& a, string const& b) { return a.size()==b.size() && !memcmp(a.value, b.value, a.size()); }
also in meinem beispiel wird nur ein int vergleich durchgeführt.
und memcmp ist schneller als strcmp - warum, dürfte klar sein.
-
Shade Of Mine schrieb:
Vielleicht solltest du erstmal das Programm fertigstellen und dich dann erst mit Optimierung befassen. 'Premature Optimization is the root of all evil'
'on the other hand we cannot ignore efficiency'
-
Also meine STL-Implementierung macht da aber nicht memcmp, sondern geht über die char_traits<char>::compare. Und da wird jedes für sich verglichen.
Aber die bekannte Länge ist sicher ein Vorteil.
-
memcmp ist schneller als strcmp - warum, dürfte klar sein.
Nein ist nicht klar, Beweise bitte.
-
*mist*
-
Abgesehen davon ist der Vergleich von compare und op== irgendwie so wie mit den Äpfeln und den Birnen. Compare muß sich auch jedes Zeichen anschauen, auch wenn beide verschieden lang sind.
-
Bashar schrieb:
memcmp ist schneller als strcmp - warum, dürfte klar sein.
Nein ist nicht klar, Beweise bitte.
strcmp muss sowohl für a als auch für b auf 0 testen während memcmp das alignement ausnützen kann und nur einen int testen muss.
der vorteil heirbei ist: das alignment. memcmp kann auf Intel Architekturen mit 4 Byte Blöcken arbeiten, strcmp kann es nicht. das ist auch der grund warum strcpy langsamer als memcpy ist.
OK, Beweisen kann ich es nicht, weil mem* kein Alignment ausnutzen müssen - ich gehe einfach von einer idealen Implementierung aus.
-
Gewonnen. Meine ersten Tests waren etwas unausgereift. Neueste Ergebnisse:
memcmp 3.81 s
strcmp 5.78 s
std::string 4.56 s(Es wird 50 Millionen mal "Hallo Welt!" mit einem String gleichen Inhalts verglichen, das Ergebnis des Vergleichs jeweils einer volatile bool-Variablen zugewiesen, g++-3.2.2 mit -O Flag)
-
Bashar schrieb:
Gewonnen.
:p
Ich habe früher sehr viel solcher minimal Optimierungen gemacht, bis ich irgendwann kapiert habe, dass ich mit einem besseren Algorithmus wesentlich mehr rausholen lässt, also mit solchen Optimierungen.
-
Vielleicht erzählst du mal WAS für ein Programm du schreiben willst, für das du so ewig viel Speed brauchst.
Ohne das zu wissen ist es blödsinn darüber zu blabbeln was schneller oder weniger schnell ist.
Und wie eben schon gesagt : Ein bessere Algorithmus ist wesentlich schneller als die kleinen Codeoptimierungen.
-
TeeJay schrieb:
Vielleicht erzählst du mal WAS für ein Programm du schreiben willst, für das du so ewig viel Speed brauchst.
Mein Tipp eine Computerspiel oder eine 3d Engine
SCNR