TalkChess.com

I made the map update for non-captures now also incremental. For that I had to add a new routine for collecting the attacks on a hitherto unoccupied square, and then blocking all slider attacks that it catches. (I.e. remove those from the attackers sets of the downstream pieces they were originally ...

I moved the stuff to Linux, so I could do profiling to see where the time goes. (Un Cygwin profiling never worked for me: it always lists all functions as using 0% of the time!) This gave the following list: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ...

Although I haven't been able to exploit this yet to achieve further speedup, I want to dwell on this some more. Because I have the feeling I am really on to something. Moving the code for finding the MVV to the parent node / makemove was originally inspired by the wish to avoid the expensive attack-...

Well, there is a wisdom known as the "maximum flexibility, minimum usefulness principle". MaxQi was a sort of half-hearted attempt to make the (source-code-wise) smallest Xiangqi engine, just as micro-Max was an attempt to make the engine with the best Elo/sorce-size ratio. And since I already had F...

Janggi and Xiangqi are fairly unique amongst chess variants, by having location-dependent movement capability of its pieces. Zone confinement can be considered as a special case of this (where the pieces lose the moves that would leave the zone when they are next to a zone boundary). But in Xiangqi ...

I am still a bit in doubt here, on what to do when the pre-existing threat is no longer valid. We would have to keep searching for a victim amongst the remaining members of the 'worseThreats' victim set. One that is attacked after the move. Which is a different test than for finding a pre-existing t...

Finding the MVV The attack map makes it easy to see whether a piece is attacked, by just consulting its attackers[] element. But the capture generation still has to loop through the piece list top-down for finding pieces that are attacked. Some time could be saved by somehow skipping the test on pi...

OK, thanks. I will have a look at it. I have a version that runs in 4.40 sec now: 1 -16 372 0 e2a6 b4c3 b2c3 e6d5 2 -16 1314 0 e2a6 b4c3 b2c3 e6d5 3 -27 3126 0 e2a6 e6d5 g2h3 b4c3 d2c3 d5e4 4 -27 40932 0 e2a6 e6d5 g2h3 b4c3 d2c3 d5e4 5 -37 97493 0 e2a6 e6d5 c3d5 b6d5 e4d5 e7e5 6 -32 277881 0 e2a6 e6...

Well, perhaps it does, and this is just my ignorance. I never used any intrinsics before, so I would not know how to do it even on a compiler that supports them. My approach has always been to just hand-edit the assembler generated by the compiler. I am using gcc 3.4.4. It says (C) 2004.

Thanks for compiling. 13.5Mnps is pretty good, 1.7 times faster than my machine & compile. Was this a 64-bit compile? (Not that this should matter much, as I don't use any 64-bit variables other than the hash key.) Indeed I did mean "int bit = BSF(incoming);", and in the pseudo-code examples I poste...