Hrvoje Horvatic wrote:diep wrote:
Had you considered shipping me an e-mail?
I responded to 100% of everyone who emailed with a C file that has everything.
Vincent, thank you for offering your help, but I've managed to make my way through, no need for your help now...
Your stuff seems to work... I still have to iron out all the bugs and incosistencies, optimize *my* part of code, but it seems to me that you were right...
Did you notice that between what i posted here and what Stallman got at the time, that the latest incarnation that you do not have running yet, that this one is considerable faster?
I posted back in the 2000s a comparision between crafty's semi legal move generation speed and Diep's.
Diep was 2.2x faster.
This was at a 32 bits processor.
Crafty ran at 32 bits hardware online for a pretty long time.
You cannot compare processors from back then with todays processors.
I posted those results - so it's not like "i did do a claim unfunded",
as you are suggesting. Also it was with a crafty compile i didn't do myself. The fastest possible crafty compile at processors from back then.
Note that in terms of system time semi legal move generation is just a small percentage of the system time. I'm using it bigtime in evaluation though for all sorts of mobility loops where i use knowledge to scan. So not some sort of dumbo bitcount, as each square gets seperately evaluated with chess logics.
I disagree with another weird opinion you write here. What i do in my move generator is simple, effective and straightforward.
The weird thing is bitboards - most use inline assembler code to speedup or system functions from the compiler or inline intrinsics. To get the square you are at, you need to do some sort of weirdo Leadz later on called FirstOne then nowadays it's called LSB or whatever. Now *that* is a weird way of programming.
It's incompatible and in terms of speed comparision you're comparing simple straight forward C code of me and compare that with 64 bits assembler. Are you understanding fully what you compare?
Compatible C code with incompatible hard to read assembler. It's very difficult to use bitboards for a program with a huge evaluation function like Diep has.
Just see how much trouble some who post here have to implement just one simple pattern into bitboards. Takes them weeks to optimize just 1 small thing.
If you do that in a knowledge rich environment you're not making much of a progress.
So the programming model for knowledge has proven itself.
In short for upcoming robotics project i'm about to start here implementing knowledge i'll do in a similar manner like Diep. Bitboards are going to be impossible there (besides that of course all those cheap ARMs are 32 bits).
It's interesting to see how long Diep's move generating tables can withstand the test of time, whereas we have seen by now already 100 revisions in bitboards. And they keep busy with it - whereas you do NOT want to spend big time on move generation of course. It has to work fine in your own code and then it's nice if you can keep using it for another 20 years, which in software engineering is similar to a building that stands for 1000 years.
