Per iteration time

HI Guys,
I have a small doubt. The new version 22.8.1 takes about 0.215 seconds for an iteration of M33362321 whereas the older one took about 0.175 seconds. What's the matter with the new version? My CPU is AthlonXP 1600+.
Thanx

[Prime95]

My guess is that in version 21 you entered the CPU speed as 1600 MHz when the CPU is really running at 1400 MHz. In version 21, the software used the value you entered to compute the per-iteration time. In version 22, it computes your CPU speed for you (and uses a better method for computing the per-iteration time).

So, in short, you've really been running at 0.215 seconds all along.

[crash893]

wat exactly is the iteration time sposed to measure

why does it change when you chage your cpu speed

[Complex33]

In reality the per iteration time does not change when the cpu speed was changed. By changed I mean when the previous version of P95 was told there was a different cpu clock rate, which says nothing about physical changes. In today’s architecture clock rate is important but not the end all be all of the speed of a particular processor, hence AMD's naming scheme.

The per iteration time is a measure of how long it takes to perform one iteration of the LL test, where it is necessary to perform as many iterations as the size of the exponent. In the new P95 version this value is more readily linked to physical time by using a high resolution system clock if available. This measure is also a good indicator of how your system stacks up against others if you look at the benchmark page. For a given FFT size each iteration should roughly take the same amount of time. Averaged over time this will give you an indication of how you are doing.

Complex

[crash893]

so basicly the new version is more acruate becuase

a) you cant screw with the settings ( say you have a 9ghz computer)

and

b) use the high res clock ( how do you know if you have one or not)

it still seems weird to me

i would be like im driving around at 60 miles an hour in my car
then i say its not my old pos it a race car and suddnely the speedomoter says im doing 120

even though i ahvent changed speeds

[Prime95]

Originally Posted by crash893

so basicly the new version is more acruate becuase

a) you cant screw with the settings ( say you have a 9ghz computer)

Yes, version 21 counted the "clock ticks" and divided by the CPU speed you entered to get the per-teration time. This is HIGHLY accurate provided you enter the correct CPU speed.

Version 22 uses the high resolution timer which has been part of every PC for many, many years. This timer ticks about 1.1 million times a second. Accurate enough for our purposes. Windows provides a system call to access this timer. Linux does not - I use the gettimeofday call which is supposed to be accurate to a millionth of a second, but Linux/FreeBSD/otherUnix system does not have to implement this level of accuracy.

Version 22 still supports the version 21 timing method via setting in undoc.txt. One other reason for changing to the new method is that some machines (laptops) run at different CPU speeds based on usage, battery level, etc.

[ADBjester]

Originally Posted by Prime95

My guess is that in version 21 you entered the CPU speed as 1600 MHz when the CPU is really running at 1400 MHz. In version 21, the software used the value you entered to compute the per-iteration time. In version 22, it computes your CPU speed for you (and uses a better method for computing the per-iteration time).

So, in short, you've really been running at 0.215 seconds all along.

George, a question, then.

Most people that have reported benchmarks to you did so on the assumption that the system was accurately measuring the iterations, by noting the start time, performing a bunch of iterations, and then noting the stop time, then merely dividing the elapsed time by the number of iterations performed. That's how I'd have calculated the iteration time, and it wouldn't have mattered what the user entered -- that value would have been useful only to the Individual Account Report on PrimeNet.

Are you saying, though, that the software didn't do that, and simply used the FFT and P-90 baseline, given the Mhz of the machine that was supplied by the USER to calculate a benchmark?

[Prime95]

Originally Posted by ADBjester

Are you saying, though, that the software didn't do that, and simply used the FFT and P-90 baseline, given the Mhz of the machine that was supplied by the USER to calculate a benchmark?

Mostly-correct. Version 21's Options/Benchmark menu choice does use the CPU speed supplied by the USER to generate the timings. 95 times out of a 100 this is OK, since the program accurately guessed the CPU type and speed when the software was installed and the user made no effort to change the CPU speed value.

[NickGlover]

Originally Posted by Prime95

Mostly-correct. Version 21's Options/Benchmark menu choice does use the CPU speed supplied by the USER to generate the timings. 95 times out of a 100 this is OK, since the program accurately guessed the CPU type and speed when the software was installed and the user made no effort to change the CPU speed value.

I'm not certain if ADBjester is asking something else or not, so I'll just add some information here anways. The P90 baseline times are not used at all in the iteration time calculation. Version 21 calculates iteration times ( for benchmarks and during an LL test ) by counting the number of clock cycles it took for your computer to do an iteration. Then it divides this number by the CPU speed reported by the USER to get the time per iteration.

So let's say for a hypothetical iteration, the program counts that it took 1,000,000,000 clocks / iteration ( which is much slower than anything GIMPS actually does right now ). Then if the user said that their computer was a 2000 MHz computer it would divide 1,000,000,000 by this, but first it needs to convert it to just Hz by multiplying by a 1 million, so 2000 MHz = 2,000,000,000 Hz. The reason the iteration time calculation will work is because 1 Hz = 1 clock / second, so when we do the calculation we have:

( 1,000,000,000 clocks / iteration ) / ( 2,000,000,000 clocks / second ) = 0.5 ( clocks * second / iteration * clocks ) = 0.500 seconds / iteration

However, if the machine isn't actually 2000 MHz, but instead is 1000 MHz, the corrected calculation would come out to be: 1.000 second / iteration . Version 21 counts how much time relative to the CPU the iteration took ( that's the number of clocks ), but it depends on the user to tell it how many clocks your CPU can do in second ( i.e. the CPU speed, like 1000 MHz ).

This was easier to see back in Version 17 and 18 when the number of clocks was printed out by default, though it probably is better for all but a few curious people that the number of clocks is not printed out by default anymore. You can see this old behavior in the current v22.8 by setting RdtscTiming=12 in "prime.ini" ( this also makes the iteration time calculation work like it did in v21 and earlier ). The information on this setting comes from the "undoc.txt" file.