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,
- 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 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
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 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
> 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
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
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
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
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
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
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
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
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
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
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...
s.
__
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
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
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
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
> 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
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
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
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
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
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
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/
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
> 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
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
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
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
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
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
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
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
]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: 28 November 2006 21:37
To: Computer Go
Subject: [computer-go] Making Java much faster
Everyone here has offered me all kinds of useful advice on speeding up
or otherwise improving Orego. In thanks, I offer a recent (to me)
discovery about how to
Everyone here has offered me all kinds of useful advice on speeding
up or otherwise improving Orego. In thanks, I offer a recent (to me)
discovery about how to make Java programs run much faster. Instead of
java MyProgram
do
java -server MyProgram
It's not entirely clear what the differenc
39 matches
Mail list logo