well i reckon its all about # of cores and time stamps but thats the first my computer has told me WARNING! ha...found this in a google search nothing else really comes up....
Originally Posted by snelan
Not sure, but I think that test still reflected your correct score
The RDTSC instruction has, until recently, been an excellent high-resolution, low-overhead way of getting CPU timing information. With the advent of multi-core/hyperthreaded CPUs, systems with multiple CPUs, and "hibernating" operating systems, RDTSC often no longer provides reliable results. The issue has two components: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no longer any promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. So, you can no longer get reliable timestamp values unless you lock your program to using a single CPU. Even then, the CPU speed may change due to power-saving measures taken by the OS or BIOS, or the system may be hibernated and later resumed (resetting the time stamp counter).
I might be understanding this wrong but... Basically both RDTSC and QPC are used to time code in time-sensitive programs. However, RDTSC might be inaccurate in above described situations. I also might be wrong about this but I believe QPC has something to do with the HPET high precision event timer. Which is a more accurate timer.
Reliance on the time stamp counter also reduces portability, as other processors may not have a similar feature. Recent Intel processors include a constant rate TSC (identified by the constant_tsc flag in Linux's /proc/cpuinfo). With these processors the TSC reads at the processor's maximum rate regardless of the actual CPU running rate. While this makes time keeping more consistent, it can skew benchmarks, where a certain amount of spin-up time is spent at a lower clock rate before the OS switches the processor to the higher rate. This has the effect of making things seem like they require more processor cycles than they normally would.
Under Windows platforms, Microsoft strongly discourages using the TSC for high-resolution timing for exactly these reasons, providing instead the Windows APIs QueryPerformanceCounter and QueryPerformanceFrequency. Even when using these functions, Microsoft recommends the code to be locked to a single CPU. Under Linux, similar functionality is provided by reading the value of CLOCK_MONOTONIC clock using POSIX clock_gettime function.
Starting with the Pentium Pro, Intel processors have supported out-of-order execution, where instructions are not necessarily performed in the order they appear in the executable. This can cause RDTSC to be executed later than expected, producing a misleading cycle count. This problem can be solved by executing a serializing instruction, such as CPUID, to force every preceding instruction to complete before allowing the program to continue or by using RDTSCP instruction, which is a serializing variant of the RDTSC instruction (starting from Core i7)
hummmmmmmmmmmEdited by ryan w - 6/11/11 at 9:56pm