Gigantua: 1.5 Giganodes per Second per Core move generator

[dangi12012]

Guys great news - finally broke the 2 GNode/s barrier for kiwipete:

Newest v1.3 Release here:
https://github.com/Gigantua/Gigantua

Sourcecode coming soon!

....
Perft Kiwi 1: 48 0ms 5.33333 MNodes/s
Perft Kiwi 2: 2039 0ms 169.917 MNodes/s
Perft Kiwi 3: 97862 0ms 998.592 MNodes/s
Perft Kiwi 4: 4085603 2ms 1625.14 MNodes/s
Perft Kiwi 5: 193690690 96ms 2005.54 MNodes/s
Perft Kiwi 6: 8031647685 4403ms 1824.04 MNodes/s
.....
Perft aggregate: 18999768562 11609ms 1636.51 MNodes/s

Question: Does somebody have a link to a compressed PEXT lookup table? My lookup still uses uncompressed 2Mbyte non overlapping pext lookup.
600KB should be the current standard here?

[R. Tomasi]

Guys great news - finally broke the 2 GNode/s barrier for kiwipete:

Newest v1.3 Release here:
https://github.com/Gigantua/Gigantua

Sourcecode coming soon!

....
Perft Kiwi 1: 48 0ms 5.33333 MNodes/s
Perft Kiwi 2: 2039 0ms 169.917 MNodes/s
Perft Kiwi 3: 97862 0ms 998.592 MNodes/s
Perft Kiwi 4: 4085603 2ms 1625.14 MNodes/s
Perft Kiwi 5: 193690690 96ms 2005.54 MNodes/s
Perft Kiwi 6: 8031647685 4403ms 1824.04 MNodes/s
.....
Perft aggregate: 18999768562 11609ms 1636.51 MNodes/s

Question: Does somebody have a link to a compressed PEXT lookup table? My lookup still uses uncompressed 2Mbyte non overlapping pext lookup.
600KB should be the current standard here?

Just had a look at your repo...

1.) There's a typo in your readme.md, although I actually prefer the sound of "Giganuta"...
2.) Do you really expect people will fund your project?
3.) From the looks of it you're using the Microsoft compiler? If so you could make a CMake project and compile against Clang. You might beat the 3GN/s barrier then - at least by your weird definition of a node.

[dangi12012]

3.) From the looks of it you're using the Microsoft compiler? If so you could make a CMake project and compile against Clang. You might beat the 3GN/s barrier then - at least by your weird definition of a node.

Yes. Dont know if clang is any faster. I can verify that g++ under WSL is slower but thats not a bare metal and fair comparison.

What I need before release: Does somebody have the source to a compressed PEXT lookup table? I have 2MB which is bad for cache - and dont want to spend another 2 weeks creating a optimal overlap finder. With this smaller table the movegen is as fast as it can go with 100% original ideas of mine. I didnt think of what is called zobrist hashing on my own.
What I need after release: I need a starting point (maybe existing github repo?) where zobrist hashes are implemented to start on the lookup.

[R. Tomasi]

3.) From the looks of it you're using the Microsoft compiler? If so you could make a CMake project and compile against Clang. You might beat the 3GN/s barrier then - at least by your weird definition of a node.

Yes. Dont know if clang is any faster. I can verify that g++ under WSL is slower but thats not a bare metal and fair comparison.

For my engine clang builds are about a factor 2 faster than the MSC builds. You can compile with clang under Visual Studio and create a windows executable. You will however need to convert your project to CMake.

[R. Tomasi]

I feel compelled to tell you again, that you're calculating the speed of your movegen in a misleading way: Let's take the start position, for example.

A depth 7 perft of that position traverses 3.20 billion leafs and 124 million nodes. If on your machine it takes 2736ms that means that your movegen is running at 45.3 MN/s. Please stop deceiving people by using a flawed calculation (elsewise one has to wonder if you're doing it on purpose).

[dangi12012]

I feel compelled to tell you again, that you're calculating the speed of your movegen in a misleading way: Let's take the start position, for example.

A depth 7 perft of that position traverses 3.20 billion leafs and 124 million nodes. If on your machine it takes 2736ms that means that your movegen is running at 45.3 MN/s. Please stop deceiving people by using a flawed calculation (elsewise one has to wonder if you're doing it on purpose).

You have no idea why this is so great. This will be Transformative. Yes 3E9 nodes are visited and i could print the fen right there.
Again: Every node (leaf or not) is Expanded. Bulk counting is optional but enabled in the release. I know what you mean and its so great to not need a movelist. The compiler inlines count++ into the movegen itself. You will see! Board before + after + movetype is there in the leaf. Ready to be stored or pruned or hashed etc. Yes i mean that for all 3E9 nodes.

All movegens I ever saw used a movelist. This does not. And you still can create an ordered list or directly prune.

Bulk is also enabled in qperft/juddperft by default. So stop crying please. Especially if just dont understand without sourcecode.

Does somebody have the source to a compressed PEXT lookup table? Thanks!

[R. Tomasi]

I feel compelled to tell you again, that you're calculating the speed of your movegen in a misleading way: Let's take the start position, for example.

A depth 7 perft of that position traverses 3.20 billion leafs and 124 million nodes. If on your machine it takes 2736ms that means that your movegen is running at 45.3 MN/s. Please stop deceiving people by using a flawed calculation (elsewise one has to wonder if you're doing it on purpose).

You have no idea why this is so great. This will be Transformative. Yes 3E9 nodes are visited and i could print the fen right there.
Again: Every node (leaf or not) is Expanded. Bulk counting is optional but enabled in the release. I know what you mean and its so great to not need a movelist. The compiler inlines count++ into the movegen itself. You will see! Board before + after + movetype is there in the leaf. Ready to be stored or pruned or hashed etc. Yes i mean that for all 3E9 nodes.

All movegens I ever saw used a movelist. This does not. And you still can create an ordered list or directly prune.

Bulk is also enabled in qperft/juddperft by default. So stop crying please. Especially if just dont understand without sourcecode.

Does somebody have the source to a compressed PEXT lookup table? Thanks!

*sigh*

I give up. Just continue to ruin your reputation on a public forum, if you want. Printing the FEN does not cut it. Print the number of legal moves, then you're on the right track.

[BrokenKeyboard]

this is literally emmanuel-perft with an executable. congrats.

[spirch]

until source code is released i take this thread as a funny imaginary idea, a nice storytelling

and no running unknown code even in a VM / sandbox is not an option for me

[R. Tomasi]

this is literally emmanuel-perft with an executable. congrats.

He should print the position encoded as 2 words instead of a FEN