Hello Don,
Thank you for the advises but I run 32 bit Fedore Core 5 on
[EMAIL PROTECTED]
Don Dailey: <[EMAIL PROTECTED]>:
>On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote:
>> Hello Sylvain and Don,
>>
>> I prefer 32-bit OS as Core series is not better for 64 bit and try not
>> nocona but
On 22/02/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote:
Hello,
2007/2/22, Martin Møller Pedersen <[EMAIL PROTECTED]>:
> > The intel compiler is much better I understand and you can get it for
> > linux too, but I'm too cheap to do this. GCC will eventually improve
> > for core 2 duo, hopefully I
Ok, so I will probably give it a chance if it's free. I'll let you
know
if anything interesting happens.
I really prefer to stay with GCC but if there is a big difference I will
use intel until GCC starts optimizing for core 2, assuming it's usable.
I'm not sure when this will happen, it se
Hello,
2007/2/22, Martin Møller Pedersen <[EMAIL PROTECTED]>:
> The intel compiler is much better I understand and you can get it for
> linux too, but I'm too cheap to do this. GCC will eventually improve
> for core 2 duo, hopefully I won't have to wait too long.
It is what I have heard fo
The intel compiler is much better I understand and you can get it for
linux too, but I'm too cheap to do this. GCC will eventually improve
for core 2 duo, hopefully I won't have to wait too long.
And it is free of cost for non-commerciel use.
http://www.intel.com/cd/software/products/asmo-na/e
On Fri, 2007-02-23 at 03:54 +0900, Hideki Kato wrote:
> Hello Sylvain and Don,
>
> I prefer 32-bit OS as Core series is not better for 64 bit and try not
> nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9
> for E6700) is very easy without core volt doping.
With 64 bits as
Hello Sylvain and Don,
I prefer 32-bit OS as Core series is not better for 64 bit and try not
nocona but pentium-m. For overclocking, usually 3 GHz (333 MHz FSB x 9
for E6700) is very easy without core volt doping.
-gg (Hideki)
Don Dailey: <[EMAIL PROTECTED]>:
>On Thu, 2007-02-22 at 18:50 +01
On Thu, 2007-02-22 at 18:50 +0100, Sylvain Gelly wrote:
> > I'm very much interested in core 2 duo performance and would
> appreciate
> > hearing what others have experienced in this regard. I don't know
> what
> > OS you use, but here are my experiences so far with Linux:
>
> You seem to have e
I'm very much interested in core 2 duo performance and would appreciate
hearing what others have experienced in this regard. I don't know what
OS you use, but here are my experiences so far with Linux:
You seem to have exactly the same processor as I have access to. And I get
much better perfor
My Mac seems to have a relatively old version of gcc:
$ g++ -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5367.obj~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-tr
On Thu, 2007-02-22 at 17:05 +0100, Sylvain Gelly wrote:
> > So, what should I be looking for in a
> > processor if I want to get the most out of my single threaded UCT
> > program?
> The best way is to find a friend with exactly the processor you want
> and try your program on it... The second best
Hi Richard,
I'm very much interested in core 2 duo performance and would appreciate
hearing what others have experienced in this regard. I don't know what
OS you use, but here are my experiences so far with Linux:
I'm a little disappointed with the speed of a single threaded
application
on my
So, what should I be looking for in a
processor if I want to get the most out of my single threaded UCT
program?
The best way is to find a friend with exactly the processor you want
and try your program on it... The second best is see benchmarks, and
find which benchmark is relevant to your progr
The hardware portion of this topic is very important, at least to me
since I'm in the market for a new laptop. :) The comment "today the
frequency means nothing" is my main concern and I worry even more if I
need to investigate all the other numbers associated with the CPU. I bet
the laptop ma
isn't that 4x worse than it should be?
s.
- Original Message
From: Łukasz Lew <[EMAIL PROTECTED]>
To: computer-go
Sent: Thursday, February 22, 2007 4:41:19 AM
Subject: Re: [computer-go] Library of Effective GO routines v 0.106
I do not understand it. Maybe someone does?
I&#
On 2/22/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote:
Hello,
> I do not understand it. Maybe someone does?
> I've made some tests on 2 core processors, and I have strange results.
> Some of 2 core processors got results exactly 2x times worse than they should.
> Why?
> I have no idea.
> But 2.8 G
A whole benchmark fits in L1 cache.
But maybe somehow hyperthreading is involved.
I will investigate.
Thanks,
Łukasz
On 2/22/07, Nick Apperson <[EMAIL PROTECTED]> wrote:
if cache is your limiting factor that is usually shared. Also, if you are
using processors with hyperthreading, it is possi
The other thought (kind of silly) but just a pssing thought is that the
threads that are benchmarking are keeping a local copy of their count and
writing it back at the end (which is allowed) so you are actually getting
good performance, but you don't know it because the processors aren't
talking
if cache is your limiting factor that is usually shared. Also, if you are
using processors with hyperthreading, it is possible. Or if bus bandwidth
is your limiting factor... but if it is exactly 2x slower that is indeed
very odd. My money is on the fact that you have a bottleneck somewhere els
Hello,
I do not understand it. Maybe someone does?
I've made some tests on 2 core processors, and I have strange results.
Some of 2 core processors got results exactly 2x times worse than they should.
Why?
I have no idea.
But 2.8 Ghz 2 core works exactly like my 1.4 laptop.
Also version of g++ d
I do not understand it. Maybe someone does?
I've made some tests on 2 core processors, and I have strange results.
Some of 2 core processors got results exactly 2x times worse than they should.
Why?
I have no idea.
But 2.8 Ghz 2 core works exactly like my 1.4 laptop.
Also version of g++ does mat
netsky <[EMAIL PROTECTED]>
Date: Wed, 21 Feb 2007 15:13:13 +0100
Subject: Re: [computer-go] Library of Effective GO routines v 0.106
>
> On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote:
> >
> > If Black is the first player then why is he winning so little?
The only real change is to link against the Boost libraries I
installed using DarwinPorts. Here are the diffs:
-CFLAGS += -Wall #-static #-Wno-long-long -Wextra -Wno-variadic-macros
+CFLAGS += -Wall -I/opt/local/include -L/opt/local/lib
It's a desktop and I don't see any options for power manag
It is because it is a random play during playouts.
I.e. komi about 1 is accurate.
Łukasz
On 2/21/07, Heikki Levanto <[EMAIL PROTECTED]> wrote:
On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote:
>
> If Black is the first player then why is he winning so little? If you
> are not us
On Wed, Feb 21, 2007 at 05:01:56PM +0300, Dmitry Kamenetsky wrote:
>
> If Black is the first player then why is he winning so little? If you
> are not using komi then Black should win more often then White. If you
> are using komi then the percentages should be more or less even, i.e.
> 50%-50%. A
If Black is the first player then why is he winning so little? If you are not
using komi then Black should win more often then White. If you are using komi
then the percentages should be more or less even, i.e. 50%-50%. Am I missing
something?
___
comp
On 2/21/07, Brian Slesinsky <[EMAIL PROTECTED]> wrote:
[resending; apologies if you get this twice.]
Hi,
Hi Brian,
This is my first post to the list, so I'll introduce myself: I'm a
software developer and just getting started with playing Go. I read
the article in the Economist and thoug
[resending; apologies if you get this twice.]
Hi,
This is my first post to the list, so I'll introduce myself: I'm a
software developer and just getting started with playing Go. I read
the article in the Economist and thought that the work on Monte-Carlo
based Go programs sounds promising. I
Hi!
New version, good news.
- Simple ko implemented in board_t. If I knew it was so simple I would
do it much earlier ;)
- UCT implemented. A very simple version, but as bazaar methodology
says "release early, release often"
Simple_playout performance is now 85 kpps on 2.2 GHz.
Since some time
29 matches
Mail list logo
