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.)<div>
<br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div><div><br></div>Sebastian
</div>