Daniel Shawul wrote:Well that would be like the rybka like optimization that does delta-pruned captures while generating moves IIRC, or scoring while move generation etc... Very bad code for my style as I would like to keep it as simple as generating and storing the moves. Also my test which showed slow down by 3x even if I did the move generation in _both_ cases. That indicates move generation is not a problem at all but whether I check the results of all the positions or not ... That is why I want to calculate the cutoff statistics.
Well, if you don't care about speed of generation, then do whatever you want.
Storing the moves is absolutely unnecessary. You only use them once and you're not going to sort them or anything like that. Generation of destination squares is incredibly simple, certainly when using bitboards.
If you do care about efficieny, first thing you should do is realize a tablebase generator has almost nothing to do with a chess engine.
Daniel Shawul wrote:Well that would be like the rybka like optimization that does delta-pruned captures while generating moves IIRC, or scoring while move generation etc... Very bad code for my style as I would like to keep it as simple as generating and storing the moves. Also my test which showed slow down by 3x even if I did the move generation in _both_ cases. That indicates move generation is not a problem at all but whether I check the results of all the positions or not ... That is why I want to calculate the cutoff statistics.
Well, if you don't care about speed of generation, then do whatever you want.
Storing the moves is absolutely unnecessary. You only use them once and you're not going to sort them or anything like that. Generation of destination squares is incredibly simple, certainly when using bitboards.
If you do care about efficieny, first thing you should do is realize a tablebase generator has almost nothing to do with a chess engine.
Optimize where it is needed. Did you forget about the profile that said 2% is spent on move generation. Now if you speed move generation alone by 25% like you did what do I get. 0.02 x 25% = 0.5% . That is very few gain for a good work of speeding up generation by 25% . No thank you.
Also you don't understand my argument at all since in both cases I did move generation BUT it only slowed down by 3X when I didn't do the cutoff. Do you see the difference or are you always this hung up ?
Daniel Shawul wrote:Optimize where it is needed. Did you forget about the profile that said 2% is spent on move generation.
But your generator is not optimised for speed at all. I do move generation, index calculation and verification in a tight loop in a few lines of code.
Also you don't understand my argument at all since in both cases I did move generation BUT it only slowed down by 3X when I didn't do the cutoff. Do you see the difference or are you always this hung up ?
Daniel Shawul wrote:Optimize where it is needed. Did you forget about the profile that said 2% is spent on move generation.
But your generator is not optimised for speed at all. I do move generation, index calculation and verification in a tight loop in a few lines of code.
You are getting desperate now. My index calculation takes about 22% so that is my top priority if I want to get my tablebase generation faster. I bet my bottom dollar that your non-capture move generaiton is no faster any bitboard method you have. It is unrolled and does the 0x88 trick and pretty much plain ride for generating all moves and non-captures. Wonder why no one ever writes a fast perft with bitboard?? And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise. Even at that I am not at all opposed to optimizing it, I just got by priority. But if I tell you that I may need to speed up the move genetation here after I learn more than 90% are cutoffs, you go all patriotic on me saying see i told you The move generation part could be slower if I do something else while generating. It is not guaranted at all... and it is not the right time to think about it at all with the 2% and all.
Oh give me a break.
Sorry man but this time I really mean that you are hung up on a false notion. We can agree to disagree anyway.
Daniel Shawul wrote:And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise.
What can I say... I've tried both and the difference is very noticeable. But dream on.
Daniel Shawul wrote:And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise.
What can I say... I've tried both and the difference is very noticeable. But dream on.
What I can say your little revelation opposes experience of many people so better be prepared to answer for it.
Daniel Shawul wrote:And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise.
What can I say... I've tried both and the difference is very noticeable. But dream on.
What I can say your little revelation opposes experience of many people so better be prepared to answer for it.
Daniel Shawul wrote:And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise.
What can I say... I've tried both and the difference is very noticeable. But dream on.
What I can say your little revelation opposes experience of many people so better be prepared to answer for it.
Maybe you could first work on your attitude.
What are we doing now ?? discussing or trolling. You just keep throwing snarly comments because I pointed out your experience opposes other's. Would my attitude be better if I didn't say that ? Or is it that you feel the need to label someone who doesn't agree with you.
syzygy wrote:My generator generates and compresses all 3-4-5 piece WDL50+ and DTZ50+ tables in 2 hours 20 minutes on my laptop. Most of that time is spent on compression. Actual generation time is less than an hour (maybe 45 minutes or so). I have no numbers yet for 6 pieces.
On my laptop, time for generation plus collection of statistics is 38m43 to be precise.
Daniel Shawul wrote:And yet you are hung up on that ( i repeat ) because it seems you have this false belief that bitboards will be faster for non-caps when all expeience and intiuition says otherwise.
What can I say... I've tried both and the difference is very noticeable. But dream on.
What I can say your little revelation opposes experience of many people so better be prepared to answer for it.
Maybe you could first work on your attitude.
What are we doing now ?? discussing or trolling. You just keep throwing snarly comments because I pointed out your experience opposes other's. Would my attitude be better if I didn't say that ? Or is it that you feel the need to label someone who doesn't agree with you.
My generator is maybe 120 times faster than yours. I have provided reasons for this and I have explained to you how I do it. Whether you want to take my advice or not is up to you, but implying that I don't know what I am talking, well that's just not very productive.
The move generation part could be slower if I do something else while generating. It is not guaranted at all... and it is not the right time to think about it at all with the 2% and all.