Both do just in time compilation,
but the -server option uses more
optimisation tricks. Sometimes these
make a significant difference, sometimes not.
Without the JIT, it would be *very* much slower.
Best regards,
Simon Lucas
-Original Message-
From: [EMAIL PROTECTED]
[mail
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
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/
t/C# will create an arms race that benefits
all their users.
Jim
PS. It is somewhat difficult to talk about memory management between Java and
C++/C because their memory models are different.
- Original Message
From: Mark Boon <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday
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
get around to that during this holiday break.
Jim
- Original Message
From: Eduardo Sabbatella <[EMAIL PROTECTED]>
To: computer-go
Sent: Wednesday, November 29, 2006 11:26:02 AM
Subject: Re: [computer-go] Making Java much faster
I'm a full time worker. Before starting m
Please go back to Java! Part of your initial aims were to make good, well
commented code available to others. I was dismayed when you started to
transition to C++, which may be the right choice if you're working on your
own and happy to trade clarity / portability for speed, but really detracts
f
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
> Huh, why not use Pascal? It has speed of C and
> simplicity of Java :)
heck, you could use perl. plenty of packages
available (it can even be made multithreaded!),
shared memory packages, etc.
i mean, if speed isn't your top concern...
s.
__
C++ should be good. But take it with double care. I
would code a lot of unit tests. If test driven
development is followed, I suppose it will be a good
piece of software, and, at the end of the day, a pro
product.
Test Driven Development, regression tests, profilling,
code coverage, I would apply
Huh, why not use Pascal? It has speed of C and
simplicity of Java :)
heck, you could use perl. plenty of packages
available (it can even be made multithreaded!),
shared memory packages, etc.
i mean, if speed isn't your top concern...
i think speed is one of most important things beacuse
Wodzu,
There are roughly two types of approaches to bettering the skill of
computer go solutions; incremental and breakthrough. I think for
incremental solutions, ones where lots of work results in small shifts
in better go playing performance, you are correct. Any optimizations
around exec
Hi Jim,
I feel similarly to you.
I have to take exception to what someone posted earlier - Java keeps
getting presented as some kind of high level language than enables a
natural expression of ideas. This is total garbage. Java is a low
level language and very much a C dialect. I don't under
I believe that MC will be the only way to write a GO program in the
near future leaving the other stuff in the dust (like Mogo has with 9x9
Monte Carlo Go.)This happened in computer chess several times,
someone came up with some breakthrough idea, proved it with actual
results and everyone
ww.jeffrey-greenberg.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Wednesday, November 29, 2006 9:01 AM
To: computer-go
Subject: Re: [computer-go] Making Java much faster
This is something we hope to do once we have Orego mul
On Thu, 2006-11-30 at 21:26 +0100, Chrilly wrote:
> >
> > I believe that MC will be the only way to write a GO program in the
> > near future leaving the other stuff in the dust (like Mogo has with 9x9
> > Monte Carlo Go.)This happened in computer chess several times,
> > someone came up with
I have been *so* tempted to either ignore this thread or rename it ...
On 30, Nov 2006, at 10:36 AM, Wodzu wrote:
i think speed is one of most important things beacuse it affects
strength of the program ;) (if the time for move is restricted)
anyway, chosing a proper (fastest) algorithm has cr
tive type?
Jeffrey Greenberg
http://www.inventivity.com
http://www.jeffrey-greenberg.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Wednesday, November 29, 2006 9:01 AM
To: computer-go
Subject: Re: [computer-go] Making Java much faster
This
Perhaps your comment is related to something i write
before.
I was not talking about the expressiveness of java
language. In that sense, Ocaml, Lisp, SmallTalk are
far, far away from Java.
Java is a C (almost C++) with garbage collection,
bound checking and variable initialisation. (its a lot
mor
> Also, my data shows that if I doubled the time
> allowed for playing,
> thus "using" the time gained from faster execution
> for doing deeper
> lookahead, the results did not improve, but actually
> got worse.
Sorry for not adding nothing to usefull to the thread.
But I found this comment
On 30, Nov 2006, at 3:46 PM, Eduardo Sabbatella wrote:
David Doshay wrote:
Also, my data shows that if I doubled the time
allowed for playing,
thus "using" the time gained from faster execution
for doing deeper
lookahead, the results did not improve, but actually
got worse.
Sorry for not add
On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
> This is not my experience at all.
>
> SlugGo was first written by a graduate student with data structures
> that made sense to them, but not to me. I rewrote it to use
> completely different data structures but with exactly the same
>
On 30, Nov 2006, at 4:47 PM, Unknown wrote:
On Thu, 2006-11-30 at 14:44 -0800, David Doshay wrote:
Also, my data shows that if I doubled the time allowed for playing,
thus "using" the time gained from faster execution for doing deeper
lookahead, the results did not improve, but actually got wo
- Original Message -
From: "David Doshay" <[EMAIL PROTECTED]>
To: "computer-go"
Sent: Thursday, November 30, 2006 11:44 PM
Subject: Re: [computer-go] Making Java much faster
I have been *so* tempted to either ignore this thread or rename it ...
On 30, No
On 1, Dec 2006, at 6:15 AM, Wodzu wrote:
- Original Message - From: "David Doshay" <[EMAIL PROTECTED]>
Also, my data shows that if I doubled the time allowed for
playing, thus
"using" the time gained from faster execution for doing deeper
lookahead,
the results did not improve,
38 matches
Mail list logo
