RE: [computer-go] Pattern Matcher

["Mark Boon" <tesuji@xxxxxxxxx>]

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Vincent
> Diepeveen
> Sent: Tuesday, November 09, 2004 2:52
> To: drd@xxxxxxxxxxxxxxxxx
> Cc: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: [computer-go] Pattern Matcher
>
>
> You claim JAVA is fast.
>
> I disprove it clearly as you again showed a memory trashing program.

What is it with you guys? You didn't disprove anyhing. You're just talking.

>
> In cilkchess you could get away with it by slowing down the program a
> factor 40 first. Not this time.
>
> It is not acceptible to use this childish programming as a 'proof' that
> JAVA is not that much slower than C.
>
> It's just about a factor 3 slower, not 30%.

How did the program run? Was the C version 3 times faster than Java or not?
Did you try it? I must admit I didn't try it myself, but then again I'm not
doubting the result Don claimed.

Goliath is what I consider a typical Go program. 90% (if not 99.9%) of the
execution is spent doing simple test-branch, integer oprations,
array-indexing and function-calls. I'm assuming chess programs are not so
different. I've spent a lot of time optimizing it when it was written in C,
without actually getting to the point of worrying about assembler all the
time. When this was translated to Java, it was first 2 times slower with the
first JITs 7 years ago. Soon after that the difference dwindled to 30%-50%.
Do you think Goliath was made by 'childish programming'? (Actually, I think
it was, but not for the reasons you think something is childish.) Are you
doubting the results I got?

Now where is *your* proof?

All you rant on about are assembler instructions that should be avoided, bla
bla. Maybe that is important in chess, but not in Go. If I had to worry
about what instructions the compiler generates I would still be fretting
over just the basic stuff in Go. No time for that, algorithms needed to be
discovered, code needed to be written. I regret not looking more at chess
algorithms, as it turned out I reinvented more of it than necessary. But
still it's all so trivial compared to the important stuff in Go. Yes, I
didn't know it was called 'null-move', but apparently I already used it in
Goliath 15 years ago. When did chess-programs start to use it?

Worrying about instructions? It would all change with the next generation of
CPUs, it's a waste of time. It works in chess because there speed is almost
the *only* important thing. So the only way to get that extra little bit is
to worry about CPU specific stuff. Not so in Go. You're talking about a poor
hashtable implementation, not important in Go. And some of your peers seem
to doubt it's all that important in chess even. If an instruction that gets
used by the compiler in a Go program is slow, I simply expect that compilers
and chip-designs will take care of it in their next generation.

Yes, optimization is important. But new ideas are more important. I doubt
*you* can write a faster ladder-routine in C than the Java one in the
library I published, without actually looking how it's done. Most likely it
will be 3 times SLOWER, if not more.

If all you care about is chess-programming, why are you here? We're
interested in your knowledge about chess programming, as long as there's any
relevance to Go. And I know a lot more effort has been put into
chess-programming than in Go, so hopefully there are bits there we can learn
from it. But stop treating us as a bunch of backward idiots. I don't treat
you as one, and I think some more respect would be appropriate.






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