Starting a new project - Rommie

[Mike Sherwin]

It seems now that everything is working. The NPS of the starting position is 93.7 million. So not bad. I know that most authors when they write their Perft() do not make and unmake the leaf nodes and other tricks to make their Perft() as fast as possible. Speedt() is not Perft() but out of curiosity I wanted to see how fast Speedt would run if the leaf nodes were not made and unmade, only counted. That number for the starting position is 292.3 million NPS. That is only running on one thread. I have no idea how good or bad that is because I have nothing to compare it with. 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.

[dangi12012]

What's the node count and perft for kiwipete position for you?

[Mike Sherwin]

What's the node count and perft for kiwipete position for you?

I have not written a perft yet. That is next. Speedt was written to test raw speed without regard for legality. And also so I could start debugging. And everything is done except castling and underpromotion as they were not needed for raw speed testing. So with the above the NPS for the Kiwi Pete is 315,466,712.

[Mike Sherwin]

What's the node count and perft for kiwipete position for you?

There were still some stupid bugs. Well maybe the bugs aren't stupid. Anyway, the numbers took a hit. Not making leaf moves.
Original 167.5 million nps
Kiwipete 231.3 million nps

[dangi12012]

What's the node count and perft for kiwipete position for you?

There were still some stupid bugs. Well maybe the bugs aren't stupid. Anyway, the numbers took a hit. Not making leaf moves.
Original 167.5 million nps
Kiwipete 231.3 million nps

That is the perft - but what is your node count?
The perft metric is only valid once the node counts match the reported numbers.

Its too soon to report perft numbers before enpessant and castling is working correctly etc.

[Mike Sherwin]

What's the node count and perft for kiwipete position for you?

There were still some stupid bugs. Well maybe the bugs aren't stupid. Anyway, the numbers took a hit. Not making leaf moves.
Original 167.5 million nps
Kiwipete 231.3 million nps

That is the perft - but what is your node count?
The perft metric is only valid once the node counts match the reported numbers.

Its too soon to report perft numbers before enpessant and castling is working correctly etc.

Okay fine. But I was not reporting perft. I said I was not reporting perft. I was just reporting the raw speed for generating moves with speedt. I said that was all that I was doing while debugging code. I said next I'll write a perft. So next I'm going to write a perft. I'll spare everyone any further updates until my perft is finished.

[Jjaw]

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."
[/quote]

[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."

[/quote]
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.

[tcusr]

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()?

[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 read from someone on the forum that in something like ...

sq = std::countr_zero(ray[fs].rayNW & occ);
rayNW = sq == 64 ? 0 : ray[sq].rayNW;

... that the second line would be optimised to use cmov and would be branchless. I could try writing the second line like this instead.

rayNW = (sq == 64) * ray[fs].rayNW;

I'll do that now and report back.