[r-t] Exhausted search spaces
mark at snowtiger.net
Fri Feb 5 17:11:52 UTC 2010
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
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
More information about the ringing-theory