[r-t] Big searches

[Mark Davies]

DFM writes,

> Find all the bobs only, tenors together, three part 5088s of Yorkshire
> Major, with part heads 34256 and 42356, and that contain all 24 5678s at
> the back.

Well my main search software (SMC32) is pretty general-purpose so it has no
real optimisations for this kind of thing - for example, I'm not even sure I
can get it to search for particular part-ends, so if a 23564 part end
happened by some bizarre mischance to generate 24 5678s, you'd get it. But
I've set it off on the problem to see what it does. These results are from
my laptop (desktop tied up with the Bristol!) so the processor is a fairly
slow 2GHz Core Due (not Core 2).

My results are:

   31,711,000 nodes,   562 ms,  56,425,000 nodes/s,  28200 nodes/s/Mcycle*
(*if I've understood Don's metric correctly)

So I'm a lot slower than Don's optimised search (562ms compared to 40ms -
he's 14 times faster... not counting his set-up time), although on this very
"small search" I'm not sure I'm that bothered! On a bigger search -
one-part? - Don's optimisations would win convincingly.

Worryingly though, I find far fewer compositions than him. I have a total of
just 14, all with a xxx5678 part end as it happens. Don, are you filtering 
out rotations? My software drops rotations (or rather only finds them once), 
but doesn't detect reversals or adding and removing "shunts". If Don is 
dropping rotations then something's very wrong somewhere. Maybe I've got a 
bug, arse.

MBD