Mark, i was getting that 3 mln nps already at an oldie K7, a total inferior processor, and that was INCLUDING a qsearch, and from Diep i had cut'n pasted a few routines for eval, not too much of course yet sure it worked; qsearch of course slows you down BIGTIME.RoadWarrior wrote:My fledgling and relatively unoptimised C# engine Amaia is searching 3.8M nps on a single core. That's using 64-bit Windows on an i7 2600K over-clocked to 4.6 GHz. It may not be a speed demon, but that number meets my current performance budget quite comfortably. At some point I'll run SF on this hardware/software so that I can do a comparison.diep wrote:p.s. some years ago when we compared some algorithmic code in C versus C#, then C# was factor 4 slower, so anything you get it faster than that here, is a big achievement, besides the huge work of porting SF to C#.
The evaluation function includes material, mobility, PSTs, pawn structures, and king safety. There is no SMP or TT yet, and also no QS or extensions - all work in progress.
I haven't looked at the assembly code produced by the JIT compiler yet. When I do, I suspect that I'll find a few decent performance improvements.
Also inside the qsearch, which determines at beancounters the speed so much, it was using diep's way of knowing when to capture or not, which obviously is a routine not optimized for speed that much.
Realistically an optimized beancounter doing what you wrote at 4.6Ghz is gonna get nearly 10 mln nps or so.
Now one thing no one can speedup and that's branches of course.
Yet 500 cycles per node, realize Schach 3.0 already was 600 cycles per node at an oldie pentium...
Sure, that was in assembler...
Vincent