intel core duo optimizer

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Intel and AMD (in Athlon64 and Barcelona/Phenom, at least) handle a feature called the "timestamp counter" differently. Each method has its advantages and disadvantages. There are performance advantages to AMD's method*, but one disadvantage is that applications can't assume certain things about the value returned by the "RDTSC" instruction when the OS moves them between cores. Applications are supposed to use API calls to read the timestamp counter; the OS knows what assumptions are/aren't safe and makes sure to return a value that an application will expect. Some applications behave poorly (they ask the CPU directly for the timestamp value, rather than using API calls that they're supposed to use) and this causes issues like wildly varying framerates or stuttering, so the AMD Dual-Core Optimizer implemented a very simple workaround (which, as I understand it, gives you the best of both worlds). Intel dual-core processors don't need a workaround, but sacrifice performance. This is my understanding based on Wikipedia and the description of the AMD Dual-Core Optimizer found here. I'm not speaking for any companies.

* This thread indicates that on AMD processors, RDTSC takes <10 cycles, but it takes >60 cycles on Intel processors.
 

brandonb

Diamond Member
Oct 17, 2006
3,731
2
0
No, the dual core optimizer on AMD is actually a bug fix (technically a work around for bad coding practices)

The reason is this (as CTho9305 indicated):

There is a command called "QueryPerformanceCounter" which gives the number of cpu cycles since the start of the computer.

The AMD dual cores actually run at different speeds. One core might be at 2.4ghz, the other at 2.3999999999999ghz. Also if you have CoolNQuiet turned on, it reduces the speed of the CPU based on usage so the different cores can move at different speeds at any given second.

That said,

If you have a program with multiple threads, which most programs do today for increased in speed on dual core systrems, and you call that command to see how many cycles have elapsed, the different cores can be out of sync. You can't use the numbers from other threads as that causes problems. Thread 1 might say we are on cycle 1000 at the start of an operation, then if we are animating artwork such as a character on screen in a game, you have to move the the animation based on time. So, if you have another thread which is performing that math on the animation and it reads the current time so it knows what to move and how far, it may say its at cycle 990. Due to the cores running at different speed. So how did we go back in time 10 cycles? From the start of the operation?

The dual core optimizer changes that command "QueryPerformanceCounter" to move the timing away from the cores, and bases it off the north or south bridge of the computer, which is a single core so to speak so the numbers never get skewed.

Intel has always done this way to begin with. It was a shortcut on AMD to get better performance so the command didn't have to jump from CPU to north bridge to southbridge and back. However, it requires any calls to QueryPerformanceCounter to always be used from the same thread. Not all software is written that way so they made the optimizer to change it. The optimizer is actually a deoptimizer.

I know thats whats going on, because I've ran into that problem personally with games I've programmed, so I know exactly what command it is and why it was doing it. ;)
 

daveybrat

Elite Member
Super Moderator
Jan 31, 2000
5,792
1,008
126
Like everyone else said, there is no patch needed on Windows XP systems with an Intel processor, only on the AMD X2 series.

And if you're running Windows Vista, no patch needed for any processor. :)