3 ms·

is the speed hit (factor 2-5) really that bad? do haskell programmers have experience that confirms that? and would it be possible to somehow switch this on a

is the speed hit (factor 2-5) really that bad? do haskell programmers have experience that confirms that? and would it be possible to somehow switch this on and off dynamically, so that a single "pypy" can adapt automatically if multiple threads start? and how will this affect a stable, well supported [edit: full library], "final" release of pypy (especially, p3)? is it going to remove effort/resources from a GIL version? i get the impression it's getting close to stable/easy to use and it would be a pity to lose that. [edit: ps, otherwise, this sounds most excellent]

gwern 15y ago
> is the speed hit (factor 2-5) really that bad? do haskell programmers have experience that confirms that? The penalty was pretty bad in the earliest STMs, but the Simons have done so much work on multi-core stuff and the STM libraries that it's hard to say. (I will note that lack of purity might be, as the comments point out, a real problem. That was what sunk the .Net/C# folks trying to add STM.)
lucian1900 15y ago
PyPy is stable/easy to use for python2, with a limited selection of C extensions.
skew 15y ago
I'm not sure what that speed hit is supposed to be for. If it's about time taken on the synchronization operations themselves, I haven't found the benchmarks but I seem to recall STM being reasonably competitive (maybe 10%-50% slowdown) with locking implementations of fairly simple things like MVar or Chan. That's certainly much larger than the hit for running under GHC's threaded runtime. The original version described in "Haskell on a Shared-Memory Multiprocessor" shows a performance hit usually under 10% for sequential code. I expect it's only gotten better with tuning since then. (Of course, purity helps a lot. Re-evaluating a pure thunk produces the same result, so two threads entering the same code just costs performance rather than correctness, and it's usually enough to use simple reads and writes to narrow the window).

gwern 15y ago

> is the speed hit (factor 2-5) really that bad? do haskell programmers have experience that confirms that? The penalty was pretty bad in the earliest STMs, but the Simons have done so much work on multi-core stuff and the STM libraries that it's hard to say. (I will note that lack of purity might be, as the comments point out, a real problem. That was what sunk the .Net/C# folks trying to add STM.)

lucian1900 15y ago

PyPy is stable/easy to use for python2, with a limited selection of C extensions.

skew 15y ago

I'm not sure what that speed hit is supposed to be for. If it's about time taken on the synchronization operations themselves, I haven't found the benchmarks but I seem to recall STM being reasonably competitive (maybe 10%-50% slowdown) with locking implementations of fairly simple things like MVar or Chan. That's certainly much larger than the hit for running under GHC's threaded runtime. The original version described in "Haskell on a Shared-Memory Multiprocessor" shows a performance hit usually under 10% for sequential code. I expect it's only gotten better with tuning since then. (Of course, purity helps a lot. Re-evaluating a pure thunk produces the same result, so two threads entering the same code just costs performance rather than correctness, and it's usually enough to use simple reads and writes to narrow the window).