Array exceeded erkennen
-
wärs nich effektiver, wenn man start dann berechnet, bevor der vector gefüllt wird?
-
otze schrieb:
wärs nich effektiver, wenn man start dann berechnet, bevor der vector gefüllt wird?
wozu denn? ich will ja nur stoppen, wie schnell er die arrays sortiert. bei der füllschleife dürfte das rand mehr zeit verbrauchen als der arrayzugriff.
-
@japro:
wenn wir von dem undefinierten verhalten (&array[size]) mal absehen: natürlich kann es am stack schneller sein als am heap - muss aber nicht. Umgekehrt geht es genauso.probier das ganze mal mit dynamischen arrays - dann hat sich bei mir die sache sogar umgedreht (liegt aber an dem schwankenden zeiten für memory zugriff)
std::vector ist natürlich _kein_ ersatz für fixe Arrays - denn dafür gibt es boost::array
-
ist das verhalten echt undefiniert? ich meine da findet ja kein zugriff statt. sind nur adressen die da sind...
habs mal mit arrays probiert, die mit new allokiert wurden. das resultat ist jedes mal anders und man kann irgendwie nicht mehr ausmachen welche version schneller ist. hättes es aber ehrlichgesagt nicht erwartet, dass per new allokierte arrays schneller als solche auf dem stack sind. jedenfalls beim sortieren.array: 4378737 vector: 5325541 array: 4781590 vector: 3654554 array: 5451583 vector: 4000206 array: 4783789 vector: 4918830 array: 5259833 vector: 4658281
-
japro schrieb:
ist das verhalten echt undefiniert? ich meine da findet ja kein zugriff statt. sind nur adressen die da sind...
array[size] dereferenziert.
natürlich wird der compiler ein
&array[size]
zu einem
array+size
optimieren - aber das ändert nix an dem undefinierten verhalten.
-
@jaspro 1000 mal durchlaufen alssen, und dann den durchschnitt bilden, anders haste da keine chance an nen halbwegs aussagekräftigen wert zu kommen..
-
Ich habe natürlich auch einen Vergleichstest gemacht, und letztendlich ist es egal ob man array oder vector nimmt. Mal ist das eine schneller, mal das andere, und mal sind sogar beide gleich schnell. Das die Zeiten jedesmal unterschiedlich sind, liegt wohl am Multitasking u.a. Einflüssen des Systems.
#include <Windows.h> #include <iostream> #include <vector> using namespace std; int main(int argc, char* argv[]) { vector<int> vec; vec.reserve(500000); // --- unsigned long startTime = GetTickCount(); for(int i=0; i<500000; i++) { vec[i] = 200; } unsigned long endTime = GetTickCount(); // --- cout << "vector\nstartTime: " << startTime << ", endTime: " << endTime << ", time: " << endTime - startTime << endl; return 0; }Und für Arrays:
#include <Windows.h> #include <iostream> #include <vector> using namespace std; int main(int argc, char* argv[]) { int *array = new int[500000]; // --- unsigned long startTime2 = GetTickCount(); for(int i=0; i<500000; i++) { array[i] = 200; } unsigned long endTime2 = GetTickCount(); // --- cout << "array\nstartTime: " << startTime2 << ", endTime: " << endTime2 << ", time: " << endTime2 - startTime2 << endl;*/ return 0; }Ergebnisse nach mehreren starts im Kommandofenster unter Win2000pro, compiliert mit VC++6.0 Standard-Edition:
10 und 20 ms, sowohl Array als auch der Vector haben immer diese Zeiten rausgebracht.
Habs auch noch mit 5000000 ausprobiert, Ergebnis bei beiden: immer um ca. 140ms.
Habs auch noch mit 50000000 ausprobiert, Ergebnis bei beiden: immer um ca. 1300ms.
-
otze schrieb:
@jaspro 1000 mal durchlaufen alssen, und dann den durchschnitt bilden, anders haste da keine chance an nen halbwegs aussagekräftigen wert zu kommen..
dann schau dir mal mein programm nochmal an
-
Zeitunterschiede von 10ms sind aber nicht sehr aussagekräftig, insbesondere, weil GetTickCount() manchmal wirklich nur ne Auflösung von mehreren ms hat. Da musst du IMO schon auf ein paar Sekunden kommen, um halbwegs repräsentative Werte zu erreichen.
-
Optimizer schrieb:
Zeitunterschiede von 10ms sind aber nicht sehr aussagekräftig, insbesondere, weil GetTickCount() manchmal wirklich nur ne Auflösung von mehreren ms hat. Da musst du IMO schon auf ein paar Sekunden kommen, um halbwegs repräsentative Werte zu erreichen.
GetTickCount hat ne Auflösung von etwa 54ms (IIRC)
weiters optimiert der VC++ Standard nicht.und statt reserver muss man resize verwenden, auch wenn das hier keine rolle spielen sollte.
-
hier stand mist
-
So'n Quatsch.
Undefiniertes Verhalten liegt dann vor wenn keine reproduzierbare Ergebnisse erreichbar wären.Da spielt die Genauigkeit von GetTickCount() keine Rolle.
Hier sieht man mal wieder dass viele Leute hier nur theoretiker sind.if(Theorie!=Praxis) feed_the_trolls = true;
-
noproblem schrieb:
Undefiniertes Verhalten liegt dann vor wenn keine reproduzierbare Ergebnisse erreichbar wären.
Ah, dh folgendes ist wohl definiert:
char c[]="!"; char dummy; c[2]='x';Mit großer wahrscheinlichkeit wird es nicht abstürtzen.
Oder meintest du etwas anderes?
-
Wie war das mit dem Vergleich von Äpfeln und Birnen.
bzw. Verhalten von Laufzeit und Exceptions ?
-
noproblem schrieb:
Verhalten von Laufzeit und Exceptions ?
Hardware Exception != C++ Exception
egal was du gemeint hast (denn es ist kein richtiger deutscher Satz - deswegen war es mir nicht möglich dein Statement zu entschlüsseln) - der Code den ich gepostet habe erzeugt undefiniertes verhalten - da kannst du nix wegdiskutieren.
char* p=0:
*p=0;erzeugt reproduzierbares verhalten - aber es ist dennoch undefiniert.
-
@noproblem, nur weil es in dem Fall oben das eigentliche Ergebnis nicht verändert,
ist dies trotzdem undefiniert und man sollte Leute darauf hinweisen, sonst würden
sie es evt. auch einmal in einem anderen Kontext so schreiben.Wieso ist das überhaupt undefiniert, ist array[size] im grunde nicht das gleiche wie
array+size?
-
SirLant schrieb:
Wieso ist das überhaupt undefiniert, ist array[size] im grunde nicht das gleiche wie array+size?
int array[2]; array[1] = 0; array + 1 = 0;
-
SirLant schrieb:
Wieso ist das überhaupt undefiniert, ist array[size] im grunde nicht das gleiche wie
array+size?nein, aber
array[size]
kommt aufs gleiche raus wie
*(array+size)
-
Stimmt, wird ja noch einmal dereferenziert um den Wert hineinzuschreiben, habe ich
nicht bedacht.