Is 8/16 bit computing inappropriate for chess programming?

Discussion of chess software programming and technical issues.

Moderator: Ras

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Is 8/16 bit computing inappropriate for chess programmin

Post by sje »

hgm wrote:
sje wrote:Speeds are from 8 MHz to 32 MHz and the architecture runs most instructions in a single clock cycle. RAM is somewhat limited, but EEPROM runs up to 256 KB.

...

Now consider the possibility of using 4,096 of these microcontrollers. That's one controller for each pair of squares, so there's a controller for each possible move (promotions are a special case). With some creative wiring and coding, one could build a HiTech clone of sorts.
If the clock speed is only 32MHz, why bother? An Intel core, doing 4 instructions per clock at 3GHz, is 400 times faster. So even with 4096 of these things, you can only do the equivalent of 10 cores. If you would not have any communication overhead, that is. IMO it would already be extremely optimistic to suppose you could do the work of 4 cores.

So just buy an off the shelf Core 2 Quad...
The 32 MHz speeds are conservative; some of these parts run at 80 MHz or better.

The memory is effectively zero wait state with nearly every instruction taking only a single clock cycle. Compare this with a typical desktop CPU that spends maybe a third of its time sitting on its ass waiting for cache misses to be satisfied.
User avatar
hgm
Posts: 28353
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Is 8/16 bit computing inappropriate for chess programmin

Post by hgm »

sje wrote:The memory is effectively zero wait state with nearly every instruction taking only a single clock cycle. Compare this with a typical desktop CPU that spends maybe a third of its time sitting on its ass waiting for cache misses to be satisfied.
This is a pessimistic estimate, depending on the design of your program. When you don't hash QS nodes (like Bob does) it is very questionable if there would be much waiting for memory at all. If you want your 4096-CPU cluster to have a shared has table, you will have similar problems with the meory bandwith of the RAM holding that table.

Especially on Nehalem, where every core will have its own private L2, and there is a big shared L3 cache where you could put a small hash table dedicated to QS nodes, I think you can make this problem go away for a large part. And if you start designing, building and testing your cluster now, it won't be up and running before you can buy off-the-shelf 8-core Nehalems.

It is not that I am against hardware development (I had lots of fun with that in the eighties myself). But nowadays, it is almost impossible to compete with the main-stream momnetum of the industry. :cry: