4 ms·

STM sounds all nice, yet there are few implementations of STM currently that give better performance than a good serial implementation.

exDM69 15y ago
I hope you have sources and/or benchmarks to support your claims. Bashing a promising future technology without any backing is not constructive.
- wynand 15y ago
  codedivine has a point and it's even admitted in this posting: "we expect the initial performance to be abysmally bad (maybe 10x slower); however, with successive improvements to the locking mechanism, to the global program transformation inserting the locks, to the garbage collector (GC), and to the Just-in-Time (JIT) compiler, we believe that it should be possible to get a roughly reasonable performance (up to maybe 2x slower)." It will likely be difficult to beat expertly written code using explicit locks. But most people aren't experts in concurrency and will either get it wrong or have slow implementations. And if transactional memory catches on, we may even see some hardware assistance in future CPUs. (S)TM is definitely worth exploring more and even a 2x slower implementation (as envisioned by the PyPy team) could cover most concurrency needs, which will make it a success in most people's eyes.
  - kbd 15y ago
    Do they mean 2x slower than CPython or 2x slower than PyPy? If they wind up with something 2x slower than current PyPy (which is much faster than CPython in many cases), that'll still be a version of Python much faster than CPython that doesn't have the limitations of the GIL and can thread across cores, and that'll be a huge win.
- codedivine 15y ago
  One good read is: http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 "Software Transactional Memory: Why Is It Only a Research Toy?" by Cascaval et al. I think transactional memory systems with at least some hardware support are potentially more interesting.
  - exDM69 15y ago
    Some of the problems addressed in the papar can be solved with compiler enforceable constraints such as is done in Haskell's type system. What comes to the performance, the benchmarks in the paper range from no speedup at all with 8 cores to having 1.5x perf increase with 2 cores to 4x increase with 8 cores. To me, that definately sounds like something worth researching.
    - scott_s 15y ago
      The point of that paper is that they have been researching it, quite extensively. But the performance results have often been disappointing, and the semantics of nested transactions can be surprisingly complex. At what point do you start looking into other things?
masklinn 15y ago
There's the same issue with normal locks: any synchronization primitive is going to incur overhead. That is, in fact, one of the defense heralded by some in the Python community against the "GIL should Go" mobthink.
- scott_s 15y ago
  I think you misunderstood codedivine. His point was not that applications that use STM and make use of a single thread are slower than sequential implementations of the same application. We expect the parallel implementation's single threaded performance to suffer by a percentage or two (or ten...) because it has to do more hardware-level atomic operations. codedivine's point was that it is often the case that applications implemented with STM that use multiple threads often perform worse than the sequential version. See the excellent ACM Queue article he links to in a sibling comment.
  - masklinn 15y ago
    > I think you misunderstood codedivine. His point was not that applications that use STM and make use of a single thread are slower than sequential implementations of the same application. And the experience has been exactly the same in locks-based GIL-removal tests in Python: David Beazley recently "unearthed" and tested a GIL-removal patch from the 1.4 days[0]... > To test threads, I wrote a small sample that subdivided the work across two worker threads is an embarrassingly parallel manner (note: this code is a little wonky due to the fact that Python-1.4 doesn't implement thread joining--meaning that you have to do it yourself with the included binary-semaphore lock). > [...] > If you run this code with the GIL, the execution time is about 2.5 seconds or approximately 1.3 times slower than the single-threaded version (1.9 seconds). Using the GIL-less Python, the execution time is 18.5 seconds or approximately 1.45 times slower than the single-threaded version (12.7 seconds). Just to emphasize, the GIL-less Python running with two-threads is running more than 7 times slower than the version with a GIL. [0] http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-remova...
    - 15y ago
cabacon 15y ago
Then again, hardware transactional memory may be arriving: http://www.eetimes.com/electronics-news/4218914/IBM-plants-transactional-memory-in-CPU http://www.eetimes.com/electronics-news/4218914/IBM-plants-t...
- pjscott 15y ago
  Note that it's currently limited to transactions will fairly small read and write sets, but this is not an inherent limitation of hardware transactional memory, and it can be used as part of a hardware/software hybrid system to accelerate small transactions. I'm pretty excited. The chip modifications here are really small and cheap, so I think we may start seeing this in more mainstream server chips in a few years.

exDM69 15y ago

I hope you have sources and/or benchmarks to support your claims. Bashing a promising future technology without any backing is not constructive.

wynand 15y ago
codedivine has a point and it's even admitted in this posting: "we expect the initial performance to be abysmally bad (maybe 10x slower); however, with successive improvements to the locking mechanism, to the global program transformation inserting the locks, to the garbage collector (GC), and to the Just-in-Time (JIT) compiler, we believe that it should be possible to get a roughly reasonable performance (up to maybe 2x slower)." It will likely be difficult to beat expertly written code using explicit locks. But most people aren't experts in concurrency and will either get it wrong or have slow implementations. And if transactional memory catches on, we may even see some hardware assistance in future CPUs. (S)TM is definitely worth exploring more and even a 2x slower implementation (as envisioned by the PyPy team) could cover most concurrency needs, which will make it a success in most people's eyes.
- kbd 15y ago
  Do they mean 2x slower than CPython or 2x slower than PyPy? If they wind up with something 2x slower than current PyPy (which is much faster than CPython in many cases), that'll still be a version of Python much faster than CPython that doesn't have the limitations of the GIL and can thread across cores, and that'll be a huge win.
codedivine 15y ago
One good read is: http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 "Software Transactional Memory: Why Is It Only a Research Toy?" by Cascaval et al. I think transactional memory systems with at least some hardware support are potentially more interesting.
- exDM69 15y ago
  Some of the problems addressed in the papar can be solved with compiler enforceable constraints such as is done in Haskell's type system. What comes to the performance, the benchmarks in the paper range from no speedup at all with 8 cores to having 1.5x perf increase with 2 cores to 4x increase with 8 cores. To me, that definately sounds like something worth researching.
  - scott_s 15y ago
    The point of that paper is that they have been researching it, quite extensively. But the performance results have often been disappointing, and the semantics of nested transactions can be surprisingly complex. At what point do you start looking into other things?

masklinn 15y ago

There's the same issue with normal locks: any synchronization primitive is going to incur overhead. That is, in fact, one of the defense heralded by some in the Python community against the "GIL should Go" mobthink.

scott_s 15y ago
I think you misunderstood codedivine. His point was not that applications that use STM and make use of a single thread are slower than sequential implementations of the same application. We expect the parallel implementation's single threaded performance to suffer by a percentage or two (or ten...) because it has to do more hardware-level atomic operations. codedivine's point was that it is often the case that applications implemented with STM that use multiple threads often perform worse than the sequential version. See the excellent ACM Queue article he links to in a sibling comment.
- masklinn 15y ago
  > I think you misunderstood codedivine. His point was not that applications that use STM and make use of a single thread are slower than sequential implementations of the same application. And the experience has been exactly the same in locks-based GIL-removal tests in Python: David Beazley recently "unearthed" and tested a GIL-removal patch from the 1.4 days[0]... > To test threads, I wrote a small sample that subdivided the work across two worker threads is an embarrassingly parallel manner (note: this code is a little wonky due to the fact that Python-1.4 doesn't implement thread joining--meaning that you have to do it yourself with the included binary-semaphore lock). > [...] > If you run this code with the GIL, the execution time is about 2.5 seconds or approximately 1.3 times slower than the single-threaded version (1.9 seconds). Using the GIL-less Python, the execution time is 18.5 seconds or approximately 1.45 times slower than the single-threaded version (12.7 seconds). Just to emphasize, the GIL-less Python running with two-threads is running more than 7 times slower than the version with a GIL. [0] http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-remova...
  - 15y ago

cabacon 15y ago

Then again, hardware transactional memory may be arriving: http://www.eetimes.com/electronics-news/4218914/IBM-plants-transactional-memory-in-CPU http://www.eetimes.com/electronics-news/4218914/IBM-plants-t...

pjscott 15y ago
Note that it's currently limited to transactions will fairly small read and write sets, but this is not an inherent limitation of hardware transactional memory, and it can be used as part of a hardware/software hybrid system to accelerate small transactions. I'm pretty excited. The chip modifications here are really small and cheap, so I think we may start seeing this in more mainstream server chips in a few years.