Syzygy / egbb discussion

[syzygy]

The 68GB are Ok. We are talking about that 80Gb DTZ table that is there to cover up for the 0.1% cases that the engine needs to ensure a win.

If you really want to compare my solution to yours, then it should be quite obvious that the DTZ50+ tables are an extra that is simply not part of your solution. That's not criticism, but just a fact. You never intended to include DTZ or DTM or whatever and that is just fine. I did intend to provide DTZ and so I did. I also intended to incorporate the 50-move rule ever since a discussion in Kirill Kryukov's forum in which the "DTZ50+" metric was developed, and so I did.

but I spent months polishing the way bitbases are used for making progress so that is some work I did (forgive the arrognace). So that is a choice I made and worked on a solution along with many authors.

As far as I understand, your "polishing" involves including into the probing code some sort of evaluation function.

In my view this is completely unnecessary. To win most positions using only WDL, the simple solution that just takes a few hours to implement goes as follows:

- if the root position is not in the tablebases, then probe as much as makes sense (which depends on the efficiency of the probing code). Treat win/loss scores as one would treat mates. This ensures that the engine that finds a forced tablebase win actually manages to reach a winning tablebase position.

- if the root position is in the tablebases (say a 6-men position), then use the WDL tables at the root to select those moves that preserve the win. Now perform a search on just those moves. Do not probe 6-men positions within the search, but only 5-men or less. In most positions this will make enough progress to win the game. (To get somewhat more natural play one could choose to not probe within the search at all, but the proportion of won positions that get drawn by the 50-move rule will somewhat increase.)

Syzygy does have a sample implementation 'stockfish' that needs both to make progress so size is 150Gb.

Simply wrong.

Why don't we all have respect for each other's work, it is not even that importan interms of Elo.

Hah and that is coming from you?

[syzygy]

The part that made me jump in was Houdart blaming Scorpio bitbases for his poor implementation. I think we all know that Houdart was just spreading BS.

Houdart's observation was that all TB solutions he had tried so far suffered from a synchronisation bottleneck when using many threads and that my solution does not, or to a much lesser degree.

I have no personal experience with any of the other solutions, but Houdart obviously has. Simply denying that a synchronisation bottleneck exists and calling him a liar is not exactly conducive to a healthy discussion.

The reason that my implementation does well with many threads is that it leaves all the complications to the OS. Current OSes are pretty good at handling many threads.

Where is the DATA? You were jumping around when Kai first produced data showing how bad Houdini played with scorpio bitbases.

Me? Where is the post?

I have not been jumping around in any part of this affair. I only cringe when I see one yet more of your immature posts showing your immature attitude to practically everything. You are coming up with strange paranoid nonsense. It's just sickening.

[Daniel Shawul]

the root position is not in the tablebases, then probe as much as makes sense (which depends on the efficiency of the probing code). Treat win/loss scores as one would treat mates. This ensures that the engine that finds a forced tablebase win actually manages to reach a winning tablebase position.

I guarantee you don't understand crap because you never trid it. Even with the root position not in in 6-men, the engine can fail to make progress. But good luck with your 80Gb solution Atleast Houdart will thank you for that.

[syzygy]

the root position is not in the tablebases, then probe as much as makes sense (which depends on the efficiency of the probing code). Treat win/loss scores as one would treat mates. This ensures that the engine that finds a forced tablebase win actually manages to reach a winning tablebase position.

I guarantee you don't understand crap because you never trid it. Even with the root position not in in 6-men, the engine can fail to make progress.

If my engine reports "mate in 20 moves", then the next move it will report "mate in N moves" moves with N < 20. This is progress.

If my engine reports "tablebase win in 20 moves", then the next move it will report "tablebase win in N moves" with N < 20. This is again progress.

This is not rocket science.

[mvk]

He is talking about 6 men:

Code: Select all

Shredder: 40Gb
Syzygy; 150Gb
Scorpio*: about 50Gb

So infact the difference is 110Gb extra space to shredder and 100Gb to scorpio. If we go by 5 men results, it looks like a total waste but one has to do the 6-men test to know since there are more cases that need attention. But Diep has used 6-men WDL alone so bitbases already has some support there too.

*In process of generation.

Seems like comparing apples and oranges here. The Syzygy WDLs are ~68GB, not 150Gb[sic].

The 68GB are Ok. We are talking about that 80Gb DTZ table that is there to cover up for the 0.1% cases that the engine needs to ensure a win. Houdart didn't know how to use Bitbases alone so he screamed Syzygy super blah blah. So there you go, sir, your bulk of 80Gb to cover up for your lack of skills. I am sure they will serve people like him well, but I spent months polishing the way bitbases are used for making progress so that is some work I did (forgive the arrognace). So that is a choice I made and worked on a solution along with many authors.

It seems also from Kai's tests Shredder needs Nalimov TBs to make progress but atleast they don'ts offer the bitbases and don't offer implementations either. Syzygy does have a sample implementation 'stockfish' that needs both to make progress so size is 150Gb. What are we going to say about Gaviota that has a soft probe but its DTM is 7Gb? Just counting what is offered as a complete solution is safer.

Even if we compare sizes of EGBBs, like I said there are choices to be made. For example Syzygy chose two sided, but has to make a move generation for each positon probe to check if a capture exists, and then probe into smaller endgames to find the capture's values. Now I could scream, "Hey but they need sub-endgames?", but that will be petty but it is things like that that were being thrown around. I tried far more that that , prediction by hard-code eval() for 5-men , a search of 1-ply,2-ply, neural nets prediction, Queenlan's rule extraction etc. Their result for me was that I was able to reduce the two sided sizes significantly but not very much the critcal one sided bitbases. So I said to hell with that, again a choick. Syzygy comes here and talks about stuff as if it is new but I guarantee nothing is new under the sun. IMO Knightdreamer's bitbases did a lot of intersting stuff back then but no one talks about them now. Or Jesper Torp's work on bitbases that have new ideas in them that everyone learned from but that the bitbases are not available. Here we are talking about implementations for god's sake!!

Most have tested many things before making a choice. For example, Syzygy does a rather cumbersome check in search of reduction of sizes by permuting 6! positons. I chose a static PKNBRQ which serves. There is nothing to bicker about here because the idea comes from somebody's work which doesn't have a bitbase. So yes everything is apples and oranges with size and access stuff. And it is very easy to brainwash chess players to use your stuff, but that only serves your ego. Why don't we all have respect for each other's work, it is not even that importan interms of Elo. Here I am forced to make a payback (though everything I say is accurate to what I belive), even though I forgot about them for years since I had my fun already. The constant bickering by the other group warrants a put up or shut up, which is ELO after all, and all seem to be equal so far ...

Are there any probing time benchmarks around for the different 6-men WDL systems, or is the jury still out?

Ronald made a bet that the OS does an excellent job at caching, compared to fetching and caching from user land. I admit I'm sympathetic to the concept as I made exactly the same bet for doing my own 5-man, uncompressed, bit bases. In my case with even less probing code than Syzygy's, because I stuffed all data in a .so and let the linker resolve everything, and Ronald has to go through mmap. But I'm switching away from my method as ELF has these 2GB limitations, not to mention the hoops to jump through to put raw data in an .so (and the trouble of having user libs).

You focussed on making the DTZ/DTM not needed. But I wonder why that's a super big deal if that's just a factor 2 more space, and needs eg-specific code to plug the gaps (and the extra disk space is only accessed from root, so no additional RAM requirements). How do you know all gaps are plugged? 99.9% vs 100.0% doesn't mean a thing elo-wise. But there is more than elo. Elo-wise, mating in KBNK is not important, but you want to avoid exposure like this: . From my point of view, 2x extra space, half of it on a slower medium, is not a big issue if it covers 100.0%.

Anyway, probe time comparisons for the WDLs, with realistic access patterns, would be interesting. In fact, that would just mean NPS ratios. (Disk space I couldn't care less personally.)

[Daniel Shawul]

Ronald, let me first say that I had respect for you in the past and never hesitated to express when i felt you deserved it. But you have this arrogance in you that you know everything about TBs or whatever. No one is like that, and if you haven't actually done the stuff, you better be careful what you say. Beating your chest up saying this is not rocket science is not gonna bring you anything. "I can do anything you ever did with bitbases given the time and the interest". Fact is I haven't done what you did and you haven't done what I did. I am 100% sure you don't have half the experience that I had about making progress with bitbases alone and I am not being arrogant. I simply spent more time on it to make progress in a way i thought was interesting. So trying to lecture me on this, when you apparently chose the DTZ way to make progress, is kind of foolish on your part. (Now this is arrogant but maybe it stops you from trying to lecture me).

Anyway before all that, bitbases were commonly used to cutoff drawing/loosing moves without actually scoring the position. The engine cutoffs moves only by looking at the WDL values and not assigning any score to the leaf node. The engine will show evaluations normally as if it is not in playing the end game with TBs. I didn't like that but granted engine will play stronger with bitbases. IIRC Delfi/knightdreamer/shredder all use it in that way, but i wanted my bitbases to return high scores like DTM tables while at the same time ensuring progress. The previous approach doesn't suffer from this problem because bitbases scores are never mixed with the standard eval() score. For instance, have you ever mixed the the distance to where the bitbases are probed with other material score? In your case you have the distance to zeroing explicitly, which I take care of by returing the bitbase score when a pawn push/capture is made. Then the other moves that reach a certain depth all will start to do the same. Using a value of 1 for this distance is like not using it so i have it at 40 or soething. This is not much but a somewhat surprizing result (observation), atleast for me that no one used before I did. And you definitely need to do that to make progress with bitbases so that it prefers the probes near the root just like mate, i.e. if you want to make cutoffss _anywhere_ inside the tree. The first approach I used was to probe them in eval() where the distances from the root are pretty much uniform but still needed distances to be incorporated because of extensions/reductions.

[Daniel Shawul]

Are there any probing time benchmarks around for the different 6-men WDL systems, or is the jury still out?

That is the problem, nobody prodces DATA except Kai so far.

Ronald made a bet that the OS does an excellent job at caching, compared to fetching and caching from user land. I admit I'm sympathetic to the concept as I made exactly the same bet for doing my own 5-man, uncompressed, bit bases. In my case with even less probing code than Syzygy's, because I stuffed all data in a .so and let the linker resolve everything, and Ronald has to go through mmap. But I'm switching away from my method as ELF has these 2GB limitations, not to mention the hoops to jump through to put raw data in an .so (and the trouble of having user libs).

All the power to him but badmouthing other approaches got to stop. Lets treat a programming approach as what it is not more not less. For instance do you really think mmap() or my dll approach would be so interesting to others except us, given how we both like our approaches to death? For instance i am not even convinced that the decompression used by syzygy as described in the paper is better than optimized implementation. Even my implementation goes like a 1000Mb/sec for some files. Apparently the syzygy circles around the supposedly better advantage of reading in the values without actually decompressing the blocks. My decompression of blocks is fast already and once that is done next probes are pretty fast value[ind], but syzgy has to do that online decompression every time. Then there is the additonal benefit of caching decompressed blocks. Saying they are not efficient for multi-threaded is wrong because there are a ton of ways to write the most efficient cache in O(1) access, and ofcourse if the OS caches' efficiently there is no reason a programmer can't. The data is also not redundant since one is compressed while the other is not. All I am saying is there are many ways to do it but to prove that one approach is superior will need data, not just because you like the approach conceptually. That would be too close minded since you have already decided on what is best conceptually.

You focussed on making the DTZ/DTM not needed. But I wonder why that's a super big deal if that's just a factor 2 more space, and needs eg-specific code to plug the gaps (and the extra disk space is only accessed from root, so no additional RAM requirements). How do you know all gaps are plugged? 99.9% vs 100.0% doesn't mean a thing elo-wise. But there is more than elo. Elo-wise, mating in KBNK is not important, but you want to avoid exposure like this: . From my point of view, 2x extra space, half of it on a slower medium, is not a big issue if it covers 100.0%.

They work 99.9% of the time because they have worked for 10 years with no reports from testers which wasn't the case when they were first realeased. The kBNK is the only one I treat special, and I am sure anyone there are 5 men and especially 6 men 3vs3 tht may require attention. But I can simply discourage transitions to those endgames by modifying the bitbase scores. DTZ gaurantees that 0.1% but still requires help from engines not to make unnatural plays so the programmer is not saved from this work , which wouldn't be needed if they were DTM.

Anyway, probe time comparisons for the WDLs, with realistic access patterns, would be interesting. In fact, that would just mean NPS ratios. (Disk space I couldn't care less personally.)

Elos speeks louder than anything IMO, because size also contributes to suitablity for caching . There is tradeoff between access time and size which are tied, and simply measuring access time is unfair to those who chose to have less size.

[syzygy]

I am 100% sure you don't have half the experience that I had about making progress with bitbases alone and I am not being arrogant. I simply spent more time on it to make progress in a way i thought was interesting.

You certainly chose another path than I did. That does not mean I cannot point out that there is a rather simple way of making progress with just WDL. You have been repeatedly claiming that this was complicated and my solution therefore cannot do it, so now I feel fully entitled to explain how it can be done (and how I have done it) in a simple way.

The most important thing is to distinguish between two cases:
1. root position not in WDL tables;
2. root position in WDL tables.

From your explanations I can't figure out which case you are talking about.

Making progress in case 1 can be handled in the same way as all engines handle making progress towards mate. You say this is not true, well I can only say this is not rocket science.

Making progress in case 2 is more tricky and not absolutely guaranteed unless at least DTZ is available. However, for the majority of cases you can just leave it to the search. The search already uses a scoring function in the form of the evaluation, so I see no need to duplicate this work. The search can be helped by first eliminating, using the WDL tables, the root moves that do not win and by probing during the search positions after a capture. Well, I have already explained this a few times now.

Obviously my preference goes to using the DTZ50+ tables, since they exist, there is no good reason not to use them in a time of multi-TB HDDs, and this is the only way of playing accurately under the 50-move rule.

[ernest]

So for now the only alternative is then the Shredder bases?

I am not aware that the 6-man Shredderbases are available...

edit: ...upps, I see Ronald just said that!

[Daniel Shawul]

So for now the only alternative is then the Shredder bases?

I am not aware that the 6-man Shredderbases are available...

edit: ...upps, I see Ronald just said that!

There is Robbobases already, so nothing new.

And now Scorpio bitbases KPPkpp 1.45pm today done! Burn