[Mono-dev] minimal mono embedding profile - hpc twist
kumpera at gmail.com
Wed Oct 3 18:57:25 UTC 2012
On Wed, Oct 3, 2012 at 1:59 PM, sebastian <sebastian at palladiumconsulting.com
> 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...
More information about the Mono-devel-list