Achtung: Chrome entleert euren Laptop-Akku schneller als nötig

[640k]

Warum sollte das Flash brauchen? ~60 FPS sind doch wirklich genug für everyone.

[hustbaer]

Viel mehr als lol hab ich dazu nicht zu sagen.

[seen]

hustbaer schrieb:

Viel mehr als lol hab ich dazu nicht zu sagen.

und wie soll man dein lol jetzt interpretieren? positiv oder eher negativ?

[hustbaer]

OK, also sag ich doch mehr.

Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

Anwendungen die darauf angewiesen sind dass der Scheduler global mit 1ms arbeitet wird es dagegen vermutlich recht wenige geben.

D.h. es wäre angesagt hier am Scheduler bzw. allgemein der Art & Weise wie das System mit Timer-Interrupts umgeht was zu schrauben, und zwar gröber. Und den Anwendungen dann genau die Dinge zu ermöglichen die sie brauchen. Wenn ein Programm nur schnellere Timer-Updates braucht, dann muss auch nur der Timer 1x pro ms upgedatet werden. Der Scheduler muss deswegen aber nicht 1x pro ms anlaufen und rumschedulen.

Genau so sollte es möglich sein Sleep() mit <= 1ms Genauigkeit zu ermöglichen, ohne dass dazu gleich global und für einen längeren Zeitraum der Timer-Interrupt beschleunigt werden muss.

Das OS könnte den Programmen z.B. die Möglichkeit geben bei Sleep einen Hint mitzugeben wie genau es denn sein soll. Und eine Funktion mit der das Programm dem OS generell sagen kann wie genau es seine genauesten Sleeps so braucht.

----

Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

p.S.:
Und wenn jemand "It was affected. A lot." schreibt, dann erwarte ich mir dass die Zahlen die darauf folgen grösser als 2.5~5% sind -- die ich nebenbei gesagt schonmal anzweifle, bis ich sie selbst nachgemessen habe. Bzw. es wäre interessant über welches System wir da reden.

[hustbaer]

BTW:
CatalystControlCenter verwendet anscheinend auch WPF, und läuft immer im Hintergrund mit. Auch dämlich. Vor allem wo ich CCC so eingestellt hab' dass es kein Tray-Icon anzeigt. Nachdem ich jetzt selbst sudere: einfacher Fix: CCC.exe muss nicht permanent als Hintergrund-Prozess mitlaufen. Nichtmal wenn es ein Tray-Icon anzuzeigen gäbe, denn dafür tut es ein klitzekleiner Tray-Icon-Hilfsprozess. Und der braucht dann kein WPF.

Bzw. noch ein LOOOOL aus dem Artikel

I don’t have the powercfg output for it but C:\Windows\System32\quartz.dll is another cause of an increased timer frequency. I’m not even sure what Quarts is (Expression Web Designer?) but I know it is sometimes wasting energy.

#1 Dumpfbacke, kannst quartz nichtmal richtig abtippen
#2 Dumpfbacke, wenn du schon rumsuderst dann investiere doch die 30 Sekunden dir zu ergoogeln dass die quartz.dll das Zuhause für alle möglichen DirectShow Filter ist. Und DirectShow... nuja..., Video und so, Graph Reference-Clock und so - neeeeeeee, da braucht man sicher keine gute Timer-Auflösung, total bekloppt.
Also #3 Dumpfbacke weil du weisst nichtmal von was du redest bist dir aber trotzdem sicher dass das Ding auf jeden Fall Energie verschwendet. Pah. Fatzke.

(Dass "du" hier ist natürlich auf den Autor des Blog-Beitrags bezogen, nicht auf irgendwen hier im Forum)

[SeppJ]

Also ich fand's interessant, dass die gemessenen Zeiten ausgerechnet im Bereich 3.9 bis 4.1 lagen. Mag sein, dass er das wirklich ganz naiv unschuldig so gemessen hat. Aber irgendwie drängte sich mir beim Lesen ein Vergleich mit den Preisen im Supermarkt auf.

[tickless]

Fakt ist das Microsoft den Developern vom Nutzen dieser Funktion abrät.

[Zeus]

tickless schrieb:

Fakt ist das Microsoft den Developern vom Nutzen dieser Funktion abrät.

Wo?

[Shade Of Mine]

Junge junge...

timeBeginPeriod sollte nur verwendet werden, wenn es unbedingt notwendig ist. Weil es eben die Performance des Systems und den Energieverbrauch negativ beeinflusst. Warum das so ist, liegt ja auf der Hand.

Microsoft raet aktiv davon ab das zu missbrauchen. zB:

http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx schrieb:

If an application must use a high-resolution periodic timer, consider disabling use of the periodic timer and associated functionality when a Power Saver power plan is active or when the system is running on battery power.

Apple hat deshalb zB in OS X 10.9 Timer Coalescing eingefuehrt.
http://www.apple.com/osx/preview/advanced-technologies.html

Das ganze ist auf Desktoprechnern irrelevant, aber auf low tech systemen die immer populaerer werden (subnotebooks, tables, smartphones,...) ist sowas sehr wichtig.

[640k]

Microsoft spricht von bis zu 25% mehr Verbrauch: http://msdn.microsoft.com/en-us/library/windows/hardware/gg463269.aspx

[640k]

Sorry, falscher Link. Hier der richtige: http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx

[dot]

hustbaer schrieb:

Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

Dennoch fällt mir kein guter Grund ein, wieso ein Webbrowser dies tun sollte, wenn ich grad nur meine Einkaufsliste angucken will...

hustbaer schrieb:

Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

Ja, das Problem kenn ich nur zu gut. Inwiefern das für das Anzeigen statischer HTML Seiten relevant ist, ist mir allerdings unklar. Abgesehen davon, sollte man sich da imo erstmal gewisse andere Fragen stellen. Wie z.B. wieso die Composition aus sein muss, wieso es Windowed sein muss und natürlich vor allem, wieso ordentliche Lösungen wie z.B. http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559.aspx nicht in Frage kommen.

hustbaer schrieb:

Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

Also ich weiß nicht; wenn du mich fragst, ist das allerletzte, was ich gerne machen möchte, wenn ich meinen Code profilen will, die Messergebnisse zu verfälschen, indem ich meinem System schnell mal 16x so viele Context Switches pro Sekunde spendiere als nötig. Viel sinnvoller wär da wohl eher z.B. das. Außerdem ist das auch wieder kein für den Produktiveinsatz beim Endkunden relevanter Anwendungsfall.

hustbaer schrieb:

Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

In vielen Fällen wäre wohl z.B. das die bessere Lösung: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247.aspx

hustbaer schrieb:

Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

Konkreter Vorschlag um es im konkreten Fall besser zu machen: Kein timeBeginPeriod() verwenden wenn nicht notwendig. Ich bin selbst überzeugter Chrome User, aber ein Webbrowser hat, zumindest ohne wirklichen Grund, verdammt nochmal die Finger von meinen Heartbeat zu lassen...

[mint]

Komischerweise kommt Linux doch auch mit einer festen Tick-Rate aus, die sich nicht zur Laufzeit ändern lässt. Und kann auch Multimedia ganz gut.

[hustbaer]

dot schrieb:

hustbaer schrieb:

Es gibt mMn. gute Gründe dafür, dass man möchte dass der System-Timer mit 1ms upgedated wird. Es gibt auch gute Gründe dafür dass man möchte dass z.B. Sleep(7) nicht >= 15~16ms dauert, sondern (meistens, ist ja nicht garantiert) wirklich etwa 7-8ms.

Dennoch fällt mir kein guter Grund ein, wieso ein Webbrowser dies tun sollte, wenn ich grad nur meine Einkaufsliste angucken will...

Weil die Leute alle rummoppeln wenn das Scrollen nicht flüssig läuft. Bzw. irgendwelche Plugins, die zu doof sind selbst timeBeginPeriod() zu machen.

dot schrieb:

hustbaer schrieb:

Beispiel: versuch mal nen Tearing-freien Present im Windowed-Mode mit D3D9 zu machen wenn die Desktop-Composition (die selbst nicht wenig Power frisst) deaktiviert ist. Bzw. auf XP Systemen wo es keine Desktop-Composition gibt. Das bedeutet nämlich du musst Sleep()en so lange es geht, und den Rest dann mit busy-wait warten. Also noch schlimmere Stromverschwendung. Jetzt kannst du dir aussuchen ob du 1-2ms pro Frame mit busy-wait verbringst, oder die gesamte Wartezeit (bei 60 fps verbietet sich bei ~15ms Timer-Frequenz jedes Sleep). Ja, klar, ein Programm könnte im Pause Mode, bzw. wenn eben kein Video läuft zurückgehen auf 15ms. Klingt aber einfacher als es umzusetzen ist.

Ja, das Problem kenn ich nur zu gut. Inwiefern das für das Anzeigen statischer HTML Seiten relevant ist, ist mir allerdings unklar. Abgesehen davon, sollte man sich da imo erstmal gewisse andere Fragen stellen. Wie z.B. wieso die Composition aus sein muss, wieso es Windowed sein muss und natürlich vor allem, wieso ordentliche Lösungen wie z.B. http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559.aspx nicht in Frage kommen.

Siehe oben, Scrollen. Und die saubere Lösung kommt nicht in Frage, weil es halt noch andere Plattformen als Windows Phone 8 gibt.

dot schrieb:

hustbaer schrieb:

Anderes Beispiel: du willst die Ausführungszeit verschiedener Funktionen/Blöcke in deinem Programm messen, und dazu an vielen vielen Stellen im Programm sehr sehr oft die Zeit abfragen. Die billigste Funktion mit der das geht ist GetTickCount. Läuft zig bis hundert mal schneller als alle Alternativen. Damit GetTickCount ne brauchbare Auflösung hat brauchst du aber timeBeginPeriod(1) . Also machst du es, weil es unter Vollast immer noch die billigste Alternative ist.

Also ich weiß nicht; wenn du mich fragst, ist das allerletzte, was ich gerne machen möchte, wenn ich meinen Code profilen will, die Messergebnisse zu verfälschen, indem ich meinem System schnell mal 16x so viele Context Switches pro Sekunde spendiere als nötig. Viel sinnvoller wär da wohl eher z.B. das. Außerdem ist das auch wieder kein für den Produktiveinsatz beim Endkunden relevanter Anwendungsfall.

Also die Beschreibung liest sich danach als ob es mit RDTSC implementiert wäre. Was schonmal nicht ganz doof wäre. Dummerweise komm ich damit auf keine Zeit, sondern nur auf relativ zueinander vergleichbaren Werten, die halt die verbratenen Zyklen angeben.
Und woher willst du sagen dass es kein für den Einsatz beim Kunden relevanter Fall ist?

dot schrieb:

hustbaer schrieb:

Hier einfach nur mit dem Finger auf die Applikationen zu zeigen und "booh!" zu rufen halte ich für wenig sinnvoll und auch nicht zielführend.
Das mindeste was ich mir erwarten würde, wäre eine Liste der üblichsten Szenarien die Programmierer dazu veranlassen timeBeginPeriod(1) zu machen, inklusive (praktikablen) Vorschlägen wie man es besser machen kann.

In vielen Fällen wäre wohl z.B. das die bessere Lösung: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247.aspx

Hat mit dem was ich geschrieben habe nix zu tun. Damit bekomm ich weder genauere Zeitmessung noch genauere Sleeps.

dot schrieb:

hustbaer schrieb:

Auf Artikel in denen einfach nur rumgesudert wird dass die timeBeginPeriod(1) Programme/Programmierer so pöse sind, ohne konkrete Vorschläge wie man es besser machen kann, kann ich mir als Reaktion aber spontan nicht mehr als ein "lol" abringen.

Konkreter Vorschlag um es im konkreten Fall besser zu machen: Kein timeBeginPeriod() verwenden wenn nicht notwendig. Ich bin selbst überzeugter Chrome User, aber ein Webbrowser hat, zumindest ohne wirklichen Grund, verdammt nochmal die Finger von meinen Heartbeat zu lassen...

dot's Herz schlägt mit Windows
Ne, ich weiss schon was du meinst, bin ja nicht doof

Ja, OK. Sollte. Blub. Ist es ein QI Problem? Vermutlich ja. Gibt es meistens bessere Lösungen? Vermutlich auch ja. Gibt es in quasi jeder Software wichtigere Probleme? Darfst du selbst beantworten.

Es darf ja gerne jeder schreiben dass das nicht optimal ist, und geändert werden sollte. Aber so zu tun als ob das jetzt voll wichtig wäre, und blah, Drama Queen, MS voll pöse und Google voll pöse und ... also ne.

[hustbaer]

mint schrieb:

Komischerweise kommt Linux doch auch mit einer festen Tick-Rate aus, die sich nicht zur Laufzeit ändern lässt. Und kann auch Multimedia ganz gut.

Ich vermute mal: weil dort die Timer bzw. die kürzeste von sleep() unterstützte Zeit nicht an den System-Heartbeat gekoppelt ist. Was ich auch für Windows vorschlagen würde.

[hustbaer]

Ach, nochwas: wieso hat schon ein Pentium 60 mit Win95/Win98 nen Heartbeat von 1ms geschafft, und nebenher noch Zeit gehabt Programme laufen zu lassen ... aber auf aktuellen Systemen kostet es immer noch 2,5~5% Leistung? ... öööööööh?
Does not compute.

(Mir ist schon klar dass der Vergleich nicht ganz fair ist, weil auf modernen Systemen ca. 100x (übertrieben) mehr im Hintergrund läuft als auf nem nackten Win95. Nur haben moderne Systeme auch die 100-fache (untertrieben) Rechenleistung...)

[zwutz]

dot schrieb:

Inwiefern das für das Anzeigen statischer HTML Seiten relevant ist, ist mir allerdings unklar.

Webseiten sind seit wohl 15 Jahren nicht mehr statisch. Dazu kommt, wie hustbaer sagt, dass es auch Plugins gibt, die das brauchen können. Und die laufen in einem Container innerhalb von Chrome, haben also wohl kaum Zugriff auf Systemfunktionen

[hustbaer]

Wobei es durchaus OK wünschenswert wäre wenn sie ne Option machen. Ich würde allerdings empfehlen Default auf "timeBeginPeriod(1)" zu machen.

[hustbaer]

So, Ergebnisse meines eigenen kleinen Tests...
Weniger Optimization-gefährdet, weniger Memory-Bound, mehr Sinn (hoffentlich).

Thread count: 4
RNG engine: ranlux64_3
Block size: 10000
Keys:
    1 ... 9 : request timer resolution of 1 ... 9 milliseconds
    0       : clear timer resolution request
    x       : exit

Mega-iterations/sec 28.23039
Mega-iterations/sec 27.81525
Mega-iterations/sec 28.12061
Mega-iterations/sec 28.21894
Mega-iterations/sec 28.23874
Mega-iterations/sec 28.23861
Mega-iterations/sec 28.21896
Mega-iterations/sec 28.12054
Mega-iterations/sec 28.14999
Mega-iterations/sec 28.22888
Mega-iterations/sec 28.22883
Mega-iterations/sec 28.23867
Mega-iterations/sec 28.18938
Mega-iterations/sec 28.21900
Mega-iterations/sec 28.22880
Mega-iterations/sec 28.21902
Requested timer resolution: 1
Mega-iterations/sec 28.19611
Mega-iterations/sec 28.06250
Mega-iterations/sec 28.07248
Mega-iterations/sec 28.16241
Mega-iterations/sec 28.18237
Mega-iterations/sec 28.17235
Mega-iterations/sec 28.15240
Mega-iterations/sec 28.16239
Mega-iterations/sec 28.18238
Mega-iterations/sec 28.15237
Mega-iterations/sec 28.16240
Mega-iterations/sec 28.12237
Mega-iterations/sec 28.05256
Mega-iterations/sec 28.02250
Mega-iterations/sec 28.19240
Mega-iterations/sec 28.15239
Mega-iterations/sec 28.17239
Mega-iterations/sec 27.99253
Mega-iterations/sec 28.15241
Mega-iterations/sec 28.15240
Removed timer resolution request.

Mega-iterations/sec 28.20551
Mega-iterations/sec 28.22876
Mega-iterations/sec 28.11067
Mega-iterations/sec 28.09078
Mega-iterations/sec 28.18969
Mega-iterations/sec 28.15002
Mega-iterations/sec 28.23871
Mega-iterations/sec 28.21894
Mega-iterations/sec 28.22879
Mega-iterations/sec 28.16972
Mega-iterations/sec 28.17941
Mega-iterations/sec 27.80536
Mega-iterations/sec 28.17982
Mega-iterations/sec 28.20912
Mega-iterations/sec 28.21900
Mega-iterations/sec 28.22866
Mega-iterations/sec 28.23860
Mega-iterations/sec 28.23893
Mega-iterations/sec 28.20907
Mega-iterations/sec 28.18948
Mega-iterations/sec 28.19925
Mega-iterations/sec 28.14016
Mega-iterations/sec 28.16979
Stopping...

Mega-iterations/sec 5.08054
Final accumulator value: 631551148
Final iterations: 1686790000
Bye.

Also ca. 0.25% Impact.
Also ziemlich genau 1/10 von dem was in dem Blog-Beitrag steht. Kommt mir immer noch viel vor, aber naja.

System:
Windows 8 amd64, Q6600, 8 GB RAM
"nix" im Hintergrund laufen, Timer Resolution mit clockres.exe und powercfg -energy nachkontrolliert = normal 15.6ms, mit timeBeginPeriod(1) auf 1ms.
Programm läuft als 32 Bit Prozess (WoW64).

Code:

#include <stdio.h>
#include <conio.h>
#include <thread>
#include <Windows.h>

#include <boost/random.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/algorithm/string/predicate.hpp>
#include <boost/preprocessor/stringize.hpp>
#include <boost/utility/enable_if.hpp>
#include <boost/type_traits.hpp>

#pragma comment(lib, "winmm")

LARGE_INTEGER g_performanceCounterFrequency;
volatile unsigned long g_accumulator;
volatile unsigned long g_iterations;
volatile long g_break;

double GetTime()
{
	LARGE_INTEGER counter;
	QueryPerformanceCounter(&counter);
	return counter.QuadPart / double(g_performanceCounterFrequency.QuadPart);
}

template<class Engine>
void WorkerFn(typename boost::enable_if<boost::is_floating_point<typename Engine::result_type>, unsigned>::type blockSize)
{
	Engine generator;
	generator.seed();

	while (!g_break)
	{
		unsigned long accumulator = 0;
		for (unsigned i = 0; i < blockSize; i++)
			accumulator += static_cast<unsigned long>((generator() + 1.0) * 123456789) & 0xFFFF;

		::InterlockedExchangeAdd(&g_accumulator, accumulator);
		::InterlockedExchangeAdd(&g_iterations, blockSize);
	}
}

template<class Engine>
void WorkerFn(typename boost::enable_if<boost::is_integral<typename Engine::result_type>, unsigned>::type blockSize)
{
	Engine generator;
	generator.seed();

	while (!g_break)
	{
		unsigned long accumulator = 0;
		for (unsigned i = 0; i < blockSize; i++)
			accumulator += generator() & 0xFFFF;

		::InterlockedExchangeAdd(&g_accumulator, accumulator);
		::InterlockedExchangeAdd(&g_iterations, blockSize);
	}
}

void TickerFn()
{
	::SetThreadPriority(::GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

	double time1 = GetTime();
	unsigned long iterations1 = ::InterlockedCompareExchange(&g_iterations, 0, 0);

	while (!g_break)
	{
		double time0 = time1;
		unsigned long iterations0 = iterations1;

		::Sleep(1000);

		time1 = GetTime();
		iterations1 = ::InterlockedCompareExchange(&g_iterations, 0, 0);

		unsigned long deltaIterations = iterations1 - iterations0;
		double deltaTime = time1 - time0;

		printf("Mega-iterations/sec %.5f\n", deltaIterations / deltaTime / (1000.0*1000.0));
	}
}

#define ENGINE_DEFINITION_ENTRY(engineName) \
	{ BOOST_PP_STRINGIZE(engineName), &WorkerFn<boost::engineName> }

static struct EngineDefinition
{
	char const* const engineName;
	void (*workerThreadFn)(unsigned);
}
const engineDefinitions[] = {
	ENGINE_DEFINITION_ENTRY(ranlux64_3),
	ENGINE_DEFINITION_ENTRY(minstd_rand0),
	ENGINE_DEFINITION_ENTRY(minstd_rand),
	ENGINE_DEFINITION_ENTRY(rand48),
	ENGINE_DEFINITION_ENTRY(ecuyer1988),
	ENGINE_DEFINITION_ENTRY(kreutzer1986),
	ENGINE_DEFINITION_ENTRY(taus88),
	ENGINE_DEFINITION_ENTRY(hellekalek1995),
	ENGINE_DEFINITION_ENTRY(mt11213b),
	ENGINE_DEFINITION_ENTRY(mt19937),
	ENGINE_DEFINITION_ENTRY(mt19937_64),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci607),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci1279),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci2281),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci3217),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci4423),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci9689),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci19937),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci23209),
	ENGINE_DEFINITION_ENTRY(lagged_fibonacci44497),
	ENGINE_DEFINITION_ENTRY(ranlux3),
	ENGINE_DEFINITION_ENTRY(ranlux4),
	ENGINE_DEFINITION_ENTRY(ranlux64_4),
	ENGINE_DEFINITION_ENTRY(ranlux3_01),
	ENGINE_DEFINITION_ENTRY(ranlux4_01),
	ENGINE_DEFINITION_ENTRY(ranlux64_3_01),
	ENGINE_DEFINITION_ENTRY(ranlux64_4_01),
};

#undef ENGINE_DEFINITION_ENTRY

void Run(unsigned threadCount, EngineDefinition const* engineDefinition, unsigned blockSize)
{
	printf("Thread count: %d\n", threadCount);
	printf("RNG engine: %s\n", engineDefinition->engineName);
	printf("Block size: %d\n", blockSize);
	puts("Keys:\n"
		"    1 ... 9 : request timer resolution of 1 ... 9 milliseconds\n"
		"    0       : clear timer resolution request\n"
		"    x       : exit\n");

	QueryPerformanceFrequency(&g_performanceCounterFrequency);

	::SetThreadPriority(::GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL);

	std::vector<std::thread> threads;
	for (unsigned i = 0; i < threadCount; i++)
		threads.emplace_back(engineDefinition->workerThreadFn, blockSize);

	threads.emplace_back(&TickerFn);

	UINT activeResolution = 0;
	while (!g_break)
	{
		int const ch = _getch();

		if (ch >= '0' && ch <= '9')
		{
			if (activeResolution)
			{
				::timeEndPeriod(activeResolution);
				activeResolution = 0;
			}

			UINT requestedResolution = ch - '0';
			if (requestedResolution)
			{
				if (::timeBeginPeriod(requestedResolution) != TIMERR_NOERROR)
				{
					puts("ERROR: timeBeginPeriod failed.");
					exit(1);
				}
				activeResolution = requestedResolution;
				printf("Requested timer resolution: %d\n", activeResolution);
			}
			else
				puts("Removed timer resolution request.\n");
		}
		else if (ch == 'x')
		{
			puts("Stopping...\n");
			g_break = 1;
		}
	}

	for (auto& t : threads)
		t.join();

	printf("Final accumulator value: %ld\n", g_accumulator);
	printf("Final iterations: %ld\n", g_iterations);
	puts("Bye.\n");
}

void Run(std::vector<std::string> const& args)
{
	unsigned threadCount = std::thread::hardware_concurrency();
	unsigned blockSize = 10000;

	EngineDefinition const* engineDefinition = &engineDefinitions[0];

	for (size_t i = 0; i < args.size(); i++)
	{
		if (boost::iequals(args[i], "-t"))
		{
			threadCount = boost::lexical_cast<unsigned>(args.at(i + 1));
			i++;
		}
		else if (boost::iequals(args[i], "-b"))
		{
			blockSize = boost::lexical_cast<unsigned>(args.at(i + 1));
			i++;
		}
		else if (boost::iequals(args[i], "-e"))
		{
			std::string const engineName = args.at(i + 1);
			i++;
			bool found = false;
			for (auto const& edef : engineDefinitions)
			{
				if (boost::iequals(engineName, edef.engineName))
				{
					engineDefinition = &edef;
					found = true;
					break;
				}
			}
			if (!found)
			{
				printf("ERROR: Unknown engine %s", engineName.c_str());
				exit(1);
			}
		}
		else 
		{
			printf("ERROR: Unknown option %s", args[i].c_str());
			exit(1);
		}
	}

	Run(threadCount, engineDefinition, blockSize);
}

int main(int argc, char* argv[])
{
	try
	{
		Run(std::vector<std::string>(argv + 1, argv + argc));
	}
	catch (std::exception const& e)
	{
		printf("ERROR: %s\n       (%s)\n", e.what(), typeid(e).name());
		exit(1);
	}
}

[quoter]

brucedawson schrieb:

Fascinating. I think that means that Windows 8 is only running the timer interrupt on some cores. Or something like that.