Testing against Fruit makes little sense at this stage. Better use some engines around 2200 Elo as the next milestone.
Note that Fairy-Max is single core, and does not ponder. With a bug-free search and a reasonable evaluation a single-core engine should be able to convingly beat it.
Yes there must be some other issue. But fairymax (1.2Mnps) is also nearly twice as fast as Weini (700Knps) on my hardware, so pondering just equilize in fact I think.
Well, part of the reason it is so fast is that it counts nodes in an unusual way, namely inside its IID loop. And even in a QS node it goes through that loop twice, first to find the 'best' MVV/LVA move, and then to actually search the captures starting with that best move. Correcting for that would bring the speed down to below 600Knps.
The other reason is that it is fast is that it has no evaluation (other than what it does incrementally, and which thus doesn't take measurable time). And it is a bit unfair to count the slowdown you get from spending time on evaluation as a speed disadvantage. It would mean the evaluation doesn't even make up in strength for the time it uses, and is thus more a waste of time than anything else.
ok, I get your point but surprisingly, when I profile Weini, the evaluation is not that much the bottleneck. Movegenerator and threat detection is taking a lot of time (together with filling and sorting moves).
My code for move generatiion (pseudo legal move) is quite classic. What seems to take time is to validate move is not illegal (puts own king in check) during search (GetThreadsHelperFast). For moves management, I've tried using a memorypool or a fixed size container, but I found nothing faster than vector or dequeue.
Still looking for improvement here. I suspect the code is globally to complex and not flat enough.
You might wonder whether it pays at all to check if moves are legal. Fairy-Max doesn't do that at all. Most moves are legal, and on those the check will be a waste of time. On the occasional illegal move, the reply node will find it can capture the King, and simply return a +INF score for that.
When you are in check, you know beforehand that most moves will leave you in check, and then it might pay to explicitly test them for resolving the check, before recursing. But better yet would be to selectively generate moves that resolve the existing check.
That malloc/free stuff looks suspicious. It's not only those 10% CPU time, but spraying objects throughout the heap also will trash the CPU cache and slow down the rest of the program. I'd consider getting rid of dynamic memory allocation, except for the hashtables (they won't fit otherwise).
But trying to do so, I need a container of fixed size for move generation. It appears that in Weini, if moves container is of size 64, the engine is faster than using vectors BUT of course 64 moves is not enough ... if the container if 128 moves sizes, speed is the same than with vector BUT in some case 128 moves is not enough. Using bigger size even around 150 or 160 is slow than with vector. And I found that in a lazy SMP implementation things become harder with this kind of fixed size containers...
Another malloc/free stuff I tried to optimize is the position copy/make or make/unmake thing. I was never able to make make/unmake work fine with nullmove and en-passant (some programming errors) but I try to use a memory pool for position copy. Here again, the memory pool is just as efficient as the standard implementation.
So I stuck here, without ideas on the malloc/free thing that indeed seems to cost a lot...
