Re: [computer-go] Computer Go hardware

["Frank de Groot" <frank@xxxxxxxxxxxxx>]

> It becomes apparent that today's computer playing level is pretty much
> limited by the computing power of the PC.


I strongly disagree.
When I started working on my Go program a few years ago, I first did some
research of the "competition" and found that none of the best Go programs,
or the commercial Go programs, scale their playing strength reasonably well
with faster computers or longer thinking time.

After doing a lot of literature research, I came to the conclusion that
there is enormous potential for improving every aspect of current Go
programs.

Some examples:

-It appears that nobody uses the 2- to 4-fold speedup that the 64-bitness of
current CPU registers can afford in certain cases.

-It appears that nobody uses pattern-recognition systems with pattern
libraries of tens of millions of patterns that can match all those patterns
to any 19x19 position in a tenth or a hundreth of a millisecond.

-It appears that nobody has yet found a good pruning strategy.

Of course the virtue of the above can and will be debated and challenged,
but of course this is just MHO.

> Anyone who disagree with the conclusion
> does not yet have a clear picture of the situation.

You would have been correct if the current state-of-the art in Go software
would have been perfect. If it would have been un-improvable. On the
contrary, the state of the art in Go software is very immature. We are just
starting to get interesting ideas and we are just about to start
implementing some of them.


> Yes, today's program may
> used only 50 to 80% of the computing power of the PC. But definitely not
far
> bellow that level. Here the case of a magic mathametical formula is
excluded.


This is a nonsensical statement. When a Go program is running, it is using
approx. 100% of the "computing power". Your statement has only one possible
interpretation: "Current Go playing algorithms are at 50% to 80% of their
theoretical maximum efficiency". Which is so patently false that I would say
that anyone who disagrees with me on this does not yet have a clear picture
of the situation :)



> One of the approaches to increase the computing power is to use paralel
> computers (supercomputers). Some new results have been reported from this
>approach.


Yes but those results are indeed useless.
When you throw enough extra processing power at an existing or slightly
modified algorithm, of course you can get a few stones extra strength.
As results, they only are useful to demonstrate that some of the current
algorithms scale a certain way. The results do not give hope for a strong Go
program in the near future.


> The second approach is to use FPGAs. At present level of interest and
> maturity of the computer Go ASICs seems out of the question. The next best
thing is > to use the FPGAs. FPGA suffers some difficulties. First, the core
frequency of
> today's FPGA is about 500 - 600 MHz at the best which is 6 times lower
than
> the speed of the available CPU in the PC.


Yes, you can be happy when your Go-thingy runs at 120 MHz.
I sold my FPGA development kit after I found it to be a bad idea in terms of
evolving better and better algorithmic approaches to Go.

By the time you have put your algorithm on a FPGA, you have already found a
better algorithm. Of course when you are of the mindset that all the best
algorithms have already been found, you will get stuck at this point :)


> It means a 6 fold increase in speed
> only makes it equivalent to a PC.

The big bottleneck of FPGA's is the bus bandwidth. The Chinese Pilchard
plugs into a DIMM slot but still I think FPGA's is overkill for the
sub-optimal algorithms of today.


> Thus, a big break through in speed is
> difficult from the FPGA. The second difficulty is the complexicity
involved. A
> designer not only need to write the Go program, he need to design the
computer at the same time. Even if the FPGA can handle the complexicity.


I was a beta-tester of Java-to-VHDL but the conversion looses speed compared
to hand-coded VHDL.


> solve the computer Go problem. Higher level concepts and functions must be
used
> to prune the search space. For example, a Go program uses a surprisingly
> large amount of memory during a search.

On the contrary.
The Go programs I have bought at least don't use much.
"large amount of memory" I would say is a few GB.
But I consider a few GB to be "totally standard" in a few years, for new
PC's.

This means I will design my Go program to use *much more* than just a few GB
if it can, because the computers of the future (the future that will be when
my Go program hits the market) will have indeed "much more than a few GB"
RAM.

The same with 64-bitness. Current CPU's are at least 64-bit so my Go program
uses 64-bit variables everywhere. But my Go program is DESIGNED from the
ground up to use 512-bit registers. Because we have 64-bit now (MMX and more
bits with SSE, SSE2), but the FUTURE will be 128, 256 and 512 bit.

So I say: If a current Go program is limited to using 1 GB RAM and 64-bit
registers it is severely limited for the hardware of tomorrow and in that
case it's the SOFTWARE that limits the performance.

Now, wake up and smell the coffee: There are no Go programs that are written
to use 64-bits everywhere it can make a difference (like in bitboards) and
there are no Go programs that grab all the GB in your PC when you run them.
Ergo, this is already proof (not evidence, proof) that the software is not
using 50-80% of the max. possible hardware. Q.E.D.


> (PCI-express won't help much.) To break this bottle neck one needs to
interface the
> FPGA device directly with the CPU. Unfortunately it's not realistically
> possible to accomplish this with the Intel or AMD processors. The reason
is that all
> these processors use a 800 MHz buss speed which is out of reach for
today's
> FPGAs. On the other hand the chipsets provided by Intel and AMD does not
have
> functions that efficiently interface a FPGA device.

Chinese Pilchard plugs into a DIMM slot. Needs modified Linux kernel.
Is YEARS old already. I had the articles for 1 year on my site even.


> that you have the backing of the IBM corporation. Now one can see the
advantage
> of programming in C/C++.


The only advantages are portability, availability of a lot of existing code
and speed of executable.

To actually build a very large and very complex software system with C++
(let alone C) is quite a challenge and in many cases destined to fail by
virtue of the exceptionally lousy design of the language, IMHO. I would not
recommend trying it without at least a decade of solid experience in C++.

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/