std:chrono mit niedriger realer Auflösung

Xebov

Ich habe bisher immer QueryPerformanceCounter verwendet um meine Zeiten zu messen und wollte jetzt mal prüfen ob sich std::chrono für meine Zwecke eignet. Ich verwende hier VS2012 und hab mir diesen Versuchsaufbau zusammengebaut.

for(int i = 0; i < 20; ++i)
{
	std::chrono::steady_clock::time_point point1 = std::chrono::steady_clock::now();

	for (int i=0;i<100000000;i++)
	{
	}

	std::chrono::steady_clock::time_point point2 = std::chrono::steady_clock::now();

	std::cout << std::chrono::duration<double, std::milli>(point2 - point1).count() << std::endl;
};

Ich habe das Gefühl das ich hier irgendetwas falsch mache. Laut den information die die steady_clock liefert, sollten dort 100ns Auflösung vorliegen (dieser Wert ist in den Headern so hinterlegt und kommt nicht vom System). In Realität bekomme ich mal 10ms und mal 15,6ms Auflösung, was schon recht mager ist.

Mache ich hier irgendwas falsch, oder ist die Auflösung in std::chrono generell eher schlecht?

Caligulaminus

Was sagt denn high_resolution_clock?

Xebov

Die Auflösung ist bei allen 3 Clocks die selbe. high_resolution_clock ist bei MS nur ein typedef auf system_clock. Egal welche Clock ich nehme ich bekome überall diese extrem grobe Auflösung. Sieht fats so aus als biegt MS das ganze intern auf die sehr ungenauen Standard Windowstimer um.

hustbaer

Ich hab mir das das letzte mal mit irgendeinem Release-Candidate angesehen. Da wurde für alles die Windows Systemzeit hergenommen (IIRC einfach GetSystemTimeAsFileTime ).
Ich gehe davon aus dass das immer noch so ist.

Ist natürlich fürchterlich. Vor allem auch weil es für die drei verschiedenen Standard-Clocks unter Windows auch jeweils eine gut passende API gäbe.
(QueryPerformanceCounter für die high resolution Clock und GetTickCount/GetTickCount64 für die steady clock).

Wenn du ein Ticket auf Connect aufmachst bekommst du auf jeden Fall ne Stimme von mir...

Dadurch das Microsoft die Implementierung versaut hat, ist chrono eigentlich nutzlos geworden.

hustbaer

portable progamer schrieb:

Dadurch das Microsoft die Implementierung versaut hat, ist chrono eigentlich nutzlos geworden.

Muss ja nicht auf ewig so bleiben.

cooky451

Also ich hab alles was clocks benutzt (z.B. ne stopwatch) einfach auf die Clock getemplated und mir QueryPerformanceCounter in ein Clock-Interface gesteckt. Dann kann ich einfach das Template-Argument ändern, sollte sich Microsoft mal entscheiden eine ordentliche Implementierung zu benutzen.

Nexus

https://connect.microsoft.com/VisualStudio/feedback/details/719443/c-chrono-headers-high-resolution-clock-does-not-have-high-resolution

Sie haben aufgrund wichtigerer Bugs vorerst keine Zeit, das zu beheben.

Die momentane Alternative ist Boost.Chrono. So kann man später mit minimalen API-Änderungen Std.Chrono benutzen.

cooky451

Sowas finde ich immer interessant. Ich meine, ich will dem guten STL sicher nicht unterstellen Leute hinhalten zu wollen, aber den Bug hätte man auch so in etwa in der Zeit fixen können, in der er diese lange Antwort geschrieben hat. Ich versteh's nicht.

cooky451 schrieb:

Also ich hab alles was clocks benutzt (z.B. ne stopwatch) einfach auf die Clock getemplated und mir QueryPerformanceCounter in ein Clock-Interface gesteckt. Dann kann ich einfach das Template-Argument ändern, sollte sich Microsoft mal entscheiden eine ordentliche Implementierung zu benutzen.

Also ich hab alles, was die Standardbibliothek benutzt, auf eine Eigenimplementation getemplated. So habe ich die grösste Flexibilität und hänge nicht von Bugs in minderwertigen Implementationen (z.B. von Microsoft) ab.

cooky451

Sehr gut.

Xebov

Danke für die Information dazu. Bleib ich also erstmal bei meinem Counter.