I have been pulling my hair out over a strange slow-down when using `spawn`. Things worked fine on Mac, but on Linux my multithreaded Nim program was _slower_ than my multiprocessing Python program.
Both Nim and Python versions are mostly C code, using the exact same C code in fact. When I run everything in the main thread of the a single process, Nim is a little faster than Python, probably because of start-up time. I added micro-second timing to the C code, so I am fairly confident that the slow-down for threaded code is in the actual C code, _not_ in Nim thread setup (deep-copying etc). The C function takes about 0.03s per call from Nim, single-process and main thread. It takes about the same from Python like that, as well as using the **multiprocessing** Python module. But as soon as I use Nim threads, the C code takes about .25s for each call. I tried compiling with `-O2` instead of `-O3` (which I think is smart anyway). No apparent difference. I also tried limiting the Nim threadpool to exactly 1 thread (by modifying `Nim/lib/pure/concurrency/threadpool.nim:setup()`). Again, no difference. My best guess for the slow-down is a [False Sharing](https://en.wikipedia.org/wiki/False_sharing), but I guess if someone really wants to dive into this bioinformatics example, I could try to provide a full test-case. I'm not sure that it's worth the effort. I think we might actually be better off with a Nim version of Python's **multiprocessing**. It solves so many problems. Does such a thing exist? Am I crazy to want this? Thoughts? For reference (nearly up-to-date): * Nim version: [https://github.com/cdunn2001/nim-consensus/blob/master/n.nim](https://github.com/cdunn2001/nim-consensus/blob/master/n.nim) * Py version: [https://github.com/PacificBiosciences/FALCON/blob/master/falcon_kit/mains/consensus.py](https://github.com/PacificBiosciences/FALCON/blob/master/falcon_kit/mains/consensus.py) * Red herring: [https://github.com/nim-lang/Nim/issues/5499](https://github.com/nim-lang/Nim/issues/5499)
