TalkChess.com

Maybe a good initial measurement is to check what the standard benchmark test (hash 128, 1 cpu, search depth 12) returns regarding nps. I'm also working on a 100% safe code and portable (SL, WP7) C# version of Stockfish for 3 months already (second half of the time optimizing it) - the portability will have some differences regarding signaling constructs and some minor areas. I'm getting on my i5 laptop 1080 kps for the original non-SSE gcc version (by running stockfish-222-64-ja.exe bench) and 450 kps for the C# version. In 4CPU mode the ratio is around 1:3 regarding speed when playing. Nothing major is changed principally, but for some of the problems I tried to find answers that are more natural and powerful in .Net - I think started off with just around 160 kps when finishing the raw porting.
The task is really tough, especially the optimization for the 'analyze, optimize, throw it out of the window and start again' part. But some ideas actually work!

Good luck with the port and looking forward to hear your results!

Cheers, Balint

Hi there.

Thanks for the reply. The port is complete but dealing with performance issues. It very well may be that its as good as its going to get. I'm halting any further work for now so I can rethink my goals and objectives. If anything this was a learning experience but it certainly fell a bit short of my expectations.

By the way, how did you handle the pointer arithmetic and templates from SF when porting that stuff over to C#? Also, C++ inline methods are not always easy to reproduce in C#. Sure, you can put alot of code inline but some of the heavier methods, you will simply have to take the extra hit of calling those methods multiple times which I hate. Cant put everything inline ya know.

Anyways, Ill keep you posted if I ever start C# back up again. I'm a bit dissapointed but moving forward with other ideas.

Thanks,

Hi David,

I think there are no real news to tell:
Pointers - really depends what the nature of that pointer actually is. One could always declare an integer index next to the array and pass it all around, in case there was a pointer passed to a function which was pointing to a middle of an array.
Templates - every template instance was moved into one function, and if/switch applied as C# generics does not support value dependent templating.
Inlining - now that's a tricky question, as there is no explicit inlining possibility - well there is in 4.5 desktop, but this is still beta: [url]http://msdn.microsoft.com/en-us/library ... 10%29.aspx[/url]. But in .Net the concept is just the opposite: the smaller methods are inlined by the JIT and not the compiler - now that depends on which JIT we actually talk about. Silverlight's JIT is somewhat simpler, I have no knowledge on the what MS guys did for WP7. This area is something one should not worry about much, as the JIT does a good job generally. I also did not like much how it looked first - but maintainability is also an aspect.

Cheers, Balint

Hey,

Thanks for the reply. Yeah, the way we did the pointers was to have this generic class for the different types, and then used implicit operators to get the different functionality. For example, if variable "st" is a pointer declared as Pointer<Stack> then we can do things like:

ss++ or ~ss, what have ya. A really slick way to mimick pointers but this does have some over head. The implicit operator were used so we could loop on the types but regular operators were used for the actual pointer functionality.

Anyways, thanks for sharing.

David

For sure that's a slick idea

Balint

diep wrote:Realistically an optimized beancounter doing what you wrote at 4.6Ghz is gonna get nearly 10 mln nps or so.

Apologies for the delay in my reply - too much work on at the moment.

To test your theory, I ran Houdini 2.0c on 3 positions with a 1 MB hash table, single core, and a fixed depth of 15. The use of a fixed depth setting prevents QS slowing the Houdini search, given that Amaia doesn't use QS yet. Then I used the same positions and settings for Amaia. I used Arena 3.0 as the GUI.

Houdini almost certainly has a considerably more sophisticated evaluation function, thus slowing down its search. In return, Amaia has no TT yet, which slows down its search. And also Amaia is relatively unoptimised - I've only spent a grand total of 80 hours working on it from scratch.

The result of this experiment is that Houdini searched between 3.8M and 5.6M nps. Amaia searched between 3.5M and 4.2M nps. Nowhere do I see your "factor of 4", so I don't know where that comes from.

RoadWarrior wrote:To test your theory, I ran Houdini 2.0c on 3 positions with a 1 MB hash table, single core, and a fixed depth of 15. The use of a fixed depth setting prevents QS slowing the Houdini search, given that Amaia doesn't use QS yet. Then I used the same positions and settings for Amaia. I used Arena 3.0 as the GUI.

The use of fixed depth almost certainly does not stop Houdini from using it's QS. It's not open source, so I can't be 100% sure, but everything else runs the main search up to depth 15, and QS is counted as "negative" depth. Also, Houdini is doing a lot of work during the search itself to prune positions, which has a big effect on NPS.

gladius wrote:The use of fixed depth almost certainly does not stop Houdini from using it's QS. It's not open source, so I can't be 100% sure, but everything else runs the main search up to depth 15, and QS is counted as "negative" depth.

If fixed depth doesn't prevent the use of Houdini's QS, then that should be taken into account when doing the comparison. On the other hand Amaia is slowed dramatically by not having a main or pawn TT, and only having minimal optimisation. In fact Amaia's optimisation was only based on perft performance, which may even have had a negative effect on the real search.

gladius wrote:Also, Houdini is doing a lot of work during the search itself to prune positions, which has a big effect on NPS.

Amaia also does null-move and other pruning, although obviously I have no way to compare the 2 programs directly. It's likely that Houdini is considerably more sophisticated in this respect.

Clearly this is a very limited experiment. And NPS probably has only a limited correlation with engine strength. My current goal with Amaia is to have the strongest C#/Java engine, a title I think is held by CuckooChess at 2682 Elo. The Elo 3000+ engines are beyond reach given my development skill and available time (3 young children and a demanding job in banking technology).

Interesting - Peter Österlund has just released a C++ implementation of his strong (Elo 2682) Java engine CuckooChess. He says that it's about twice as fast as the Java version: http://talkchess.com/forum/viewtopic.php?t=42999

From experience, C# runs faster than Java. So any claim of a C/C# slowdown in excess of a factor of 2 needs some pretty strong evidence before I'm going to believe it.

Mark, what Mps do you get for perft in Amaia? Wondering what could that be in you get 4 Mps on a single core for searching...

Cheers, Balint