This is a request to fix, I hope fixable, issue with multi-threading before 1.0.
I have a multi-threaded twinprimes sieve that I’ve done now in Nim, Rust, D, and Crystal.
The Crystal implementation is the slowest, but that’s not the immediate issue of concern.
Each thread does an independent process of the sieve.
The issue with Crystal is it doesn’t release the memory used by each thread, so as each
thread’s process runs, you see memory usage (via htop, etc) steadily increase until the sieve
finishes, then the active memory use drops back to the initial amount.
For all the other language implementations the memory use hits some constant amounts
which doesn’t deviate much over the entire process.
This problem severely restricts the input size for the sieve because the larger the range values the higher the memory use, until it eats up all the usable memory and hangs the system (if I don’t abort first).
I don’t know if this is a garbage collector issue, and/or some other structural problem.
I think it would be good to fix this issue before 1.0 to at least present Crystal as a viable
language for performing multi-thread applications, regarding memory use too.
I am sure this also affects speed, because it overflows the systems cache causing Crystal
to be substantially slower (almost twice as slow to Rust depending on input size).
So fixing the memory leak issues will probably have a significant benefit on performance too.
Thanks for your consideration.