RE: [computer-go] Using floating point sounds very strange to me

["Mark Boon" <tesujisoftware@xxxxxxxxx>]

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of chrilly
> Sent: Friday, January 07, 2005 7:47
> To: computer-go
> Subject: Re: [computer-go] Using floating point sounds very strange to
> me
>
>
> >
> >
> >On Thu, 6 Jan 2005, Vincent Diepeveen wrote:
> >
> >> You guys are making jokes i hope about using floating point in
> evaluation.
> >>
> >> Nothing as slow and non deterministic like floating point. Additional
> >> certain compilers will use all kind of tricks with floating
> point giving
> >> massive roundoff errors.
> >
> >Surely you must be joking that these problem are relevant for the move
> >valuation in GNU Go.
> >
> This is really a clash of culture. I do not know any chess programmer who
> uses floating point. It really shocked me that someone is doing evaluation
> this way. In Deep Blue the material-value of a pawn was set to 128. Hydra
> follows the Deep-Blue design, but I set immediatly the value to
> 64. In fact,
> I would set it nowadays to 32 but it is to cumbersome to do all
> the changes
> in the harware design. There is nothing which can be measured reasonable
> with a precision of 1/128 pawn units. On a processor it does not matter if
> the pawn-unit is 128 or 64, in hardware it does.
> I can therefore not imagine why one needs floating-point precision. The
> examples given like graphics are a total other story. If you do your own
> fixed point arithmetic the floating point representation easies your life,
> has better precision and is probably today indeed faster. Also the
> comparison to Vector Units for BLAS does not really fit. This
> works in BLAS,
> but not for game programming. There is also an integer vector unit on the
> x86. It is called MMX and SSE2. If you can do something in parallel, than
> use MMX.
>
> In a chess programm 3 things are importan: Speed, speed and speed. In a go
> programm things are obviously different.
> But if this is really the case, one can not explain SlugGo. SlugGo uses
> additional computing power in a rather primitive and inefficient way.
> Nevertheless it plays according the published results
> considerable stronger.
> If speed does not really count, than SlugGo should not play
> stronger, or if
> SlugGo plays stronger, Speed counts and one should not use - at
> least not on
> the x86 - floating point.
>
> Chrilly

Traditionally in Go, speed was of utmost importance too. But computing power
has increased faster than Go programmers could keep up with, so nowadays
focus on speed has become much less. However projects like SlugGo might yank
computer-Go back to focussing on speed.

Personally I don't see any reason to use floating-point calculations in a Go
program. But I think it's very much a personal preference. At some point I
heard that combining floating-point calculations with integer calculations
is faster than a purely integer or purely floating-point based calculations
because (x86) CPUs have multiple pipelines for both and one set is idle in
such cases. (Even though your CPU load will show 100%.) But as I've written
often before, I don't think it's worth it trying to optimize Go software so
closely to the hardware. The return in terms of speed increase doesn't
warrant the effort. Most likely you'll be able to speed it up by the same
amount, if not more, by focusing on smarter algorithms and you don't risk it
becoming obsolete with a change in CPU architecture.

I bet the floating-point calulations in GNU Go comprise only a small
percentage of its total time, so it seems futile to quible about the speed
of such calculations. Vincents myopic focus on performance details makes us
all laugh. It's probably a characteristic that makes him successfull in
chess programming and it definitely has its rewards in that area of
expertise, but it seems so futile in regards to Go.

But it doesn't mean we never pay attention to performance. We do. But we
focus on the big problems first. David Fotland is a hardware (chip?)
designer during the day and a Go programmer at night. He probably knows more
about CPU architectures than all of us combined, but still I don't think he
uses much of that particular knowledge to speed-up his Go program. I'd say
that's a telltale sign by itself.



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