SV: [vtkusers] c# port of VTK

[Andy Somogyi]

Lars Overgaard wrote:

 > Rather, my point is that C# is special - a beauty, and a real beast!
 > .Net and managed code introduce a HUGE overhead on function calls and
 > data referencing - and automatic garbage collection, not to mention.


Actually, when c# first came out, I was sceptical, very sceptical, so I wrote
TONS of benchmarks comparing c# and c++. Turns out that function calls
(to other .net functions) are actually faster in c# than in c++. Calling a
an external c function from c# is about .01% slower in c# than c++. Memory
allocations are much faster in c# than c++ because an alloc simply moves the stack
pointer down, then at a latter time, the garbage collector re-compacts the
the global heap.

The overhead of a 'managed' class is 12 bytes higher in c# than in c++. Thats why
value types (or structs) are much better when TONS of objects are involved.

Array access in certain cases is about 1% slower in c# because of array boundry
checks, although in loop, if the loop index value is compared against the array
'Length' value, array index checks are eliminated.

I ported a large n-body simulation from C to c#, run time took several hours, and
the c# version was about 1% slower, in total run time of hours, the time difference
was measured often less than a minute.

There is a MASSIVE performance hit in c# however, that is when a native or C modules
calls a callback function in a c# module. for example, using the C run time 'qsort'
function from c# is about 30 times than calling it from c or c++. This is because a callback
is registered with the qsort function, and c code in qsort needs to call back on this
function. As a refference, calling something like 'memcpy' from c# is identical to calling
it from C in terms of performance.

 > C# port/wrap/what-ever that does not take this into account could end up
 > with a computational performance that is a fraction of what was
 > expected. In case of frequent C#->vtk interface calls, it could mean not
 > just lost microseconds but rather lost hours.


This depends on what type of 'wrapper' is used. A script style wrapper, like that
used for python or tcl, where vtk clases are only called or used 'as is' and not
extended would result in a very minimal performance hit. Vtk however is a library
that is really designed to be used by 'extending' classes, overriding virtuals, and
in this case, the performance of a wrapper that involved virtuals would be
absulutly abysmal. Not to mention, writting this kind of a wrapper might be more
dificult than than porting the whole library.

 >
 > A vtk wrapper is much easier to maintain than a port, no doubt. On the
 > other hand, wrapping reduces performance. It's a classical choice
 > between maintenance and performance. Usually, the performance cost of a
 > wrapper is quite small, and a wrapper is the obvious choice.
 >
 > In case of C#, the huge .Net overhead makes the choice less obvious.
 >
 > Best regards,
 > - Lars
 >
 >
 >
 >>>> It's relatively easy to create wrappers for vtk and the overhead is minimal in calling them. A lost microsecond when processing hundreds
 >
 >
 >
 >>>> of MB of data is not worth saving.
 >
 >
 >
 >
 >>> In general, wrappers have advantages, no doubt about that. But C# is no just yet another programming language - a lot of things go with .net. I wonder if this comment comes out of real experience 
with C# and managed C++/C wrapping? I think that the overhead can actually become quite substantial. Great care must be taken to obtain an efficient C#-based VTK.
 >
 >
 >
 >>   I cannot speak for John, but I never took him to be referring to C#. Rather, he references the considerable experience of himself and others in using VTK via one of its current wrappers (Java, 
Python, and
 >
 >
 >
 >> Tcl). His comment is pretty solid and should be applicable.
 >
 >
 >
 >