Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r5161:ffa0a239d1a2 Date: 2014-02-25 15:27 +0100 http://bitbucket.org/pypy/extradoc/changeset/ffa0a239d1a2/
Log: Add the WTM abstract. diff --git a/talk/wtm2014/abstract.rst b/talk/wtm2014/abstract.rst new file mode 100644 --- /dev/null +++ b/talk/wtm2014/abstract.rst @@ -0,0 +1,47 @@ +Abstract +-------- + +As part of the PyPy project, we explore the usage of transactional +memory (TM) to enable parallelism for high-level, dynamic languages like +Python or Ruby. + +Most current software TM (STM) systems suffer from a big overhead when +they run on a single thread only (usually between 2-5x slowdown). They +try to scale to a large number of CPUs for the benefit of +parallelization to be greater than the penalty of the overhead. On the +other hand, while also software-based, the system presented here +initially focuses on a low CPU count (< 8). It uses an approach that can +keep the single-thread overhead very low (initial experiments with a +simple lisp interpreter suggest around 15%). As a consequence we already +see great speed-ups over single-threaded, non-STM execution by only +using 2 CPU cores. We achieve this with very-low-overhead read barriers +and very-low-overhead fast paths of write barriers. The enabling +mechanism, the Linux-only system call "remap_file_pages", allows for +creating several "views" on partially shared memory; every thread sees +one of these views. + +Our goal is to support a mixture of short to very long transactions. We +have an object-based STM system with an integrated GC handling the +typical high allocation rates of dynamic languages; in particular, it is +a generational GC, and the write barrier combines GC and STM roles, +always taking the fast path for recently-allocated objects. + +The next step is to finish integrating this system with PyPy, the Python +interpreter in Python, and its Just-In-Time compiler. This is +relatively straightforward and partly done already. We believe that the +result has got the potential to give good enough performance to rival or +exceed the HTM experiments which have been done before on Ruby [1]. +Future considerations also include optionally adding a hybrid (HyTM) +component to our system. + + +-------- + +[1] Eliminating Global Interpreter Locks in Ruby through Hardware +Transactional Memory. + +Rei Odaira, Jose G. Castanos and Hisanobu Tomari. + +PPoPP '14 Proceedings of the 19th ACM SIGPLAN symposium on Principles and practice of parallel programming + +Pages 131-142 _______________________________________________ pypy-commit mailing list [email protected] https://mail.python.org/mailman/listinfo/pypy-commit
