The main concern about .Net Application Development is that porting everything to manage code will result in significantly slower performance for the heavy computational nature of the rendering engine. You may not be concerned about the difficulty in *rewriting* the code, but you want your code to run as fast as possible and it is obvious to happen with the overhead involved in managed code.
 |
| .Net Application Development - Laitkor |
Porting an application to .Net environment
1. The prime concern is to check if the code runs just as fast as it does natively. You might have seen conflicting reports on the web. Any good side by side comparisons out there involving lots of floating point calculations.
2. You must know the best way to go if you want to port only the front end GUI, etc. to .Net, and keep the back end in native C / C++. You might have read about calling unmanaged DLLs from managed code or using C++ / CLI with _nogc tags, etc., but it may be that these methods are either too clunky to efficiently pass data back and forth and/or involve a lot of overhead as the processor switches back and forth between managed and unmanaged code.
3. Before porting, you must ensure if there is a standard manner of handling the issues. Well, it’s inelegant but you could simply have the GUI call the actual program through an intermediate file.
4. It is not certain to find the VM really causing lots of performance problems. Remember that all your code is compiled to native code before it is run and if you are running in a tight loop your first iteration may be slow while the JITer does its things, but your next iterations should be fast. You should do this because you might have learned a lot. If you think your code is slow, you’d learn about how to profile .Net apps and work from there.
5. It is hard to say without seeing you code, but .Net is a managed environment and platform calls go through an intermediary layer which adds a few ops. You can set it to link your rendering engine as a native DLL. Pass parameters and the scene to the DLL and get your image back. You can do this in an unsafe block in C#. There is a cost to marshaling but it seems like you could set things up to only pay it infrequently.
6. .Net is really designed with developer productivity and maintainability in mind. This comes at the cost of a few things which performance is one. Also, .NET application development is designed to call into legacy and native code easily, but crossing the managed / unmanaged boundary is fairly expensive. This shouldn’t be much of a problem if you are just feeding data from the GUI into the renderer and getting periodic status back, though. The biggest thing than using managed code is using the correct algorithms. Also, during heavy loops, avoid creating objects and quickly destroying them.
One of the larger problems with heavy computation work is that the runtime’s memory management is geared towards the safe end, i.e., keep everything in memory until there is no chance of needing it. It really all depends what the ultimate goal of the project is. If you ever seriously want to develop this, at some point you will be fighting C# more than liking it. C# is a wonderful language if you need to throw something up fast.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.