Starting a new project - Rommie

[Mike Sherwin]

Hi Mike , Can you please share a Windows complie ? " So next I'll just have to write an actual Perft() and then I guess I'll post the source and exe on MediaFire. That is unless someone wants to swap in a different move generator sooner than that. If so just ask and I'll upload the source and exe right away."

https://www.mediafire.com/file/72e3ovs3 ... ie.7z/file
It was not quite ready because I needed to do a couple of things first. Oh well.
It understands two commands.
1)setboard somefen
2)speedt // speedt is hardwired for 6 ply. I had trouble inputting a parameter for speedt.

It is currently set up not to make and unmake the leaf node. The conversion though is just to divide by three to get the ~rate for making and unmaking all moves. The exe is in the x64/release folder. I tested the download link and it worked fine.

For those that want to compile the code use MSVC 2022. And the only file needed to compile is Rommie.ccp as all the other files are includes in Rommie.cpp.

i see a lot of "ifs" in move gen for sliders, i don't know if this optimization will work but why not make rays an array of 66 elements and use another pointer that points at "rays + 1" to resolve the otherwise illegal indexes (64 and 63 - 64) returned by std::countr_zero()?

I rewrote all the sliders to be like this:

Code: Select all

	case WB:
	  sq = std::countr_zero(ray[fs].rayNW & occ);
	  rayNW = (sq != 64) * ray[sq].rayNW;
	  sq = std::countr_zero(ray[fs].rayNE & occ);
	  rayNE = (sq != 64) * ray[sq].rayNE;
	  sq = std::countl_zero(ray[fs].raySE & occ);
	  raySE = (sq != 64) * ray[63 - sq].raySE;
	  sq = std::countl_zero(ray[fs].raySW & occ);
	  raySW = (sq != 64) * ray[63 - sq].raySW;
	  genbb[ply][fs] = rayNW | rayNE | raySE | raySW;
	  genbb[ply][fs] ^= bob[fs]; // bishop on board [fs]
	  atkbb[ply] |= genbb[ply][fs];
	  genbb[ply][fs] &= notMe;
	  break;

Which is what I had originally intended. I just got it confused at some point along the way.
From 167 million nps to 184 million nps
Thanks!

[tcusr]

but you're still accessing elements out of bounds, to try what i mean in Variables.cpp write this

Code: Select all

Rays _ray[66];
Rays *ray = _ray + 1; 

you don't even need the multiplication with (sq != 64) because the illegal squares are already set to zero (global variable are always zero-initialized)

[Mike Sherwin]

but you're still accessing elements out of bounds, to try what i mean in Variables.cpp write this

Code: Select all

Rays _ray[66];
Rays *ray = _ray + 1; 

you don't even need the multiplication with (sq != 64) because the illegal squares are already set to zero (global variable are always zero-initialized)

I think there is a problem with countl_zero needing to be flipped with sq = 63 - sq in order to work. That is because 63 - 64 is -1. So for countl_zero the case of sq being 64 needs to be solved first. You are right for the case of countr_zero though because 0 to 64 will just simply work for the extra entry lookup.

But it can be made to work if the negative tables SE, SS, SW and WW are reversed at initialization so that 63 - sq is not needed.

[tcusr]

but you're still accessing elements out of bounds, to try what i mean in Variables.cpp write this

Code: Select all

Rays _ray[66];
Rays *ray = _ray + 1; 

you don't even need the multiplication with (sq != 64) because the illegal squares are already set to zero (global variable are always zero-initialized)

I think there is a problem with countl_zero needing to be flipped with sq = 63 - sq in order to work. That is because 63 - 64 is -1. So for countl_zero the case of sq being 64 needs to be solved first. You are right for the case of countr_zero though because 0 to 64 will just simply work for the extra entry lookup.

But it can be made to work if the negative tables SE, SS, SW and WW are reversed at initialization so that 63 - sq is not needed.

it works even for -1 because ray points at _rays + 1
basically every calculation is done with an offset of 1

[Mike Sherwin]

but you're still accessing elements out of bounds, to try what i mean in Variables.cpp write this

Code: Select all

Rays _ray[66];
Rays *ray = _ray + 1; 

you don't even need the multiplication with (sq != 64) because the illegal squares are already set to zero (global variable are always zero-initialized)

I think there is a problem with countl_zero needing to be flipped with sq = 63 - sq in order to work. That is because 63 - 64 is -1. So for countl_zero the case of sq being 64 needs to be solved first. You are right for the case of countr_zero though because 0 to 64 will just simply work for the extra entry lookup.

But it can be made to work if the negative tables SE, SS, SW and WW are reversed at initialization so that 63 - sq is not needed.

it works even for -1 because ray points at _rays + 1
basically every calculation is done with an offset of 1

Okay, I understand what you mean now. I've done the same thing before:
int orgtbl[102];
int *table = orgtbl + 2; // and then table[-2] is the same as orgtbl[0] or something like that. I'll give it a try.

[Mike Sherwin]

That worked! Thanks. 167 mnps -> 184 mnps -> 189 mnps.

Code: Select all

Rays rays[66];
Rays* ray = rays + 1;

	case WB:
	  sq = std::countr_zero(ray[fs].rayNW & occ);
	  rayNW = ray[sq].rayNW;
	  sq = std::countr_zero(ray[fs].rayNE & occ);
	  rayNE = ray[sq].rayNE;
	  sq = std::countl_zero(ray[fs].raySE & occ);
	  raySE = ray[63 - sq].raySE;
	  sq = std::countl_zero(ray[fs].raySW & occ);
	  raySW = ray[63 - sq].raySW;
	  genbb[ply][fs] = rayNW | rayNE | raySE | raySW;
	  genbb[ply][fs] ^= bob[fs]; // bishop on board [fs]
	  atkbb[ply] |= genbb[ply][fs];
	  genbb[ply][fs] &= notMe;
	  break;

[Jjaw]

Mike , Thanks for the download. I downloaded it & tried to run engine. 1st attempt to run failed & said I needed an mscvr dll. Downloaded dll to engine folder. 2nd attempt to run engine failed & said I needed a different dll. Downloaded that dll to folder & tried to run engine. Engine failed to open & said failed to find entry point. I gave up. Thank you for your effort to share your engine.

[Mike Sherwin]

Mike , Thanks for the download. I downloaded it & tried to run engine. 1st attempt to run failed & said I needed an mscvr dll. Downloaded dll to engine folder. 2nd attempt to run engine failed & said I needed a different dll. Downloaded that dll to folder & tried to run engine. Engine failed to open & said failed to find entry point. I gave up. Thank you for your effort to share your engine.

I can run it from any folder and it runs just fine. I don't call any functions from any dll's in my code. So, I'm sorry, but I have no clue why it won't run for you. I'm running Windows 10. Maybe someone else might chime in that understands the problem.

[tcusr]

Mike , Thanks for the download. I downloaded it & tried to run engine. 1st attempt to run failed & said I needed an mscvr dll. Downloaded dll to engine folder. 2nd attempt to run engine failed & said I needed a different dll. Downloaded that dll to folder & tried to run engine. Engine failed to open & said failed to find entry point. I gave up. Thank you for your effort to share your engine.

I can run it from any folder and it runs just fine. I don't call any functions from any dll's in my code. So, I'm sorry, but I have no clue why it won't run for you. I'm running Windows 10. Maybe someone else might chime in that understands the problem.

did you compile it statically?
maybe the dll version needs to be the same as the visual studio version

[Mike Sherwin]

I've not been able to do much. Just some more bug fixing and some optimization. So this is where the code is so far performance wise compared to my previous work.

My example bitboard speedt code is called Halfwit and was written just before I wrote RomiChess and uses the exact same classic bitboards as RomiChess. Starting position all examples. All moves made and unmade.

34,956,440 nodes per second.

Conundrum is similar to HGM's mailbox trials in that it updates scanning out from the from and to squares to update move/attack tables.

54,204,298 nodes per second.

Carnivor is a GNU 4 style move generator.

53,923,811 nodes per second.

Godzilla is Carnivor hand written in assembler.

69,665,358 nodes per second.

And now my fastest so far Rommie.

83,869,433 nodes per second.

Some caveats favoring Rommie code. The mailbox code in Carnivor and Godzilla is very close to optimal as there are no nested loops. One loop handles it all for each piece. And Conundrum is fast because it only updates the move list. And in Rommie classical bitboards are used. If PEXT on a PEXT enabled cpu or magic was used Rommie may very well be even significantly faster. Although the classical Bob approach is a bit more optimised now.

If we extrapolate the search performance from RomiChess to Rommie we should be able to approximate the search performance of Rommie. Assuming Rommie will be like RomiChess in all other ways.

Romichess 7,406,801 nodes per second in search.

So if we take the 35 million of Halfwit (same as Romi's mg) and the 83.9 of Rommie the factor is 2.4. 7,406,801 x 2.4 = approximately 17,776,322 nodes per second search speed for Rommie under the proposed conditions. Bricabrac was only 2.5 million nodes per second faster than Romi. Rommie is 7.8 million nodes faster than Bricabrac!

I knew that I could do better!