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

[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.

[Shade Of Mine]

Die Argumentation ist also, dass Linux unfähig ist Webseiten flüssig anzuzeigen.

OK, das macht Sinn...

[mega confused]

Shade Of Mine schrieb:

Die Argumentation ist also, dass Linux unfähig ist Webseiten flüssig anzuzeigen.

OK, das macht Sinn...

[citrus]

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.

Inzwischen gibt es nicht mal mehr feste ticks: https://lwn.net/Articles/549580/

[citrus]

und davor waren sie auf 250 mal pro Sekunde

[Shade Of Mine]

mega confused schrieb:

Shade Of Mine schrieb:

Die Argumentation ist also, dass Linux unfähig ist Webseiten flüssig anzuzeigen.

OK, das macht Sinn...

Du kannst die Timer Auflösung in Linux nicht ändern. Ergo kann nur Windows flüssig eine HTML Seite darstellen - denn unter Windows ist es ja notwendig die Timer Auflösung für HTML Seiten zu ändern da sie sonst nicht flüssig dargestellt werden können. Linux bietet diese Option nicht, ergo ist Linux zum surfen ungeeignet.

[bullshit!]

Shade Of Mine schrieb:

mega confused schrieb:

Shade Of Mine schrieb:

Die Argumentation ist also, dass Linux unfähig ist Webseiten flüssig anzuzeigen.

OK, das macht Sinn...

Du kannst die Timer Auflösung in Linux nicht ändern. Ergo kann nur Windows flüssig eine HTML Seite darstellen - denn unter Windows ist es ja notwendig die Timer Auflösung für HTML Seiten zu ändern da sie sonst nicht flüssig dargestellt werden können. Linux bietet diese Option nicht, ergo ist Linux zum surfen ungeeignet.

Linux kann Internetseiten flüssig darstellen da es defaultmässig mit timeBeginPeriod(4) oder timeBeginPeriod(10) läuft.

[Shade Of Mine]

bullshit! schrieb:

Linux kann Internetseiten flüssig darstellen da es defaultmässig mit timeBeginPeriod(4) oder timeBeginPeriod(10) läuft.

Das ist aber zu langsam. timeBeginPeriod(1) ist notwendig, sonst ruckelt alles ja furchtbar.

[fürchterlich butthurt]

da ist wohl jemand auf ärger aus...

[hustbaer]

citrus schrieb:

und davor waren sie auf 250 mal pro Sekunde

Davor waren sie das was die jeweilige Distro verwendet hat. Auf bestimmten SUSE Versionen waren es konstant 1000 Hz.