Why not use unmanaged safe code in C#

There is an option in C# to execute code unchecked. It’s generally not advised to do so, as managed code is much safer and it overcomes a lot of problems.

However I am wondering, if you’re sure your code won’t cause errors,
and you know how to handle memory then why (if you like fast code) follow the general advice?

I am wondering this since I wrote a program for a video camera, which required some extremely fast bitmap manipulation. I made some fast graphical algorithms myself, and they work excellent on the bitmaps using unmanaged code.

Now I wonder in general, if you’re sure you don’t have memory leaks, or risks of crashes, why not use unmanaged code more often?

PS my background: I kinda rolled into this programming world and I work alone (I do so for a few years) and so I hope this software design question isn’t that strange. I don’t really have other people out there like a teacher to ask such things.

Well, it’s mostly a case of the age old adage

Don’t optimize
(for experts only) Don’t optimize yet

But actually I can think of three main reason to avoid unsafe code.

Bugs:
The critical part of your question is “if you’re sure your code won’t cause errors”. Well, how can you be absolutely totally sure? Did you use a prover with formal method that guaranteed your code correct? One thing is certain in programming, and that is that you will have bugs. When you take off a safety, you allow new sort of bugs to creep trough. When you let the garbage collector take care of the memory for you, a lot of problem go away.
Not always as fast as you think: The other point is : depending on the problem, the gain may not be that great. Although I can’t seem to find them right now, I remember a study by Google comparing the speed of Java, Scala, Go and C++. Once optimized to the ground, of course C++ was much faster. But the algorithm programmed in the “idiomatic” way were not really that much faster. Idiomatic in the sense that they were using standard structure and idioms (stl container, no unrolled loop, etc). Microsoft did a similar experiment with C# and C++. Raymond Chen, one of the top Microsoft Engineer, had to write his own implementation of std::string to beat C#. (see: http://www.codinghorror.com/blog/2005/05/on-managed-code-performance-again.html) For much less effort, you got pretty decent performance in managed code, so its often not worth the trouble.
Reusability: Unsafe code can only be used in a full trust environment. For example, in an ASP.NET server, you usually can’t use unsafe code, since it would be pretty easy to introduce a vulnerability by buffer overflow. Another example would be clickonce. Or if your application was accessed from a network share. So if you plan to use your code in a variety of deployment scenario, unsafe code is out of the game.

So basically : its frowned upon because it may introduce unnecessary bugs, it may well be for no gain at all, and it reduce the reusability of your code.

But if your scenario really require it for performance (and you have data to prove it), you are an experienced programmer that know how to handle memory and your code will be used in a controlled environment, then sure, go for it.

In a way, unmanaged code is a form of payment: you buy faster execution with the extra development effort. Indeed, the unmanaged code requires more time to develop, to debug, and to maintain. Getting it exactly right is a challenge for most participants. In a way, this is similar to programming in assembly: sure, you can squeeze more power out of your CPU if you write in assembly^*, but you “spend” a lot more effort going that route.

Sometimes, the difference in development time is very significant – days instead of hours. However, the difference in execution speed is not nearly as dramatic. That is why the development of unmanaged code is reserved for situations similar to the one that you described in your post – localized, self-contained, implementations of resource-hungry algorithms, such as audio and video processing.

Essentially, the answer to your question is similar to the answer of why doesn’t everyone drive Ferrari: it’s a much better car, right? (Un)fortunately, not everyone can afford it.

^* The advancements of the past few decades in the optimization technology in compilers have narrowed down this gap so much that it is no longer a sure bet, though.

Because being “sure” about correctness or any other constraint in the mathematical sense (i.e. you have proof) is a very hard problem for imperative languages. Programs often have a such high number of states that it’s not possible to verify them even with checking each possible state. And creating a constructive proof is not something you can automate.

So the reason is that the insurances that managed execution provides most often over-weigh the small performance gain that you would get with unsafe code. Of course, this depends on the specific use-case, too.

In short, nothing prevents you in doing all that work and managing bits and bolts of your program in C++ environment. As you are pretty sure that you can correctly manage all the memory hoops and leaks without garbage collector then you are welcome to do that in C++ 🙂

In contrary, C# has advantages providing safe/managed and strongly-typed development environment to run safely in .NET framework.

The possible back-draw of programming un-managed code is the longer development time, allocation of time for detailed testing. You will of course gain processing speed and more control over how your software is running.

Thus, the option to work with un-managed code in .NET Framework starting from 4.0 is an option for edge cases when you sure that it might bring you gains over not using it…

Filed under: softwareengineering - @ 14:55

Thẻ: c++, memory-usage, performance

Thiết kế website giá rẻ

Danh mục

Why not use unmanaged safe code in C#