[r-t] Exhausted search spaces

[Mark Davies]

Simon Humphrey writes,

> Surely you don't have a 6 GHz processor, Mark? I thought 3.0 Ghz is
> still about the limit for processor speed/  Modern technology is only
> able to provide more computing power by squeezing multiple processors
> onto the same chip, but that won't speed up single-threaded
> applications.

No, my current machine is a 2.8GHz i7 quad-core, and (for SMC32) it's 
only barely as fast as my previous box, an Athlon X2 4200.

I don't know why your PC is performing so badly on the SMC32 benchmark. 
Possibly your L2 or L3 caches aren't up to scratch, or maybe disabling 
hyperthreading has made it worse. I'm not quite sure why you've done 
that, as I don't think it'll give you any benefits! I could be wrong, 
but I certainly wouldn't expect it to help SMC32.

In terms of I/O, yes in theory that can be a bottleneck. In practice, 
even if you're producing a composition every 30 microseconds, there is 
much more work to do in the search phase than there is in the output 
phase. The number of bytes output for each composition is small, and the 
disk writes are buffered. Given the above, the CPU should never be 
waiting on I/O on a normal search.

Computers and their associated numbers never cease to amaze me, after 
all these years. We still sit around waiting for busy cursors for 
minutes on end, cursing how slow they are - yet with a decent bit of 
code they can search for, prove and output a composition in a few 
microseconds. A microsecond is really too short a time for the human 
brain to properly imagine, but it is actually a vast aeon for a modern 
CPU. You can carry out maybe ten thousand arithmetic operations in a 
microsecond. Awesome.

MBD