Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Suturb - Bob

Author: Robert Hyatt

Date: 20:15:22 01/24/03

Go up one level in this thread


On January 24, 2003 at 17:40:27, Keith Evans wrote:

>On January 24, 2003 at 12:22:53, Robert Hyatt wrote:
>
>>On January 24, 2003 at 12:13:35, Jeremiah Penery wrote:
>>
>>>On January 24, 2003 at 10:25:44, Robert Hyatt wrote:
>>>
>>>>On January 24, 2003 at 02:15:34, Jeremiah Penery wrote:
>>>>
>>>>>On January 24, 2003 at 00:56:41, Robert Hyatt wrote:
>>>>>
>>>>>>On January 23, 2003 at 23:20:33, Jeremiah Penery wrote:
>>>>>>
>>>>>>>On January 23, 2003 at 20:59:04, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>means that some sort of PCI bus interface is also needed.  The PCI bus is
>>>>>>>>changing regularly as well, as it its clock frequency.
>>>>>>>
>>>>>>>??
>>>>>>>The basic PCI bus has not changed in at least 10 years, so I'm not sure what
>>>>>>>you're talking about here.
>>>>>>
>>>>>>Mine has.  64 bit pci.  32bit pci.  which speed?  Etc.
>>>>>>
>>>>>>You have to make a card that will plug into the thing.  10 years ago it would
>>>>>>have probably been an EISA card.  3 years ago 32 bit PCI.  Now 64bit pci.  And
>>>>>>so forth...
>>>>>
>>>>>About 10 years ago, I had a 486 something or other.  It had PCI slots which were
>>>>>identical to the PCI slots in my computer today (32 bits/33MHz).  Sure, you can
>>>>>get 64 bit/66MHz slots, but 32b/33MHz slots are still most plentiful, as they
>>>>>have been for years.  Really, you can only find the 64bit/66MHz slots on some
>>>>>server-type motherboards, and often they still have some of the old slots as
>>>>>well.  Further, I think (but I'm not totally sure) that 32-bit cards work in
>>>>>64-bit slots.
>>>>
>>>>
>>>>First, they don't work.  And second, the point is about getting better (faster)
>>>>as time
>>>>passes.  Using old PCI slots gives you a specific bottleneck to talk to a
>>>>chess-processor
>>>>that sits on the PCI bus.   If you stick at the stock 32 bit 33 mhz bus speed,
>>>>then the faster
>>>>you make the microprocessor itself, the less searching you can do on the chess
>>>>processor to
>>>>keep a speed balance (same issue exactly was found in deep blue).
>>>>
>>>>The point is that if you want to go faster you have to speed up the bottleneck
>>>>as well or
>>>>you don't advance.
>>>
>>>You seemed to originally imply that changing the PCI interface of the card
>>>(several times) was mandatory, due to changing standard.  My point was that they
>>>could have kept the same interface if they chose to, because the standard hasn't
>>>really changed.  If they absolutely want the best performance, they can use one
>>>of the bigger/faster PCI variants, but it is their choice to do so.  Even so,
>>>they can't have changed it more than once or twice in its lifetime.
>>
>>I used the term PCI pretty generically.  If someone had done an FPGA board 15
>>years ago, they would have had to re-do it 10 years ago to go faster.  They
>>would need
>>to re-do it again today to move to a 64 bit slot.  My point was, the "bus" is a
>>bad place
>>to "sit".  Because it is a bottleneck, and just because you can clock the fpga
>>faster, you
>>still have a data transfer rate problem with the raw bus itself, and to move the
>>speed up,
>>you have to move to the most recent bus, which probably won't be PCI much
>>longer.
>>
>
>If you designed such a beast well, then the bus interface would be the least of
>your worries.
>
>Some reasons I can think of that custom chess hardware isn't seen much:
>
>1. It requires a lot of money for hardware. If you really want to be competitive
>then you'll need the latest FPGAs. Right now at work we're using a nice $6000
>FPGA to prototype an ASIC. If I were going to to a hardware chess project then I
>would want to use something of equal or greater capability - and I would
>probably want N of them.

N of them on a PC might be problematic.  The PCI bus isn't that great.  Also
there has to be a balance between the speed of the actual CPU being used and
the speed of the chess processors, factoring in the communication bandwidth.
If one part goes faster, then the other part will have to go slower to avoid
waiting or overrun.

Hsu's thesis makes some interesting reading to understand this issue...

>
>I'm assuming that it would take such hardware to motivate somebody to do such a
>project, otherwise why not just write a pure software engine? What's the point
>of a weak hardware based engine? The whole point of doing it would be to
>dominate the field. (Isn't this what drove Hsu?)

Correct, and yes...


>
>2. It requires a lot of money for development tools. We're talking tens of
>thousands of dollars.



Maybe or maybe not.  Someone working at a university, for example, could get
access to the tools for nothing or next to nothing.  And even making ASICs
is not terrible for university people with project MOSIS and the like.  This
was what led to deep thought, and eventually deep blue although IBM couldn't
use the MOSIS stuff of course.



>
>3. There aren't many hardware engineers that have written chess engines, or are
>interested in doing it. (I think that anybody building a hardware chess engine
>would first write a pure software engine to learn the state of the art
>techniques. And then to experiment.)

It really is not that difficult.  I designed a bunch of hardware back in the
70's and even in the early 80's, and I'm not an EE.  So it is doable.  Whether
the reward justifies the cost is an issue.


Of course, ASIC stuff is not nearly as easy to "evolve" as a hardware
solution also.  In the case of Brutus, 3M nodes per second sounds pretty
good today, but there are already general purpose hardware solutions that
are faster.  30M would be quite an advantage...


>
>[4. It's a huge opportunity cost - you could use these same skills/tools to earn
>a lot doing ASIC work. If you actually own and pay maintenance on your tools,
>then this is an issue.]
>
>Regards,
>Keith




This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.