Syzygy / egbb discussion

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Daniel Shawul
Posts: 3593
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Syzygy / egbb discussion

Post by Daniel Shawul » Wed Oct 23, 2013 10:59 am

Laskos wrote: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

User avatar
Laskos
Posts: 8965
Joined: Wed Jul 26, 2006 8:21 pm
Full name: Kai Laskos

Re: Syzygy endgame tables: Generation and first impressions

Post by Laskos » Wed Oct 23, 2013 1:03 pm

Daniel Shawul wrote:
Laskos wrote: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
Posts: 3593
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Daniel Shawul » Wed Oct 23, 2013 1:52 pm

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
Posts: 716
Joined: Thu Mar 09, 2006 12:21 am
Location: Portland Oregon

Re: Syzygy endgame tables: Generation and first impressions

Post by Ryan Benitez » Wed Oct 23, 2013 5:41 pm

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
Posts: 3593
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Daniel Shawul » Wed Oct 23, 2013 6:08 pm

Ryan Benitez wrote: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.

User avatar
Houdini
Posts: 1471
Joined: Mon Mar 15, 2010 11:00 pm
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Houdini » Wed Oct 23, 2013 9:52 pm

Ryan Benitez wrote: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

User avatar
Houdini
Posts: 1471
Joined: Mon Mar 15, 2010 11:00 pm
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Houdini » Wed Oct 23, 2013 10:06 pm

Daniel Shawul wrote: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
Posts: 3593
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Daniel Shawul » Wed Oct 23, 2013 10:20 pm

Houdini wrote:
Ryan Benitez wrote: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.

User avatar
Houdini
Posts: 1471
Joined: Mon Mar 15, 2010 11:00 pm
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Houdini » Wed Oct 23, 2013 10:43 pm

Daniel Shawul wrote: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
Posts: 3593
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Syzygy endgame tables: Generation and first impressions

Post by Daniel Shawul » Wed Oct 23, 2013 10:51 pm

Houdini wrote:
Daniel Shawul wrote: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.

Post Reply