René, please don't apologize.
I will start to feel embarassed...
I am very happy that you came out with a working implementation of the
ideas I explained, as I never really did it (I only had made some
preliminary implementation in order to evaluate the interest).
Arguments people give on this
I only showed the first line. There were many more. Gotta go to work though.
René van de Veerdonk wrote:
Micheal,
Is that all the output you get? Did you notice that the first line with
test-error changed ... the second number went from 31 to 32. We did
something! But not what I expected. B
No. The code is now:
__forceinline
unsigned int bitmap_t::lowest_index () const {
const __m128i comp = _mm_cmpeq_epi32 (_mm_setzero_si128 (), board);
unsigned long m = _mm_movemask_epi8 (comp) ^ 0x;
if (!_BitScanForward (&m, m)) return 127;
/* offending instruction */
//return 8*m
Debug build:
testing _BitScanForward (&m, 0): 0 842032512
testing _BitScanForward (&m, 1): 1 0
testing _BitScanForward (&m, 256): 1 8
testing _BitScanReverse (&m, 0): 0 840277132
testing _BitScanReverse (&m, 1): 1 0
testing _BitScanReverse (&m, 256): 1 8
Release build:
testing _BitScanForward (&m
Mark,
I would argue that 10x vs 5x is not a deal-breaker if bitmaps would support
your particular goals better. They do provide the advantage of automatically
providing you all the liberties of strings, for instance. Requests on how to
do that efficiently come by on this mailing list on a regular b
A couple of notes. Some of us on this computer-go forum are also Chess
programmers and many of write 64 bit chess programs. I am one of them but
I know there are others.
My 64 bit chess program runs almost 2X faster if I compile it to run on a 64
bit OS - in other words I'm using real 64 bit v
Zach,
I can't help the windowsiness, but thanks for taking a look already.
Popcounting I believe to be optimal for 32-bit only instructions, especially
since I would like to keep the intermediate byte-count to help speed up the
random pick function. There is a really neat trick to speed up the fin
That doesn't seem to have any effect on the results.
René van de Veerdonk wrote:
Hi Micheal,
Thanks for the test (Intel -> AMD, Windows XP -> Windows 7, x32 -> x64,
great, three birds with one stone!). So much for portability. But,
hooray for test-cases!
This may be related to the __lzcnt i
Hi Micheal,
Thanks for the test (Intel -> AMD, Windows XP -> Windows 7, x32 -> x64,
great, three birds with one stone!). So much for portability. But, hooray
for test-cases!
This may be related to the __lzcnt intrinsic, giving you a completely
different result, i.e., 32 - my result. Could you try
On an initial look, it seems that the shifting, popcounting, and
bitscanning functions can be improved significantly. That's all I
looked at closely, perhaps the other board routines could use some
reworking too.
I'll try my hand at optimizing it if I get the time, but the windowsy
code makes it a
2009/8/25 René van de Veerdonk :
> Nonetheless, bitmap-go as a topic keeps resurfacing on this
> mailing list every once in a while and nobody ever put solid data and a
> reference implementation behind it. That is what I wanted to accomplish with
> my mockup.
I think this is interesting informati
(AMD Phenom CPU)
Michael Williams wrote:
It came through fine the first time. Gmail probably hid the duplicate
text from you for convenience since it saw that it was text that you
already sent out. Or something.
I can compile the original (9x9) bitmap Go files in Windows 7 x64, but
when I r
It came through fine the first time. Gmail probably hid the duplicate text from you for convenience since it saw that it was text that you already sent out.
Or something.
I can compile the original (9x9) bitmap Go files in Windows 7 x64, but when I
run it I get this:
test-error [bitmap_t::low
[I do not know what happens, but this is the second time the computer-go
archives miss the body. Maybe its the attachment. I apologize for sending
this a second time, this time without attachment. If someone knows what the
problem is ... I am using Gmail]
Antoine,
I apologize for misrepresenting y
Hi René,
David,
Confession: I have not tested 19x19. As you have noted, and others
before you over the years, a 19x19 board does not fit in one but three
128-bit registers and there would be a rather big penalty as a result,
perhaps (likely?) wiping out all of the benefits of bitmaps. Antoine
--capture-all-dead --level 10
--positional-superko).
David
From: computer-go-boun...@computer-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of René van de Veerdonk
Sent: Monday, August 24, 2009 9:23 AM
To: computer-go
Subject: Re: [computer-go] Bitmap Go revisited and mockup
For many people on this list, Computer Go is a hobby and that means that it is important to do whatever you find interesting and motivating, event if it may not
be the best or most promising direction in order to become the next world champion program. There is room for pushing limits in all dire
Oops,
Speed drops more that the (per move) estimate below due to the increase in
length of the game as well, of course.
René
On Mon, Aug 24, 2009 at 5:36 PM, René van de Veerdonk <
rene.vandeveerd...@gmail.com> wrote:
> Lukasz,
> I tested Libego version 0.125 on my labtop, compiled using Visual
Lukasz,
I tested Libego version 0.125 on my labtop, compiled using Visual Studio
2008 under Windows XP with slight modifications:
#ifdef NDEBUG section commented out in "testing.h"
#include added to "fast_random.cpp"
>From the command-line with "engine -b" I observed 67-71 kpps on the same
labto
2009/8/24 René van de Veerdonk :
> David,
> Confession: I have not tested 19x19. As you have noted, and others before
> you over the years, a 19x19 board does not fit in one but three 128-bit
> registers and there would be a rather big penalty as a result, perhaps
> (likely?) wiping out all of the
If an engine (or an engine's playout policy) needs to check the legality of
every move before making a selection, this could still be a benefit.
René van de Veerdonk wrote:
David,
Confession: I have not tested 19x19. As you have noted, and others
before you over the years, a 19x19 board does
David,
Confession: I have not tested 19x19. As you have noted, and others before
you over the years, a 19x19 board does not fit in one but three 128-bit
registers and there would be a rather big penalty as a result, perhaps
(likely?) wiping out all of the benefits of bitmaps. Antoine voiced his
dis
Hideki Kato: <4a91e91a.9859%hideki_ka...@ybb.ne.jp>:
>David Fotland: <05c301ca242f$03433740$09c9a5...@com>:
>>How much would you lose for 19x19 board? A board representation is not very
>>interesting unless it scales to 19 line boards.
>
>Wait for Intel Larabee processor which has 512 bit SIMD reg
David Fotland: <05c301ca242f$03433740$09c9a5...@com>:
>How much would you lose for 19x19 board? A board representation is not very
>interesting unless it scales to 19 line boards.
Wait for Intel Larabee processor which has 512 bit SIMD registers.
Hideki
>From: computer-go-boun...@computer-go.or
How much would you lose for 19x19 board? A board representation is not very
interesting unless it scales to 19 line boards.
David
From: computer-go-boun...@computer-go.org
[mailto:computer-go-boun...@computer-go.org] On Behalf Of René van de
Veerdonk
Sent: Sunday, August 23, 2009 1:11 PM
T
25 matches
Mail list logo
