OliPerft with divide Option as Pre Version for OliThink 5

[hgm]

If we want to know what it 'means' then we should follow one definition.
Bob was first so let us follow his.

If someone wants to put out the highest numbers that they can then let their function have a specific definition and a different name.

Well, I would be quit happy if they just specify what exactly they have done (as I always do when presenting my perft timings for comparison with those of others). Doesn't have necessarily to be done by the name. "Perft without making the last ply" sounds good enough to me.

Converting that to knps, like is done here, seems cheating according to any standard, though. A node is something where you do move generation. If the move generation tells you that there ar 30 moves, it still is only 1 node. The numbers presented here would sound more realistic if they were divided by 30...

[OliverBr]

Converting that to knps, like is done here, seems cheating according to any standard, though. A node is something where you do move generation. If the move generation tells you that there ar 30 moves, it still is only 1 node. The numbers presented here would sound more realistic if they were divided by 30...

Nana.. cheating is very hard word. Originally the task of perft it to calculate the number of nodes and leafs in a tree from a certain position. I actually did not make and unmake the last node (as it is nonsense), but I can do it, if you want and I would bet it won't decrease the number by 30 at all. I would expect a division by 3 or maximum 4.
I can't do it now, as I haven't the infrastructure here but I will tell you the result when done.

[hgm]

Well, don't bother. As far as timing is concerned, I think not making / unmaking the last ply gives a much more realistic impression of the speed of your search anyway. I just wanted to make sure what your numbers represented.

I agree with you about the meaning of the perft(n) function, and that there is nothing against trying to get those numbers as quickly as possible (through hashing, saving on unnecessary makes/unmakes, bulk counting in the horizon nodes, etc.) . I just don't think that you can refer counted leaves / time as knps in that case. When my engine has a hash pruning, it does not even count it as a single node, let alone as the size of the subtree that was pruned. I also don't think that most engines, reporting nodes or nps, would count leaves that were pruned by futility, which is very similar to you not making/unmaking the last ply.

[OliverBr]

But I bothered and so I did the calculation without any hash *AND* with do/undo every node:

Former: Nodes: 553838205 ms: 1840 knps: 300183

Now: Nodes: 553838205 cs: 3010 knps: 18395

Former: Nodes: 8229523927 ms: 40610 knps: 202647

Now: Nodes: 8229523927 cs: 39614 knps: 20773

So actually it's a factor 15 in the first one and a factor 10 in the second one. But the bigger effect comes from switching off hash (factor 5 in the first and factor 3 in the second). No skipping the make/unmake of the leaf makes it about a factor 3 slower.

Now you have the *real* node count: It is about 20 Millions nodes/seconds.

System was Vista 64 Bit mit VS2005 on AMD64 4600+
GCC4 on Linux 64bit is slightly slower.

[OliverBr]

Ah I forget to take out the lines in "doMove" where hash is updated. As it is not used they are obsolete. So actually it should be a bit faster.

[adams161]

hi,

Just out of curiosity is this the same ollithink that i recall from years ago that supported atomic? If so does the new version support atomic ( version 5) and will there be any improvements in this code?

Mike

[hgm]

Ah I forget to take out the lines in "doMove" where hash is updated. As it is not used they are obsolete. So actually it should be a bit faster.

More than a bit probably. Hash probing (or storing) is extremely expensive, as with this high nps you are likely to run into the memory bandwidth limit. Unless you had limited the probig and storing to internal nodes of the tree, well away from the leaves.

[OliverBr]

If anyone is interesteed. Just released OliThink 5.0.6 opensource:

http://home.arcor.de/dreamlike/chess/index.html

[Denis P. Mendoza]

Oliver,

I just replicated this (same as pm). since there was no downloadable binary from your site. I tried my luck building it. Yes it compiles and is sure has very fast search at first start, but crashes with an "illegal move fault" in Arena. Any which way I build it, the fault was the same using ICC. or MSVC. Did I miss something here? It was a rewrite from the old code, so I have no idea where it went wrong. Thanks.

[Denis P. Mendoza]

It's funny that t works well using MingW compiler.

I'll try some MingW-pgo builds till Master Jim hasn't made one yet for initial testing of our members here.

Just informing