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
13 matches
Mail list logo
