Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
To: "'computer-go'" <computer-go@xxxxxxxxxxxxxxxxx>
Subject: RE: [computer-go] Computer Go hardware
Date: Mon, 18 Oct 2004 19:17:39 -0700
I'd rather have a strong program that doesn't use all available memory and
CPU power
than a weak program that uses all available resources :)
David
> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Chris Fant
> Sent: Monday, October 18, 2004 5:18 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: [computer-go] Computer Go hardware
>
>
> Actually, when in learning mode, my program does grab all
> availible RAM.
> But I know you meant no publicly availible Go programs do this.
>
>
> >From: "Frank de Groot" <frank@xxxxxxxxxxxxxxxxx>
> >Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >To: "computer-go" <computer-go@xxxxxxxxxxxxxxxxx>
> >Subject: Re: [computer-go] Computer Go hardware
> >Date: Sun, 17 Oct 2004 12:06:42 +0200
> >
> >
> > > 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/
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/
_________________________________________________________________