Prime95 version 26.4

[science_man_88]

Originally Posted by Bdot

I have a multi-boot machine that runs WinXP (32-bit) and Windows 7 (64-bit). As it is the same machine I used the same prime95 directories, just put both the 32-bit and 64-bit versions of prime95, v. 26.4.1.0 in there, and run the appropriate one.

Now, the 64-bit one did a check which FFT size to use:

Trying 1000 iterations for exponent 53372357 using 2800K FFT.
If average roundoff error is above 0.24273, then a larger FFT will be used.
Final average roundoff error is 0.2021, using 2800K FFT for exponent 53372357.

And writes that also to worktodo.txt.
Test=<ID>,FFT2=2800K,53372357,69,1

When the 32-bit version finds that new syntax in worktodo.txt, it complains:

Cannot initialize FFT code, errcode=1002
Number sent to gwsetup is too large for the FFTs to handle.

And stops the thread.

Removing the ",FFT2=2800k" part from worktodo.txt allows resuming work.
Test=<ID>,53372357,69,1


Looks as if 64-bit and 32-bit of the same version (26.4.1.0) are not on the same code ?

this doesn't surprise me does it surprise you. maybe that FFT length is 64 bit specific.

[Bdot]

The 32-bit version uses a 2880k FFT, but it does not write this info to the worktodo.txt, nor did it need to run a test about that.

I figure that the different FFT length is a runtime-thing that is not put into the save files. So it should be able to pick up where another version (with another FFT-length) left off. With 26.3 it worked that way. And with 26.4 it also works, if I remove that extra info from the worktodo.txt.

[Prime95]

Originally Posted by Bdot

When the 32-bit version finds that new syntax in worktodo.txt, it complains:

Cannot initialize FFT code, errcode=1002
Number sent to gwsetup is too large for the FFTs to handle.

And stops the thread.

Removing the ",FFT2=2800k" part from worktodo.txt allows resuming work.

and what FFT size did the 32-bit version use? 4M?

Is this a Pentium4/Celeron with 256K of L2 cache? If so, this is the bug that you'll find reported in the 2nd post to this thread. To work around the problem until a new version is available, add CpuL2CacheSize=512 to your local.txt file. Also, consider switching to double-checks - these small cache CPUs thrash terribly on large FFTs.

[Commaster]

Originally Posted by tichy

xor reg, reg is basically the same as sub reg, reg. For actual timings you have to do your own measurements, since latency/throughput cycle data from intel manuals are informational only. However, in these manuals at least you will find there number of machine opcodes required for any of these operations.

Running some simple benchmarks resulted in win for xor.

Originally Posted by tichy

As for the multithreaded work...

I was surely talking about multi-threaded work on same or more multi-cored CPU. So, as I understand, not much "work"-thread schedule for each core.

[NBtarheel_33]

Originally Posted by Prime95

Also, consider switching to double-checks - these small cache CPUs thrash terribly on large FFTs.

This "thrashing" - would it be severe enough to cause the PC to become unusable for other work?

[Prime95]

Originally Posted by NBtarheel_33

This "thrashing" - would it be severe enough to cause the PC to become unusable for other work?

No, it simply makes the FFTs run slowly. There isn't enough room in the L2 cache to prefetch data that will be needed soon.

The thashing that makes a computer unusable is when main memory is tight and it gets sent to/from your slow disk.

This thrashing is when cache memory is tight and it gets sent to/from your relatively fast main memory.

[NBtarheel_33]

Originally Posted by Prime95

This thrashing is when cache memory is tight and it gets sent to/from your relatively fast main memory.

OK, but could this slow things down if the system has (relatively) low RAM?

[Rhyled]

Originally Posted by NBtarheel_33

OK, but could this slow things down if the system has (relatively) low RAM?

The thrashing George is talking about will only affect programs that are highly cpu limited and are processing huge amounts of data e.g. Prime95.

If you're running a browser or other light cpu task, you won't notice the effect. If you happen to be burning a DVD - with lots of compression calculation going on - you might see a noticeable slow down as the processor is having to swap even more data in and out of cache as it bounces between the different applications.

Very roughly speaking, cache memory is 10x faster than system RAM, which in turn is 100x faster than swapping to the hard drive. If your system is RAM starved and has to swap a lot to disk, the cache issue is going to be inconsequential because the disk swap is the primary slowdown.

[chris2be8]

Originally Posted by Rhyled

Very roughly speaking, cache memory is 10x faster than system RAM, which in turn is 100x faster than swapping to the hard drive.

System ram is more like 100,000x faster than swapping to the hard drive. A hard drive takes 5-10 milli-seconds to read a block into memory, system ram takes about 50 nano-seconds to return a cache line. Granted a block is bigger than a cache line but you don't always need all the data in a block.

The above times are only estimates, but the lesson is to avoid swapping if at all possible. And if you wear out your hard disk you will find out how good your backups are.

Chris K

[Bdot]

Originally Posted by Prime95

and what FFT size did the 32-bit version use? 4M?

Is this a Pentium4/Celeron with 256K of L2 cache?

The 32-bit version uses a 2880k FFT (so that is 80k more).

The machine is a Core i7 M620 @2.6GHz with 32k/256k/4MB cache. The L2 cache is just 256k, but as there is 4MB L3 cache, wouldn't that be OK?

I noticed though that my old Xeon 5140 @ 2.33GHz with just 32k/4MB cache is faster on that ...

[joblack]

Originally Posted by tichy

xor reg, reg is basically the same as sub reg, reg. For actual timings you have to do your own measurements, since latency/throughput cycle data from intel manuals are informational only. However, in these manuals at least you will find there number of machine opcodes required for any of these operations

Earlier cpus were faster with xor reg,reg but it might be that recent cpus have lost that advantage. Anyway it is just cooler to use xor reg,reg so it appears to be l337. ;)