Syzygy / egbb discussion

[Daniel Shawul]

I got an amazing result in some 2,600 games, 15 +/- 8 Elo (2SD) points benefit from 3-5 Syzygy on HD using Stockfish 21.10.2013 at 15+0.15 time control. I have never seen such improvement with any other TBs. On SSD they are probably even better. Kudos to Ronald.

Are you for real, or just trollin? You just produced the same elo with same error bars with shredderbases couple of days ago, as did Ferdinand with scorpio bitbases.
http://talkchess.com/forum/viewtopic.ph ... 13&t=49684

[Laskos]

I got an amazing result in some 2,600 games, 15 +/- 8 Elo (2SD) points benefit from 3-5 Syzygy on HD using Stockfish 21.10.2013 at 15+0.15 time control. I have never seen such improvement with any other TBs. On SSD they are probably even better. Kudos to Ronald.

Are you for real, or just trollin? You just produced the same elo with same error bars with shredderbases couple of days ago, as did Ferdinand with scorpio bitbases.
http://talkchess.com/forum/viewtopic.ph ... 13&t=49684

I mean TBs on HD. Yes, with EGBBs loaded into RAM I got the same result, but not with HD TBs previously (Nalimovs gave 0+/-2).

[Daniel Shawul]

Nalimov is too big so cacheing is not as efficient as for small EGBBs that typically exhibit a high hit rate. It probably doesn't matter much whether they started out in RAM/SSD/HD because the most relevant parts will be in system cache soon.

Could you please post your result in the previous thread so that it can be referred? It helps to put a stop to the misinformed stuff that goes around here.

[Ryan Benitez]

Given equal implementation in the chess engine I would expect equal performance using Shredderbases, Syzygy, or Scorpio bitbases. Until someone shows me otherwise beyond statistical error with proof of equal implementation I consider the Syzygy hype to be strange marketing.

[Daniel Shawul]

Given equal implementation in the chess engine I would expect equal performance using Shredderbases, Syzygy, or Scorpio bitbases. Until someone shows me otherwise beyond statistical error with proof of equal implementation I consider the Syzygy hype to be strange marketing.

Tell me about it. Most of it is fabricated bullshit like the one Houdart pulled. If you squeeze they squish. You can't discuss properly since they produce NO data to backup any claims! When we finally did, you saw what happened. Look how awesome my non-existent cache is...and how your sucky compression is etc... All I see is an 80Gb wasted space on DTZ when in practice bitbases suffice. Never back up claims, just blow hot air till death and you might get lucky some butthurt engine author will support them.

[Houdini]

Given equal implementation in the chess engine I would expect equal performance using Shredderbases, Syzygy, or Scorpio bitbases. Until someone shows me otherwise beyond statistical error with proof of equal implementation I consider the Syzygy hype to be strange marketing.

Your comment is valid when only a single thread is running.
But, as I've noted in the past on this forum, neither Nalimov nor Gaviota nor Scorpio bases are very good when the probing is heavily multi-threaded - say with 8 or 16 threads.

To understand what I'm saying, I invite you to run some 16-core analysis on an endgame position, and you'll see that Syzygy bases reduce the overhead by an order of magnitude compared to the three other table base types.

Cheers,
Robert

[Houdini]

Most of it is fabricated bullshit like the one Houdart pulled.

I challenge you to find any negative comment I wrote about your bitbases. Other than a cursory remark about multi-threaded performance (see also the post above), you will find none.
As I said before and as is written in the user's manual, the egbb implementation in Houdini works well for analysis but is not intended for match play.

I'm not sure what exactly your problem is or why you want to disturb a thread about Syzygy bases, but please stop projecting your personal frustrations on me.

[Daniel Shawul]

Given equal implementation in the chess engine I would expect equal performance using Shredderbases, Syzygy, or Scorpio bitbases. Until someone shows me otherwise beyond statistical error with proof of equal implementation I consider the Syzygy hype to be strange marketing.

Your comment is valid when only a single thread is running.
But, as I've noted in the past on this forum, neither Nalimov nor Gaviota nor Scorpio bases are very good when the probing is heavily multi-threaded - say with 8 or 16 threads.

To understand what I'm saying, I invite you to run some 16-core analysis on an endgame position, and you'll see that Syzygy bases reduce the overhead by an order of magnitude compared to the three other table base types.

Cheers,
Robert

Haha it is very likely that I have found yet another problem of yours with scorpio EGBBS ,besides your botched up implementation ofcourse. Scorpio egbbs are not compiled for more than 8 processors. The number 8 is hard coded so even Jim never compiled for more than 8. No wonder you see orders of magnitudes decrease in speed, and may even hang, this pretty much explains it. I repeat No one ever compiled egbbdll for more than 8 processors Look in the code if you don't beleive me. Infact I know so because TCEC's Martin told me Scorpio can't run with 16 cores and I told him exactly that.

And I also looked in the cache and realized how good I implemented it! To begin with every single EGBB has its own cache that would only require locking when two threads probe KBNKB simultanesouly. Even with that a 16Mb cache is like 2000 entries which is fast.

[Houdini]

Haha it is very likely that I have found yet another problem of yours with scorpio EGBBS ,besides your botched up implementation ofcourse. Scorpio egbbs are not compiled for more than 8 processors. The number 8 is hard coded so even Jim never compiled for more than 8. No wonder you see orders of magnitudes decrease in speed, and may even hang, this pretty much explains it. I repeat No one ever compiled egbbdll for more than 8 processors Look in the code if you don't beleive me. Infact I know so because TCEC's Martin told me Scorpio can't run with 16 cores and I told him exactly that.

And I also looked in the cache and realized how good I implemented it! To begin with every single EGBB has its own cache that would only require locking when two threads probe KBNKB simultanesouly. Even with that a 16Mb cache is like 2000 entries which is fast.

You fail to realize that Houdini doesn't use egbbdll, it compiles the Scorpio code in the engine itself. The Scorpio code in Houdini works with up to 32 threads.

It must be gratifying for you to boast the efficiency of your own code, but your reply also shows that you've never actually used it with large number of threads probing simultaneously. I suggest that you start doing that, compare the performance to the Syzygy bases, and then we can continue the discussion.

[Daniel Shawul]

Haha it is very likely that I have found yet another problem of yours with scorpio EGBBS ,besides your botched up implementation ofcourse. Scorpio egbbs are not compiled for more than 8 processors. The number 8 is hard coded so even Jim never compiled for more than 8. No wonder you see orders of magnitudes decrease in speed, and may even hang, this pretty much explains it. I repeat No one ever compiled egbbdll for more than 8 processors Look in the code if you don't beleive me. Infact I know so because TCEC's Martin told me Scorpio can't run with 16 cores and I told him exactly that.

And I also looked in the cache and realized how good I implemented it! To begin with every single EGBB has its own cache that would only require locking when two threads probe KBNKB simultanesouly. Even with that a 16Mb cache is like 2000 entries which is fast.

You fail to realize that Houdini doesn't use egbbdll, it compiles the Scorpio code in the engine itself. The Scorpio code in Houdini works with up to 32 threads.

It must be gratifying for you to boast the efficiency of your own code, but your reply also shows that you've never actually used it with large number of threads probing simultaneously. I suggest that you start doing that, compare the performance to the Syzygy bases, and then we can continue the discussion.

Well where is your comparison results because i don't see them. Like I said before show me your data so that I can tell you your bugs last time. From the things you said about slowdown starting from 8 processors, it perfectly matches the fact that they are never compiled for more than 8 processors by anyone but now YOU of all people, which is hard to believe given your total lack of know how how you implemented them but ok, so post DATA now.