We also have just become comfortable enough with libego
to be thinking about how we intended to add the go domain
knowledge for heavier playouts.
Cheers,
David
On 17, Jun 2007, at 3:15 PM, George Dahl wrote:
Posting that code would be really helpful! I too was thinking about
modifying libeg
Posting that code would be really helpful! I too was thinking about
modifying libego's move choosing algorithms. But I haven't gotten
anywhere yet since I have been working on a proof of concept
experiment for what I will be planning to do later.
- George
On 6/17/07, Darren Cook <[EMAIL PROTEC
On Sun, Jun 17, 2007 at 10:06:42PM +0900, Darren Cook wrote:
> I've been refactoring the libego playouts to allow me to easily plug in
> different move choosing algorithms, and choose between them at run-time.
> I was willing to accept a slight slowdown, but ironically got a 5%
> speed-up (on rando
> libego is a very optimised library. indeed, very hard
> to change. If it fits your needs, go for it. Its
> simply the best you can do.
>
> BUT, If you want to try different MCGO approachs with
> libego, I'm sure it will be far more hard to change
> than using slowish java.
I've been refactorin
Its like small AI we all just want a box we can strap on our head so we
don't have to think :)
Common consensus from dual language people Java has as many implementation
issues as C, even though they obscured by a cloud of proselytizing (or
prophylactic). But, all things being equal there is no
If you want compare pure efficiency (without taking
into account development costs, including maintenace
costs, clarity of code, etc.) C will win. period.
Learning curve for the java language is quite small.
(like pascal, thats why they used to use pascal as an
introductory language. Nowadays it
> Also I've found:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
> Strict 1/2 C++ speed.
more surprising to me, i suppose, is that C is apparently more expressive --
the size of the code is smaller for the C implementations than for java ones.
that's just pure comedy t
> Also I've found:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
> Strict 1/2 C++ speed.
not to mention 10x the memory usage of C.
s.
We won't tell. Get more on shows you hate
Stunning data.
I suggest list members to look at this papers.
Also I've found:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Strict 1/2 C++ speed.
--- Peter Drake <[EMAIL PROTECTED]> escribió:
> The JIT compiler can optimize away a lot of these
> things.
>
> For those
libego is a very optimised library. indeed, very hard
to change. If it fits your needs, go for it. Its
simply the best you can do.
BUT, If you want to try different MCGO approachs with
libego, I'm sure it will be far more hard to change
than using slowish java.
If you want to compare it with Go
"Robin Kramer" <[EMAIL PROTECTED]> writes:
> So if there was any language which allows a programmer to port their
> code to be compileable and executable on a wide variety of systems
> it is C.
Hey, are C and Java are all you guys know about?
What about Ada? I'd say it's much easier to write por
2007/6/16, steve uurtamo <[EMAIL PROTECTED]>:
on the other hand, there are places and times where
a little assembly can go a very, very long way. i seem
to recall (although i'm probably misremembering this)
that if you need to copy more than a page worth of data
on a pentium, directly using asse
a person can also (at the assembly level) do very
tricky things via repurposing instructions to perform
tasks they were perhaps not originally intended to
perform. also, scheduling a pipeline by hand can
really lead to some clever and creative ideas that
no compiler would ever find.
very painful
On Fri, 2007-06-15 at 21:09 -0700, Brian Slesinsky wrote:
> On 6/15/07, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> > These arguments are based on the assumption that the human can't do as
> > well as the computer for certain tasks. A custom designed memory
> > manager by a person who knows what h
On 6/15/07, Don Dailey <[EMAIL PROTECTED]> wrote:
These arguments are based on the assumption that the human can't do as
well as the computer for certain tasks. A custom designed memory
manager by a person who knows what he is doing will be faster than an
automatic generalized algorithm and as
Oh, that's because I'm a lousy programmer. :-)
Peter Drake
http://www.lclark.edu/~drake/
On Jun 15, 2007, at 4:03 PM, Darren Cook wrote:
Plenty of data can be mustered for either side of this question,
but the
assumption that Java is necessarily, inherently slower than C/C++ is
outdated.
> Plenty of data can be mustered for either side of this question, but the
> assumption that Java is necessarily, inherently slower than C/C++ is
> outdated.
So why is libego many times faster (at doing random playouts) than orego
on the same hardware? :-). I got the impression from you that you d
Gah! no destructor gotta love that one if you are trying to write threaded
API's.
OK my proof goes like this. Not all operating systems are the same, and you
can access things in the operating system using Java, breaking
encapsulation, and making that code non-independent.
Furthermore, Java has
> What are the specs of the actual cores? Shared
> memory or does each core have it's own?
Its a SMP machine. (share memory with same access
speed for every core)
> There are more things to take into consideration
> than just cores. I've
> seen several posts like this in the past, and it
> ma
Java is the platform.
so far, so good, Java is THE OS abstraction layer.
We have to admit the Java people have done it well.
You can't get anything better in platform
independient. A lot of interpreted languages (Python,
Perl, etc.) don't have platform 100% independient
libraries... Some libraries
I'm 100% with you.
[[SET MODE SELLING MY OPEN SOURCE PROJECT ON]]
But, actually I have found that Java is fast enough in
MCGO simulations. 100k simulations can be achieved in
less than half minute.
In the other side, writing and testing new ideas and
algorithms in Java is far more faster than C
I think Java approaches the speed of C only in a few benchmarks. I
think if you had a competition by super-experts in any language to write
a very specific program, you would find that the Java program couldn't
approach the C program in speed.
For instance I would like someone to take Lukasz L
On 6/15/07, Don Dailey <[EMAIL PROTECTED]> wrote:
I think D keeps improving. The gcc version is slower anyway, so I
haven't bothered with it but my understanding is that they have made a
lot of optimizations since we last discussed the performance of D on
this group. Of course I haven't tested
I think D keeps improving. The gcc version is slower anyway, so I
haven't bothered with it but my understanding is that they have made a
lot of optimizations since we last discussed the performance of D on
this group. Of course I haven't tested it out in a while.
I would use D exclusively for pe
On Fri, 2007-06-15 at 15:35 -0400, Don Dailey wrote:
> These arguments are based on the assumption that the human can't do as
> well as the computer for certain tasks. A custom designed memory
> manager by a person who knows what he is doing will be faster than an
> automatic generalized algorith
On Fri, 2007-06-15 at 14:45 -0400, Jason House wrote:
> On 6/15/07, Phil G <[EMAIL PROTECTED]> wrote:
> JIT didn't solve everything - the managed memory management in
> Java (and C#) has overheard which JIT can not always optimized
> away, for example.
>
>
> The D program
On 6/15/07, Phil G <[EMAIL PROTECTED]> wrote:
JIT didn't solve everything - the managed memory management in Java (and
C#) has overheard which JIT can not always optimized away, for example.
The D programming language website argues in favor of garbage collection...
Even claiming that it cou
Regarding the garbage collector, Azul Systems' big selling point is that their
hardware-assisted
garbage collection consumes vastly less time and is much more predictable.
- Original Message
From: Álvaro Begué <[EMAIL PROTECTED]>
> Then you have the garbage collector, which will run
> Terry McIntyre <[EMAIL PROTECTED]>
> They mean to govern well; but they mean to govern. They promise to be kind
> masters; but they mean to be masters. -- Daniel Webster
>
>
> - Original Message ----
> From: Joshua Shriver <[EMAIL PROTECTED]>
> To: computer-go
gt; s.
>
>
> - Original Message
> From: terry mcintyre <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Friday, June 15, 2007 1:17:11 PM
> Subject: Re: [computer-go] Java hounds salivate over this:
>
> The Vega chip is custom-designed to run a Java Virtual Machine.
java really is as fast as C now.
>
> s.
>
>
> - Original Message
> From: terry mcintyre <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Friday, June 15, 2007 1:17:11 PM
> Subject: Re: [computer-go] Java hounds salivate over this:
>
> The Vega chip is custom-design
hat point.
-Josh
On 6/15/07, steve uurtamo <[EMAIL PROTECTED]> wrote:
>
> hey, you guys are right, java really is as fast as C now.
>
> s.
>
>
> - Original Message
> From: terry mcintyre <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Friday, June 1
OO is slower than non-OO. it's just easier for a lot
of people to write.
s.
- Original Message
From: Joshua Shriver <[EMAIL PROTECTED]>
To: computer-go
Sent: Friday, June 15, 2007 1:27:28 PM
Subject: Re: [computer-go] Java hounds salivate over this:
I'm not a java
mo <[EMAIL PROTECTED]> wrote:
hey, you guys are right, java really is as fast as C now.
s.
- Original Message
From: terry mcintyre <[EMAIL PROTECTED]>
To: computer-go
Sent: Friday, June 15, 2007 1:17:11 PM
Subject: Re: [computer-go] Java hounds salivate over this:
T
hey, you guys are right, java really is as fast as C now.
s.
- Original Message
From: terry mcintyre <[EMAIL PROTECTED]>
To: computer-go
Sent: Friday, June 15, 2007 1:17:11 PM
Subject: Re: [computer-go] Java hounds salivate over this:
The Vega chip is custom-designed to run
t they mean to be masters. -- Daniel Webster
- Original Message
From: Joshua Shriver <[EMAIL PROTECTED]>
To: computer-go
Sent: Friday, June 15, 2007 10:03:46 AM
Subject: Re: [computer-go] Java hounds salivate over this:
Interesting machine, but something about it seems odd. First
Interesting machine, but something about it seems odd. First it says
it's tuned for Java. Does that mean you can't use non-java on it? Run
Linux? Or is it a glorified cluster of chips like the old hardware
chips Sun made a decade ago for their defunct Java Station?
What are the specs of the actua
Wow, 48-cores in a second-generation chip. The future is not far now.
On 6/15/07, terry mcintyre <[EMAIL PROTECTED]> wrote:
Azul Systems has released a "compute appliance" with 768 cores and 768
gigabytes of RAM,
happily driving your Java applications faster than ever before:
http://www.azul
38 matches
Mail list logo
