[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [computer-go] Computer Go hardware



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/