[Mono-dev] minimal mono embedding profile - hpc twist

[Rodrigo Kumpera]

On Wed, Oct 3, 2012 at 1:59 PM, sebastian <sebastian at palladiumconsulting.com
> wrote:

> We are investigating running mono to enable C# as a computing language in
> an HPC framework. There are many strategies for getting maximum speed out
> of a program, and one of them involves running a single process per CPU
> core and pinning it there. (There are reasons this is good and bad -- I
> don't want to debate that at the moment.)
>
> In this case we would want the mono we loaded to be as "small" as possible
> in some sense that is probably different than "small" means on a mobile
> device. We are happy to consume tons of memory if necessary, but would want
> as few threads as possible. If possible, only 1, with the garbage collector
> "stopping the world" if necessary. Are there switches or diagnostics to
> understand or control this behavior? (Obviously some common programming
> paradigms, such as the task pool, are discouraged in this scenario, as we
> wouldn't want a thread pool spun up.)
>

Mono only uses one extra thread for finalization. Making all code that runs
on the finalizer thread happen on the main thread would be challenging.



> To get even more exotic, and I suppose this would require a patch to mono
> itself, we would want the memory allocation to be customized to take
> advantage of the NUMA on the machine, allocating memory only which is
> advantageous to the socket on which our current process is running.
>

Can't a numactl wrapper do all of this?

Finally, we may want to tweak the parameters sent to the LLVM compiler to
> optimize for runtime speed, even at the cost of very slow compilation.
>

Tweaking llvm parameters require changing mono's source code and pretty
much voids any guarantees that the resulting code will work.
A lot of LLVM optimizations for some reasons produce bad code when used
with mono. Zoltan can better explain this, I guess.


Where do we start in understanding the above changes and whether they are
> already supported? The documentation for LLVM and the garbage collectors is
> excellent at describing the high level approach, but I am at a bit of a
> loss when understanding how to tweak the details.
>

For such a thing, you need to dig into the runtime source code as those
internals are not documented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20121003/762c925f/attachment.html>