Determining the runtime of programs on the i5 / 7 core architecture

Question

When you determine exactly how fast the algorithm works in my programs, I always used QueryPerformanceCounter () in combination with QueryPerformanceFrequency (), however what happens when I use the basic i5 / 7 architecture?

Is it possible that the turbobus will suddenly hit half through my algorithm, and suddenly my performance timer will cease to be accurate because the frequency of my clock is no longer constant or is it really not a problem? If this is a problem, what would be the best way to accurately execute the algorithm?

Answer 1

Simply put, yes, anything can happen. A modern processor simply does a performance assessment in the real world so that the curse is hard to do. This is not limited to the latest Intel x86-64 processor, it applies equally to 8-bit PIC microcontrollers and everything in between.

The only reasonable thing to do is just check more. You will need to perform many retests to get an accurate idea of ​​real-time real-time performance for real equipment for real workloads.

On the other hand, if one algorithm is superior to the other on the same equipment ("on my machine"), then it usually gives similar comparative results for other installations, although it may vary depending on a constant factor.

Answer 2

Here's an interesting article on the topic of QueryPerformanceCounter :

http://www.virtualdub.org/blog/pivot/entry.php?id=106

Apparently, the dude VirtualDub has stopped using it and now prefers timeGetTime . Well read.

I recommend using Boost.Date_Time , especially boost :: posix_time .

Answer 3

There are two separate questions here:

• the reliability of any given time method when changing the processor clock frequency (either an increase, for example, using Turbo Boost, or a decrease due, for example, to energy saving or heat supply) - this is considered in some other answers

• reliability of reference measurements (taking into account reliable watches) - this is more problematic if you are working on optimization and are looking for small improvements, for example. about 10%, it is easy to mislead the effect of the oscillation of the clock from Turbo Boost at al. Possible solutions:

  2.1. disable Turbo Boost and other clock scaling

  2.2. run tests for a long enough time to average clock deviations

Answer 4

The clock source for QPC has traditionally never been clocked out. Motherboard manufacturers have already cut corners, trying to shave a penny or two. Usually they choose the frequency from the inside of the chipset. I heard about some AMD machine that had a 2 GHz QPF, dangerously close to the value that you get for the processor clock after multiplication. Just be nervous if you get so much value.

The absolute value of QPC should never bother you. It will largely depend on the quality of the kernel. Only ever use QPC measurements to look for additional improvements in your code.