Stockfish port to C# Complete

[whittenizer]

I am happy to annouce that the conversion to C# with testing is complete. There could be some small bugs but I havent found any yet for the desktop version. My goal was to get this working on my WP7 phone but there are issues, lots of them. Slowness is number one, and second, in the id_loop method when we compare bestvalue to alpha, this comparison is way off compared to the desktop version. By the way, the desktop version is very very close to C++ performance. My counterpart did an amazing job with the conversion.

Now, for the WP7 version, we may have to totally gut the search and re-do it so it behaves like I want it to. Not sure how to approach it yet but I'll be sharing code at some point.

Thanks all.

[Jan Brouwer]

By the way, the desktop version is very very close to C++ performance. My counterpart did an amazing job with the conversion.

How close exactly?

[whittenizer]

Well, I tested it against Bobby Fischer's game of the century right before the infamous g4e6 move. I did a depth 10 search and C++ came back in like a second, C# 1.5 maybe. You might say, well thats 50%. It's not really that noticable in the UI. I'm happy with it. Just need to figure out how to get this WP7 to function properly.

[Jan Brouwer]

Well, I tested it against Bobby Fischer's game of the century right before the infamous g4e6 move. I did a depth 10 search and C++ came back in like a second, C# 1.5 maybe. You might say, well thats 50%. It's not really that noticable in the UI. I'm happy with it. Just need to figure out how to get this WP7 to function properly.

Indeed, 1.5 times slower is not too bad at all. I did some googling and it seems the main performance issue is the much larger memory footprint of C# applicationts versus C++.

[whittenizer]

Thats right. In this challenge there were alot of no direct translations so complete workarounds were needed. This was totally managed code too so mimicking pointer arithmetic and templates, and his solutions were absolutely ingenious.

Ill share code at some point but need ot figure out this WP7 thing. Driving me nuts.

Thanks.

[whittenizer]

Another crazy thing is the book.bin is working perfectly in WP7. Just need to wrap my head around the searching issues, and things will be cool.

Thanks

[whittenizer]

Alright. I've uncovered the performance culprit. We are using implicit operators so we can actually do loops on the types. Also, operators in general are hurting us too. The Pointer implementation is using these operators extensively.

I've fixed a few areas already using regular ints for the loops, and have seen usage drop down noticably. The desktop version is geting closer to C++ performance but needs some refactoring now.

I'll keep you all posted.

[diep]

Well, I tested it against Bobby Fischer's game of the century right before the infamous g4e6 move. I did a depth 10 search and C++ came back in like a second, C# 1.5 maybe. You might say, well thats 50%. It's not really that noticable in the UI. I'm happy with it. Just need to figure out how to get this WP7 to function properly.

Indeed, 1.5 times slower is not too bad at all. I did some googling and it seems the main performance issue is the much larger memory footprint of C# applicationts versus C++.

The way it gets reported smells after flawed measurement.

a) is it deterministic the same?
b) if you allocate say a 1GB hashtable and have it search for a few minutes
at a core or 6, what's the difference in nps then, if you repeat it a few times?

c) what is getting compared here? A gcc compiled SF with debug code and no optimization? A selfcompiled SF? If so how did it get compiled? Or an intel c++ compiled SF as you can download? Quite some speed difference between all those executables. Then compare that with the best available compiler you can find for C#.

d) 1 second outputs tell nothing, that's not not how you accurately measure of course, too big odds the measurement is flawed

e) there is a ton of testers posting in this group, can they also do the measurement, as you want to release the code anyway as i read?

f) did you use a 32 bits SF compile for the C/C++ ?

Probaby it'll go a ton over 50% diff at intel processors.

[diep]

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#. When i google a tad around it seems you were already busy doing that by januari 2011? Is that correct?

A huge project you know...

Until there is some objective testing of its speed, then i'll have in my book that factor 4 as the speed diff.

Regards,
Vincent

p.s.2. it was exactly factor 4

[whittenizer]

Yep, we started this just a few months ago. As for testing, I know the 1.5 times slower is not detailed enough. There's much more in depth testng I'll be doing but I need to fix the operators to get the perofrmance up where it needs to be. I mean its pretty darn fast now but I want it better. Also, there are some pre-loading of structures I want to try to get the search to go deeper in less time but that comes later. Not even sure if it will work.

Its going to take me a few weeks to refactor some of this c# as I dont have too much time on my hands. I'll keep you all posted. I will say that Ive made some improvements already simply doing loops using ints instead of the types. Thats why the operators were used. But theres some serious overhead there so Im removing the operators where I think they need to be removed, and going from there.

Thanks