[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [computer-go] Computer Go hardware
That's why the smiley :)
I don't know anyone that's worked full time on computer go
for very long. Tuning the heuristics by hand is pretty tedious. It's too
bad that
no one has found a better way yet to make a strong program. I probably have
put in the
equivalent of about 3 full time years (about 6000 hours). It's about 5 to
10 hours a week,
about 8 months a year, for about 20 years.
I don't think it is possible to make a strong program by extracting millions
of patterns from
professional games and sorting through them automatically. Go is too
tactical, and the branching
factor is too high to avoid heuristics in move sorting. The tactics don't
appear in the game
records, so there is no source to automatically extract this information.
If you are off by factors of millions in the compute power to do a full
width search, then
a factor of 2 or factor of 10 speedup is worthless compared to tuning the
heuristics to
do better move ordering.
Regards,
David
> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Chris Fant
> Sent: Tuesday, October 19, 2004 7:44 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: RE: [computer-go] Computer Go hardware
>
>
> With all due respect, some of us haven't been working on Go
> full time for
> the past 15 years.
>
>
> >From: "David Fotland" <fotland@xxxxxxxxxxxxxxxxx>
> >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
> > > >C++ 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/
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for
> advice on how to
> get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
> _______________________________________________
> 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/