RE: [computer-go] Pattern Matcher

[Vincent Diepeveen <diep@xxxxxxxxx>]

Mark, if you can't program very well yourself, lacking cpu understanding,
you must not claim that JAVA is nearly as fast as C/C++.

Also claiming that for a go program it's easier to program in JAVA is of
course not true. C++ and JAVA are very similar object oriented programming
languages.

Real high level things you cannot use in neither languages because those
constructions are too slow.

Or are you nonstop moving objects in your JAVA code?

Now *there* you could optimize something then :)

I'm not going to convince anybody that C is faster than assembly language
either. Assembly is just *so much* faster. I'm not going to claim that my
code 'just slower' 30% than assembly.

It's not. In assembly you can win *way more* than 30%.

Please don't allow the same nonsense in this mailing list of C versus JAVA,
or C versus C#.

I can assure you, in a few years when C# is more grown up, many will use it.

Because you can easier build interfaces with it...

At 09:20 9-11-2004 -0200, Mark Boon wrote:
>> -----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/
>
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/