Ist operator[] langsamer als ein Iterator?

endline

Hallo,

macht es operator[] beim Zugriff langsamer als einen Iterator, da operator[] sich ja nicht die momentane Position merkt?

Also das war fuer mich bisher immer die logische Erklaerung.

Konrad Rudolph

endline schrieb:

macht es operator[] beim Zugriff langsamer als einen Iterator, da operator[] sich ja nicht die momentane Position merkt?

Generell ja. Zumindest aber sollte es genauso schnell sagen. Alles andere ist wohl von Maschine und Compiler abhängig.

endline

Hab mal folgendes kompiliert:

#include <iostream>
#include <ctime>
#include <vector>

using namespace std;

class Timer
{
	static int counter;
	clock_t start;
	int id;
public:
    Timer()
		:id(counter++)
		,start(clock()) 
	{ 
	}

	~Timer()
	{
		cout<<"Timer "<<id<<" took "
			<<double(clock()-start)/CLOCKS_PER_SEC
			<<" seconds\n";
	}
};

int Timer::counter=0;

int main()
{
	{
		std::vector<int> vec1(99999999);
		Timer timer1;
		for(std::vector<int>::iterator it = vec1.begin(); it!=vec1.end();++it)
			int a = *it;
	}

	{
		std::vector<int> vec2(99999999);
		Timer timer2;
		for(std::size_t i=0; i<vec2.size(); ++i)
			int a = vec2[i];
	}

	return 0;
}

Ausgabe:

Timer 0 took 2.98 seconds
Timer 1 took 8.35 seconds

Damit sehe ich meine Annahme bestaetigt... Sicherlich haengt das auch von der Implementation ab, wie du schon sagtest. Aber ich glaube weiterhin, dass es daran liegt, dass ein Iterator die Position behaelt, operator[] aber nicht.

otze

hast du das als release mit allen optimierungen getestet? müsste dann eigentlich beides denselben asm code ergeben.

endline schrieb:

Ausgabe:

Timer 0 took 2.98 seconds
Timer 1 took 8.35 seconds

Hatte in etwa die selben Zahlen raus, nachdem ich -O3 noch hinzugefügt habe bin ich auf um die 10tel Sekunde gekommen. Erstaunlich wie gut der Compiler optimieren kann

endline

KasF schrieb:

endline schrieb:

Ausgabe:

Timer 0 took 2.98 seconds
Timer 1 took 8.35 seconds

Hatte in etwa die selben Zahlen raus, nachdem ich -O3 noch hinzugefügt habe bin ich auf um die 10tel Sekunde gekommen. Erstaunlich wie gut der Compiler optimieren kann

Kannst du die Ausgabe mit -O3 mal bitte zeigen?

Edit: Vermutlich macht das optimierte Programm gar nichts, da 'a' nicht verwendet und die Schleife auch nicht durchlaufen wird...

Bitte:

Timer 0 took 0.062 seconds
Timer 1 took 0.141 seconds

endline

Danke.

pale dog

Timer 0 took 3.531 seconds
Timer 1 took 1.062 seconds

windoofs, vs express (release, optimize for speed), etwas älterer PC
vor beide 'int a' in der main noch ein 'volatile' davorgesetzt

edit: ohne volatile

Timer 0 took 0.562 seconds
Timer 1 took 0.391 seconds

Konrad Rudolph

pale dog schrieb:

Timer 0 took 3.531 seconds
Timer 1 took 1.062 seconds

Ja, woran liegt's? was sagt die Disassembly? Ist das Ergebnis reproduzierbar?

camper

pale dog schrieb:

Timer 0 took 3.531 seconds
Timer 1 took 1.062 seconds
windoofs, vs express (release, optimize for speed), etwas älterer PC
vor beide 'int a' in der main noch ein 'volatile' davorgesetzt

füg mal noch

#define _SECURE_SCL 0

ein. Bereichsüberprüfungen wollen wir schließlich nicht ausmessen.

pale dog

Konrad Rudolph schrieb:

Ist das Ergebnis reproduzierbar?

nö,
reproduzierbar ist etwa das:

Timer 0 took 1.094 seconds
Timer 1 took 1.078 seconds

bei meinem ersten versuch haben wohl andere tasks dazwischengefunkt.

pale dog

camper schrieb:

füg mal noch
#define _SECURE_SCL 0
ein. Bereichsüberprüfungen wollen wir schließlich nicht ausmessen.

ändert nix, hatte schon vorher in den projekteinstellungen die bereichsüberprüfung ausgeschaltet
btw: mit volatile liegen bei mir beide etwa bei einer sekunde, ohne volatile hatte ich mal eben:

Timer 0 took 0.016 seconds
Timer 1 took 0 seconds

da war wohl gerade scheduler- und interruptmässig nicht viel los