RE: [computer-go] Pattern Matcher

["Mark Boon" <tesuji@xxxxxxxxx>]

No, I must admit my ignorance, as I had never heard of it. A Google got me
this though:

Profile Guided Optimization for static languages provide
benefit #3 at the cost of not being transparent
(they require a multi-phase compilation process). Additionally,
PGO suffers from three main problems:
(1)Empirically, developers are unlikely to use PGO, except
when compiling benchmarks.
(2) When PGO is
used, the application is tuned to the behavior of the
training run. If the training run is not representative
of the end-user's usage patterns, the program may actually
be pessimized by the profile information. (3)
The profiling information is completely static, meaning
that the compiler cannot make use of phase behavior
in the program or adapt to changing usage patterns.

Seems to me not something I can care to get into for a Go program.

In your next mail you're all making nonsense assumptions about my program
that you know nothing about. I measured what I measured. What you think
about my programming skills is just for you, as it's also something you know
nothing about. So far it's all talk from your side, showing very little
respect.

Come on, where is your 3 times faster C compilation of John's example?

> -----Original Message-----
> From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Vincent
> Diepeveen
> Sent: Tuesday, November 09, 2004 11:55
> To: computer-go; computer-go
> Subject: RE: [computer-go] Pattern Matcher
>
>
> Mark, did you already try a PGO with your C code?
>
> 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/
>

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