Native -> Managed?


Today, I was asked for performance data comparing between C++ and C#.  The reason they ask is the same one I’ve seen people ask for before: they’re trying to convince someone up their management chain that moving to managed code is the right thing to do.  The problem is that this has never been an easy question to answer, at least, not in a way that gives the person asking exactly what they were looking for: hard data proving the move is the right thing to do. 


The truth is that over time, I’ve seen many folks ask this question, end up going with managed code, and never really come back and mentioning anything about performance problems but instead talking about their productivity gains as a result of the move.  This is always good to see but it’s not the kind of thing that helps the folks who haven’t made the jump and won’t until their management is convinced it’s the right thing to do. 


Of course, there are definitely areas where you want to stay in the world of native code.  The next killer 3d game is highly unlikely to be written in managed code (though it probably wouldn’t be all that bad) but I bet a lot of the tools used to make it could all be managed apps.  I’m seeing less and less projects that aren’t suited for the managed world and definitely less than I originally thought I was going to see back when .NET was just getting started. 


Is this something you have encountered over time?  How would you help someone asking this question?  I’d love to hear your thoughts… 

Comments (4)

  1. Folds from dbAnalytics ( http://www.dnanalytics.net/ ) would be really interrested in this kind of discussion.

    They already started a thread here ( http://blog.dotnetwiki.org/archive/2004/06/28/579.aspx )

    Cheers,Jonathan

  2. jaybaz [MS] says:

    For most software, performance of the runtime & language isn’t the right thing to look at, but it is something we focus on. Perhaps because it’s so obvious how to measure it.

    Programmer productivity & bug creation/fix rates are probably much more valuable measures.

    The problem, obviously, is that only a small fraction of the code you produce can have any impact on the performance of the application.

    Accepting reduced productivity for the 99% of your application that isn’t perf-sensitive is the wrong choice.

    Write clean, clear, correct code, and getting good perf will be easy.

  3. Hy Jay,

    What you say is totally for most cases but numerical computation is a special case for that.

    In numerical computation, performance is a one of the major objective of the code (along with robustness, etc…) and it is crucial to take into account when designing the code.

    I am not talking about microoptimization like loop unrolling but rather choices like: managed or unmanaged or native, single dimension array or multi dimension array.

    More specifically in numerical algebra, those choice are critical.

  4. I agree with Jonathan that numerical programming is a special case. In my opinion, piggybacking on the robust, high-performance implementations of LAPACK like MKL just makes sense. We’ve written all of our high-level code in C# because it’s such an attractive language for programming. The memory is allocated on the managed heap, the pointers are pinned and then the calls are made to native libraries. The performance is good yet the advantages of .NET are preserved. More at http://www.centerspace.net/products.php?page=0&sub=1