To be more specific, "-server" tells java to spend more time on the
compilation. This is good if you compile a little bit of code and run it
over and over, but it makes programs seem sluggish at first and take a
long time to start up, which is why it isn't the default.
Also, the documentation says
You can also squeeze a little more runtime performance by increasing the
size of object nursery.
The commands would be:
java -XX:NewSize=256m -Xms512m -Xmx512m -server MyApp
The NewSize command alters the object nursery size - note that this is in
the addition to the heap size. So if you had 1
Other tricks for faster java include ensuring that, wherever possible, you
use the final, static and private keywords. This enables the compiler to
apply more compilation tricks in more places. Obviously there are places
where you sholdn't use these (think interfaces), but in the inner loop they
c
I am confused. In your paper you write "Orego is a Monte CarloGo programm
written in C++". Is Orego now in C++ or in Java or both?
The paper mentions the relative comparison of 2 versions. This is common
practice in the scientific literature, but it is a very poor choice if one
wants to meas
I have heard this many times - but it doesn't always apply. In fact I
have heard that IMPROVEMENTS always look better against your
twin-brother but if that were true, I would always want to test against
my twin since it makes improvements stand out. It's hard to measure
small improvements so thi
Le mercredi 29 novembre 2006 14:21, Don Dailey a écrit :
> I have heard this many times - but it doesn't always apply. In fact I
> have heard that IMPROVEMENTS always look better against your
> twin-brother but if that were true, I would always want to test against
> my twin since it makes improv
Yes, it is definitely possible to engineer an improvement that is
mostly effective against a specific opponent and may even hurt the play
in general.
The kind of in-transitivity I have seen the most is where you make a
change that helps a lot in self-testing but only a little or not at all
agains
In case of the Null-Move the improvement was not only in Nimzo-Nimzo games.
What is especially overestimated is the speed advantage. If e.g. 2 programms
have an identical evaluation function, but the other one calculates 2 Plies
more the slower twin has practically no chance. The faster one must
On 29-nov-06, at 08:43, Stuart A. Yeates wrote:
Other tricks for faster java include ensuring that, wherever
possible, you use the final, static and private keywords. This
enables the compiler to apply more compilation tricks in more places.
More and more I find that using 'final' or 'stat
> Games are additionally hard-real-time problems. E.g.
> in the Orego tests but
> versions got the same amount of nodes. For a
> realistic comparision one has
> to give both sides the same time and not the same
> node-budget.
What do you think about giving the same program
different player time
Orego version 3.03, described in the paper and available at the Orego
web site, is in C++.
However, we are finding C++ an exceedingly frustrating language to
work in. I won't go into the details here -- we don't need another
language war -- but suffice it to say that it seems like we're
s
This is something we hope to do once we have Orego multithreaded:
give each version the same amount of time, so the time costs of
adding a heuristic are automatically taken into account.
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
Mark,
It's true.
My interpretation of Sun's documents:
In the more recent versions of Java (1.4, 1.5, etc.), the runtime analysis in
the -server option of Sun's Hotspot JVM is able to do several different types
of optimization around "potentially final" and "mostly final" methods. The
most re
I'm a full time worker. Before starting my engine (a
couple of months ago) by 3rd or 4th try. I concluded
this:
It will be impossible for me to do anything in C, C++
because I will have to focus on not having memory
leaks, range errors, etc.
My engine nowadays is winning agains gnugo on lower
lev
On Nov 29, 2006, at 9:26 AM, Eduardo Sabbatella wrote:
I'm a full time worker. Before starting my engine (a
couple of months ago) by 3rd or 4th try. I concluded
this:
It will be impossible for me to do anything in C, C++
because I will have to focus on not having memory
leaks, range errors, etc
The thing about java is that it seems to be a big memory pig.
I can't have multiple java processes running without suddenly
getting a lot of memory thrashing.
If I do things in C, everything screams.I always figured
this is a problem with java that will be solved - but to this
day it hasn
However, we are finding C++ an exceedingly frustrating language to work
in. I won't go into the details here -- we don't need another language
war -- but suffice it to say that it seems like we're spending a lot of
time messing with details that aren't of interest for the research. Now
th
> C and Java are in my opinion almost the same
> languages. I think the error
> rate and nowadays also the speed is very close.
i might agree about the error rate, but speed
isn't even close, in my limited experience.
if you statically allocate all of your ram usage,
this *might* be closer to be
It's been my experience that the bigger the project, the less difference
it
makes if you use a high level language.
There are some awesome high level languages that are very good for quick
and
dirty programming tasks. But the advantage seems to go away as soon as
you have
a substantially larg
Eduardo,
I am finding the same thing, strongly favoring optimizing algorithms and not
code.
As to object creation, I do most of mine at once near the start and then rely
upon using pools and reference identity (== where it only compares references
and does NOT call .equal()). And once I am wo
20 matches
Mail list logo
