Ergebnisse der Geschwindigkeitstest versch. Funktionen mit gleichen Ergebnissen

rapso schrieb:

laut intel und amd sind die arrayversionen schneller, besonders unrolled. laut arm sind die pointerversionen schneller (ich hab beides auch richtig gebenched sodass ich das bestaetigen kann).

deine tests habe so einiges an unperformanten dingen, z.b. switch im inneren der schleife, du wolltest im switch die schleifendurchlaeufe machen!!!

was ist arm?

achso sorry wusste nicht dass es so etwas gibt. hatte nicht gegoogelt

oh sorry ich hab falsch abgelesen :

1.85
2.2
2.3
2.3

stimmt array ist doch schneller.

dann muss ich mich nicht mit so komplizierten pointers kümmern

irgendwie ist x != x?

welcome to the SMS generation

rüdiger

arm => http://de.wikipedia.org/wiki/ARM-Architektur

du solltest nicht mit einer Stopuhr messen. µBenchmarks richtig hinzubekommen ist nicht leicht!

die anderen x's sind nicht echt, sry sollte noch registrieren

rüdiger schrieb:

arm => http://de.wikipedia.org/wiki/ARM-Architektur

du solltest nicht mit einer Stopuhr messen. µBenchmarks richtig hinzubekommen ist nicht leicht!

wie? also ich benütz immer

#include <windows.h>

LARGE_INTEGER start_ticks, ende_ticks, frequenz;

double tick_diff     = 0;
start_ticks.QuadPart = 0;
ende_ticks.QuadPart  = 0;

QueryPerformanceCounter(&start_ticks);
QueryPerformanceFrequency(&frequenz);

// ... Hier Funktionen testen

QueryPerformanceCounter(&ende_ticks);

// benötigte zeit berechnen
tick_diff = ((double) ende_ticks.QuadPart - (double) start_ticks.QuadPart) / frequenz.QuadPart;
cout << tick_diff << endl;

kommen doch immer milisekundengenaue ergebnisse oder was ist nicht leicht? oder du meinst , es hängt immer so sehr von sprüngen ab z.b. funktionssprünge, if-anweisungen usw dass es nicht immer das richtige ergebnis rauskommt?

Naja, schlag mal den Begriff Multitasking-Betriebssystem nach. So wie Du vorgehst könnte der Rechner zu 90% der Meßzeit mit anderen Threads beschäftigt sein ohne das Du das unterscheiden kannst. Für aussagekräftige Messungen brauchst Du einen Profiler.

Und letzten Endes hängen solche Messungen stark vom Zielrechner ab. Auf meinen System z.B. sind die Pointer-Versionen im Schnitt 10% schneller als die Index-Versionen.

das ganze wirkt stark wie premature optimizing...

könnt ihr mir einen Profiler empfehlen? Wo find ich sie oder wie mach ich das?

Wiki hab ich schon durchgelesen aber keine Beispiele

hustbaer

Was schneller ist kommt vor allem auf den Compiler drauf an. Nur weil man im C++ Code irgendwo "a[i]" schreibt heisst das noch lange nicht dass im generierten Code auch noch irgendwo ein Zugriff über einen Index vorkommt, der Compiler kann daraus leicht nen Pointer machen der einfach weitergeschoben wird.

Messem mit QueryPerformanceCounter ist im Übrigen schon OK, man muss halt mehrere Messungen machen, und ein wenig aufpassen dass man im Hintergrund nix laufen hat was grob dazwischenfunken könnte.

Ok, ja. Aber es ist halt nur eine Schätzung und keine absolute Messung und das sollte man im Hinterkopf halten.

darthdespotism

x schrieb:

könnt ihr mir einen Profiler empfehlen? Wo find ich sie oder wie mach ich das?

Bei AMD gibts einen kostenlosen Profiler Und in der GCC ist glaub ich auch einer dabei.

hustbaer

@loks:
Angenommen ich habe 2 Funktionen die das gleiche tun, also 2 Implementierungen von irgendwas. Nennen wir sie A und B.
Nun mache ich ein paar Messungen/Testläufe im Profiler/...

Angenommen ich bekomme dann über den Profiler raus dass A schneller ist, aber alle Messungen die ich mit QueryPerformanceCounter gemacht habe zeigen dass B schneller ist, dann verlasse ich mich auf QueryPerformanceCounter, nicht auf der Profiler.

----

Einen Profiler verwende ich vielleicht um rauszubekommen wo ich noch was optimieren kann, aber sicher nicht um zu entscheiden welche Version einer Funktion schneller ist. Schliesslich läuft das Programm auf dem Zielsystem ja auch nicht mit dem Profiler, sondern "frei", also genau so wie man es mit QueryPerformanceCounter messen kann.

Solche Messungen eine "Schätzung" zu nennen halte ich für Unsinn.