Porting Engine from C++ to C# as a whole or only partially?

I would agree with jpetrie's theories in the last post. Avoiding the managed/unmanaged boundary whenever possible is the key to good performance, and it's likely that you'll cross this boundary less if you move as much as possible into C# and only call into native code when absolutely necessary, such as for DirectX or OpenGL API calls.

Of course, both Josh and I work on SlimDX, so take that with a grain of salt [grin]

I had something written out, but have confused myself.

I am actually curious as to what other may say.

Have you considered using C++/CLI as an interim?

Thanks for your suggestion. I might also do a complete port and when performance becomes an issue I'll investigate ways to either reduce native calls or move parts back to C++.

Currently I plan on using OpenTK (OpenGL) for my linux version, but I might still incorporate SlimDX into the Windows version [grin].

Although somewhat off-topic again, maybe you could help me: I'm looking for a CG bind to C#, in order to make including DX later easier (shaders don't have to be migrated). The only one I found was the Tao Framework which only supports CG 1.5 (not the current 2.0 or 2.1).

Quote:

Original post by evolutional Have you considered using C++/CLI as an interim?

You mean a C++/CLI library that forwards calls to OpenGL/DX? I'm not sure about OpenTK but what about SlimDX? How do you handle it?

C++/CLI doesn't get rid of the boundary, it only masks it and makes it easier to cross. You're still going to be incurring that performance penalty whenever you call from managed into unmanaged code, so you should know what you're doing because it isn't as obvious as P/Invoke from C#.

That said, C++/CLI is probably the better choice for interop if you're doing a lot of it. You'll probably see a slight performance boost, and your life will be much easier since you won't be P/Invoking every damn method and redefining every damn structure you need to get the job done.

Quote:

Original post by Lord_Evil Although somewhat off-topic again, maybe you could help me: I'm looking for a CG bind to C#, in order to make including DX later easier (shaders don't have to be migrated). The only one I found was the Tao Framework which only supports CG 1.5 (not the current 2.0 or 2.1).

On the Tao website it says it has support for 2.0. I've been using it.

Keep in mind that Mono cannot really handle C++/CLI. So if Linux/Mac support is important to you (as I imagine it would be if you're using GL to begin with), it's really not a good choice.

Quote:

Original post by Promit Keep in mind that Mono cannot really handle C++/CLI. So if Linux/Mac support is important to you (as I imagine it would be if you're using GL to begin with), it's really not a good choice.

So what would you recommend?

Let me put it this way. Managed<->Native calling overhead isn't really of much interest to you. It exists, it can hurt, but we're talking like maybe 10% of total call time per graphics call is overhead. For it to come into play, not only do you have to be CPU bottlenecked, but graphics calls have to be eating a significant amount of your CPU time to begin with. And if it's the case that half of your program's CPU time is spent calling GL/DX (which is rather unlikely in a game), then you stand to gain/lose 5% total based on that overhead. Maybe you'll lose another 5% to poor math performance, so that's a 10% total possible overhead, based on these largely made up numbers.

Is C# worth 10% to you? Are you currently CPU bound and running under 66 frames per second?

Quote:

Original post by Promit Is C# worth 10% to you? Are you currently CPU bound and running over 66 frames per second?

Let me say it with Tim Sweeny's words: "I'd gladly sacrifice 10% of our performance in order to gain 10% productivity." [smile] So yes, C# would be worth 10% to me.

So the OGL/DX bindings like OpenTK and SlimDX don't use C++/CLI, do they?

SlimDX is all C++/CLI, OpenTK is all C#. We enjoy different advantages and disadvantages as a result.

My general method, I think, would be to implement as much of what you need in C# as possible. Once you have it running, if there are things that are managed that are too slow because of too much managed->native interop, you could start pushing things past the divide (over to C++).

Chances are, you'll never hit that scenario, where the managed->native interop is causing you such performance drop that it'd be worth it to move things across to native land.

I think this falls into the category of "don't prematurely optimize."

Quote:

Original post by Drilian I think this falls into the category of "don't prematurely optimize."

True, but I wanted to clarify this before I start working on the port.

As I said earlier, I'll do a full port and continue developping in C# until I hit serious performance problems.

Thanks for making those things more clear to me.

Quote:

Since the native/unmanaged transition incurs some overhead, would you implement your renderer in C# (with overhead calling OpenGL and other native libs like PhysX) or keep those parts in C++ and implement the rest of the engine in C# (moving the transitions from low-level API <-> subsystems to engine <-> subystem)?

This is not a C++ vs C# question, you can mix them in the proportion you see fit, they are not mutually exclusive. I would [ab]use the dll's as much as I could (within sane limits)

[Edited by - Calin on March 13, 2009 1:08:44 AM]