c# for chess engine

[stevemulligan]

Do you know your rgstat timing for 10k games is? I just spent weeks rewriting move generation in my c# engine to use a pseudolegal move generator and the most I can get is about 170 games per second. I'm using bitboards and piece-square arrays.

That's like 10 times slower than C engines so I'm not sure what I'm doing wrong...

[Don]

I've just spent a few days to write a simple engine on C#. I was surprised that it's not so slow as I presumed. Bitboard engine (base on de Bruijn numbers) with alpha/beta, w/o move ordering and with eval based on psq/material does 1 200 000 pos/sec. at my notebook (while SmarThink does about 450 knodes/sec). It looks promising, I hope completely rewritten engine will be not more that 10–15% slower than original.

C# and any of the java-like languages do not have to be particularly slow and they can approach the speed of C.

However I'm a bit skeptical that you can get away with doing this for chess without giving up a lot of speed. Is your program bit-board or mailbox?

The problem with high level languages for chess is that you need a lot of low level control. It's not clear to me how much of this you can get with C#. Maybe a lot more than I think but it's just not that clear to me. Maybe you can work around it without taking a hit, that's not clear to me either.

The nodes per second is a meaningless number to me without having a good sense of how you count nodes and how sophisticated the evaluation function is. Do you have an apples to apples comparison? For example is it (more or less) equivalent to your C program?

Anyway, keep up the good work. There are some advantage to high level languages in that you can develop more quickly and try new ideas more easily. We seem to be able to progress with ELO gains rapidly and it almost makes obsessing over a few percent speedup seem silly.

When we have released in the past what has usually happened is that we lose 2 or 3 weeks obsessing over how to get the fasted possible executable and which compiler to use, etc. By the time we were able to release we usually have a version using our standard dumb compile that is stronger than the one we obsessed over (despite the distractions.)

So our time is better spent working on the program rather than the compile and thus you may find your time is better spent writing a chess program in a high level language, especially if you can get without 20 or 30 percent of the same speed.

There is one caveat here. To have really fast code you have to work pretty hard to get the most out of the code. It's been my experience that trying to wring the most speed out of high level languages is not a natural thing to do. They are designed to be easy to program and easy to read and work with and heroic optimization's seem to work against this principle and make you wonder why you didn't just write it in C.

[rbarreira]

Do you know your rgstat timing for 10k games is? I just spent weeks rewriting move generation in my c# engine to use a pseudolegal move generator and the most I can get is about 170 games per second. I'm using bitboards and piece-square arrays.

That's like 10 times slower than C engines so I'm not sure what I'm doing wrong...

One aspect where C# and Java are usually much slower than C is program startup. I'm not sure what you're measuring in those benchmarks, but if it involves starting the engine for each game that could explain it.

Personally I would avoid C# for the simple reason that it's not a portable language... And I would avoid Java because I don't like it.

I consider C or a sane subset of C++ to be a good compromise, they're efficient and quite portable languages which still provide enough high level syntax to make programming much simpler than using Assembly directly:

- variables and scoping
- flow control
- functions and recursion
- arrays and structs

For a not so big/abstract program such as a chess engine, those features are everything you need to program without headaches. You can be more fancy and use other features of C++, C# or whatever, but their benefit is negligible compared to the four above.

PS: By portable, I mean that the ubiquity of C/C++ guarantees that you'll for sure be able to easily port your engine to whatever computer is fashionable tomorrow... A new computer architecture or operating system without a C/C++ compiler is pretty much dead on arrival.

[Sergei S. Markoff]

Do you know your rgstat timing for 10k games is? I just spent weeks rewriting move generation in my c# engine to use a pseudolegal move generator and the most I can get is about 170 games per second. I'm using bitboards and piece-square arrays.

That's like 10 times slower than C engines so I'm not sure what I'm doing wrong...

I think you shold use profiler to find the major slowdowns. Don't forget to turn on optimization in project settings, choose Release target, remove DEBUG/TRACE, use unchecked {} everywhere it's possible and finally run your engine _not_ under IDE.

[stevemulligan]

I think you shold use profiler to find the major slowdowns. Don't forget to turn on optimization in project settings, choose Release target, remove DEBUG/TRACE, use unchecked {} everywhere it's possible and finally run your engine _not_ under IDE.

Thank you for the tips. All of them together do speed things up quite a bit. I can get over 200 rg/sec with unchecked & no debugger attached. (rg is random games, See Stephen Edwards posts from this thread )

I'm guessing that c/c++ can play 1000 rg/sec right now. I hope others will implement it so I can compare so I know for sure if my move generator is way too slow or if I should leave it alone.

I'm using ANTS profiler right now and it tells me almost all my time is spent building the list of pseudo-legal moves.


Are your valid moves cached? Mine are computed each time. Can I store these in a "always-replace" TT?


Also - Do you use EGTB? 5 Man Gaviota EGTB probing code is available here https://code.google.com/p/gaviota-probe-dotnet/

[UncombedCoconut]

Personally I would avoid C# for the simple reason that it's not a portable language... And I would avoid Java because I don't like it.

It should be OK as long as you stick to the subset that Mono understands (which for chess programmers' purposes is a very large subset). Sure, you'll lose some ability to predict your program's speed across platforms, but if you reach the point where your chess program can only be improved by raw speed optimizations you've already coded a @)(#*&$ monster...
Phones are a pretty serious exception to my point. If "it should work on all standard smartphones" is a requirement, your language choice is pretty much decided...