A note: we're working on converting Orego back from C++ to Java, and
we're getting 5,000 (totally random at this point) simulated games per
second. We'll probably continue in this direction.
Peter Drake
Assistant Professor of Computer Science
Lewis Clark College
Agner Fog, in his well known optimization guide, claims that Digital
Mars compilers are rather weak optimizers. But the features of D
language are indeed admirable.
I would be grateful to see direct performance comparison on MC Go program
(or on anything else)
http://www.agner.org/
BTW
Does
Would you like to share some experiences on tunning up
Java code ?
Yesterday I left my machine profilling the code.
(takes ages with TPTP).
I didn't research too much the results, but as far I
could see, creating objects is almost FORBIDDEN.
The clone method on game class which is used for
I've debating trying to switch over to D with my project, but have not
yet done it. I use http://www.boost.org for a number of missing
features of C++ and worry about simply not having such things available
if I did switch over. I also worry that using D would scare away
developers.
In the Orego paper the problem of selecting a move when the board is filled
with stones is mentioned. Orego uses a sort of double-hashing scheme.
But isn't it trivial to keep a list of empty intersections?
Before the MC-run is started, one builds up this list. If a stone is placed
now on the
I would forgive weak optimization if the actual performance difference
was small and it wasn't painful to get close, like it is in java.
But from what I've read, you can interface C code directly, no special
gymnastics. In fact any external libraries are supposed to work as is,
just link them
It's not clear whether this is faster. Determining that a move is
illegal because the point is occupied is very fast; determining that
a move IS legal (i.e., not a suicide or ko violation) is the slow
part, and I avoid that by taking the first legal move I find. (Of
course, once all moves
The three most important things seem to be:
1) Run java in -server mode. This appears to double speed for no effort.
2) As you say, avoid creating objects. For example, instead of
creating a new array each time a method is invoked, make the array a
field and just clear it out when you need
Similarly,
instead of
Foo x = y.clone();
do something like
x.copyDataFrom(y);
where of course you have to write copyDataFrom().
in C you can do something like:
(toward the beginning of your code)
CovZ= (double *)calloc(p*p*K,sizeof(double));
(and then inside some kind
I've noticed that Orego has done very poorly in the last couple of
competitions. This is partly due to the improvements in others'
programs, but I think the fact that Orego currently doesn't have a
transposition table is crippling. Since I'm rewriting this stuff in
Java, I'm thinking about
I'd be a bit more careful about the comparison with alpha-beta in
section 2.3. I believe that iterative deepening of alpha-beta is very
common. It can be argued that when iterative deepening is used, an
early termination isn't very detrimental. I've seen people get
completely turned off to a
On 4-dec-06, at 15:23, Don Dailey wrote:
But it seems like more of a travesty in Java.
Well, this may be subjective. What may seem like travesty to one may
appear completely normal to someone else.
I'm curious though. If you have the time, could you point out in the
code in my public
- Original Message -
From: House, Jason J. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org
Sent: Monday, December 04, 2006 8:10 PM
Subject: RE: [computer-go] Technical Report on MoGo
I'd be a bit more careful about the comparison with alpha-beta in
Guys, keep your eyes on the prize. If your only problem
is that you need to double your speed, all you have to do
is wait 1.5 years.
All this talk of optimizing speed by tweaking language xx to be
more like assembly language (or C) is almost completely a waste
of time.
Likewise, algoritmic
On Mon, 2006-12-04 at 12:15 -0800, Dave Dyer wrote:
Guys, keep your eyes on the prize. If your only problem
is that you need to double your speed, all you have to do
is wait 1.5 years.
All this talk of optimizing speed by tweaking language xx to be
more like assembly language (or C) is
Don,
I disagree rather strongly with some of your statements.
On 4-dec-06, at 18:35, Don Dailey wrote:
This isn't a Java issue, it's most if not all computer languages - if
you really go all out to optimize your code for performance, you will
sacrifice readability, clarity, etc.
In
I don't see the
logic why you
can't do in Java something that performance gurus do
in C. Just
because it's Java? Because it makes sense?
the garbage collector might make you a little
bit more afraid of churning through objects,
and the difference between a new() and a malloc()
is
17 matches
Mail list logo
