On Mon, 2006-12-04 at 19:30 -0200, Mark Boon wrote:
> The object pooling is the only thing I'd rather do without. But for
> speed that's not possible, unfortunately. However it hardly affects
> cleanliness or readability as there's not such a big difference
> between a constructor call and a
> 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 sig
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 princ
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)
On Mon, 2006-12-04 at 17:37 -0200, Mark Boon wrote:
>
> 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
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 opt
On 12/4/06, Peter Drake <[EMAIL PROTECTED]> wrote:
The three most important things seem to be:
1) Run java in -server mode. This appears to double speed for no effort
I understand this is largely the old optimize for processing or optimize for
interactivity trade off. It's almost as old as m
- Original Message -
From: "House, Jason J." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "computer-go"
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
section 2.3. I believ
I'll port the Java code to C#. I'm curious as to the performance comparison
between these languages. I'm getting fairly good at porting code between Java
and C++ to C#, so it would take too long.
- Original Message
From: Peter Drake <[EMAIL PROTECTED]>
To: computer-go
Sent: Sunday, Dec
- Original Message -
From: "Magnus Persson" <[EMAIL PROTECTED]>
To:
Sent: Monday, December 04, 2006 7:45 PM
Subject: Re: [computer-go] Proposed UCT / transposition tableimplementation
Quoting Peter Drake <[EMAIL PROTECTED]>:
I've noticed that Orego has done very poorly in the last
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 p
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 pap
Quoting Peter Drake <[EMAIL PROTECTED]>:
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 rewritin
> "avoiding object creation" in a object oriented
Only at inner cycles / loops.
Of course you have to create a lot of objects and
complex structures / object relationships.
But on inner cycles / loops, just modify pre-created
ones, do not create new ones. That is idea of my
posting.
Creating
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
On 12/4/06, Peter Drake <[EMAIL PROTECTED]> wrote:
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 le
> 3) Algorithmic improvements are always more important that
fine-tuning.
It depends on what you mean by algorithmic improvements. Do you mean
performance improvements or do you mean conceptually cleaner code?
Sometimes you get both, but other times you have to write difficult to
understand code
> 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 so
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 a
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 h
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 in.
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 boa
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.
-Origin
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
cre
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 any
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
http://www.lclark.edu/~drak
26 matches
Mail list logo
