Page 1 of 1

DGK and .NET (restored)

Posted: Fri Jun 28, 2024 2:01 am
by Nick
Hello friends

I have decided to repost the thread below. It is somewhat outdated, but the main point that computationally heavy software should not be implemented in .NET is still valid.

Regards
Nick

Re: DGK and .NET (restored)

Posted: Fri Jun 28, 2024 2:03 am
by Nick
This post is related to <a lost thread>.

A natural question appears in this regard: Why not rewrite entire KernelCAD as a .NET component? It would make whole software self contained and will be more secure pure .NET component for the developer’s application

Despite this is what some of our colleagues are doing I am positive this is would be a bad idea. Do not get me wrong. I love C#. It has limitations though and it has its target audience. CAD kernels is the main type of software which should NOT be written in .NET

.NET is an end user framework. It makes everything simple, fool proof, high level, productive for the developer. There are costs though. The main one is performance. There are lots of redundant checks and runtime processing going on under the hood in .NET, starting with the fact that it is only partially compiles. So it is a half scripting language

This is particularly important and sometimes critical in CAD applications. Heavy geometric computations with huge sets of data appear in CAD all the time. Surprisingly, multithreading does not significantly help with that. I hope to write about that in another post
Another one is memory consumption. Although memory is plentiful these days, this still has effect. Modern 3D scanners produce very fine meshes and whatever memory is available is consumed very quickly

New faster computers and huge amount of memory definitely help, but, again these resources are very quickly consumed by developers doing work which was not possible before. And it still is not enough. Imagine that an average new computer cannot load complete model of a small house with all the details. Simplifications are always necessary. Full model with even modest precision would have terabytes in size

So, even with pure .NET control interface for developers, we intend to keep core of KernelCAD as C++ components. Another reason is that, no matter how much a company can do - there are lots of very useful components to be consumed. They all are C++ dlls because it is the industry standard