# The Future Of .NET performance...

This topic is 5404 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi. I am writing a chess program. I have finished it in terms of all moves, check, etc, as well as move generation using alpha beta. I want to improve it by first off using a bitboard, and also implementing a transposition table after that. I am doing it in C++ using Win32 right now. If I move it to .NET, Managed C++, how much performance will I lose? I am thinking of this simply because .NET will be supported fully on future MS OS's, and it will continue to pick up speed gains. I think I will be able to implement my stuff faster. I need to have it play pretty good by March, cuz I have a \$10 bet with my avid chess playing friend that my program can beat him. Also, if I have a 64 bit integer, how do I check whether say pieces[43] is 1 or 0? Also, I don't have an amd 64 bit processor, so how much performance for bit boards do I lose? Thanx!

##### Share on other sites
I can't figure out how to use 64 bit integers. Sorry, but I have always just used int. I know .NET has nice support for 64 bit integers, but I am concerned that it is slow. On the other hand, I can build nice gui's really fast using .net

##### Share on other sites
The chances of .net being your bottleneck are pretty close to zero.

When you know the difference between different types of variables, then you can start worrying about things like optimization.

##### Share on other sites
Quote:
 Original post by Anonymous PosterThe chances of .net being your bottleneck are pretty close to zero.When you know the difference between different types of variables, then you can start worrying about things like optimization.

I know the basics. I am not stupid enough to post on this forum with out checking out google. However, there isn't a lot of information on personal experiances for optimization. And yes, I do know that .Net does have a large performance difference. I simply wanted to know how much.

##### Share on other sites

>And yes, I do know that .Net does have a large performance
>difference. I simply wanted to know how much.

I am afraid I have to correct you. The .NET Framework does not have a large performance difference, in fact, if used properly, it can outperform Win32 native applications, because of the way the allocations are done, for example. But you must understand .NET garbage collection (pretty different to Java one, mainly because of the generational system) to be able to write fast and efficent code in this new platform.

Keep in mind this: You cannot forget the way the memory is handled just because the dirty work is being done for you; you can have serious performance problems if you don't research a little bit on this.

On the other hand, I have to agree with AP too: You are obviously lacking the very basic knowledge of types, are you really sure you are ready to start a chess problem? Maybe you shoud get used to the framework with easier examples first.

And again, repeat with me: .NET code isn't slow. Good .NET code is FAST! ;)

##### Share on other sites
It's not a huge difference. I don't know the exact stats, but I don't think managed C++ will bring about more than a 10% loss in performance, and likely not even that. The only things that would make it any slower are really the .NET code (GUI, etc.) and that's not very likely and the garbage collection. Garbage collection occurs periodically, not constantly, so you might experience an occasional short lag depending on how often you leave behind data to be collected. That said, the VC++.NET compiler optimizes better than the VC++6 compiler. I can't compare with anything else, since I don't really know the stats on that.

Your algorithms are several orders of magnitude more important than the compiler. But I imagine you know that since you're trying for bitboards instead of arrays...

To find out if "pieces[43]" is 1 or 0, you would do a bitwise and (&) between your board and a 64-bit value that only has the 43rd bit set. While I'm sure there are better ways to do it, you could do something like this:

int64 compare = 1;location = 43;// This is assuming that you have position 1 in the leftmost// bit and position 64 in the rightmost bit// This part can be VERY heavily optimized and may contain an// off by one error...for (int i = 0; i < (63 - location); i ++)    compare = compare << 1;if ((pieces & compare) != 0)    // space is occupied (bit is 1)

You can speed up the computation of the comparison by having a const array of 64 int64s each containing the correct bitmask for each position of the board (ie: mask[0]=1, mask[1]=1<<1, mask[2]<<2). But make sure to keep in mind the endianness you have for your board variable.

-Auron

##### Share on other sites
Ok. First, I have already built the engine using arrays. I have a feeling that having a constant array isn't very efficient, though it is the only way I can think of. But doesn't that mean I would have to test each of the 64 squares? Ultimately, the .net question boils down to this: if I have an engine that uses pure C++, and it is called from .NET, how is performance effected? I will not be making more than one call across the border.

##### Share on other sites
Quote:
 I can't figure out how to use 64 bit integers.

The typename for a 64-bit integer in c++ is __int64.

##### Share on other sites
Quote:
Original post by Nemesis2k2
Quote:
 I can't figure out how to use 64 bit integers.

The typename for a 64-bit integer in c++ is __int64.

thanx.

I have a question. The Visual C++ .NET Express Beta uses .NET 2.0. DOes this mean that if my schools comps, which have .net 1.1, won't be able to use my program?

##### Share on other sites
Afraid so.

As for performance, the 64-bit type on non 64-bit systems wont be a noticable hit. And the garbage collect isn't a problem either if you handle your allocations properly. The big thing to be careful of is boxing. If you use Express be sure to use generics when it's appropriate as this helps avoid most situations where boxing is required.

• 21
• 13
• 9
• 17
• 13