Author: Armin Rigo <ar...@tunes.org> Branch: extradoc Changeset: r4954:1eae9d7ddf7f Date: 2013-03-14 11:24 -0700 http://bitbucket.org/pypy/extradoc/changeset/1eae9d7ddf7f/
Log: In-progress diff --git a/talk/pycon2013/pypy_without_gil.txt b/talk/pycon2013/pypy_without_gil.txt new file mode 100644 --- /dev/null +++ b/talk/pycon2013/pypy_without_gil.txt @@ -0,0 +1,140 @@ +==================== +PyPy without the GIL +==================== + +Intro +--------------------------- + +- PyPy intro + +- thanks to contributors for STM + + + +Demo +--------------------------- + +- demo: ~/br/stm-thread-2/64compiled/pypy-c-r61735+-stm + + * run some random multithreaded program + + +- missing in pypy-stm: + + * GC major collection + * JIT + * some more optimizations possible (= tons of) + + +- __pypy__.thread.atomic + + * with atomic: + print "hello", username + + * the illusion of serialization + + +Lower level: STM +--------------------------- + +- pypy and not cpython? + + +- STM = Software Transactional Memory + + +- Basic idea: each thread runs in parallel, but everything it does is + in a series of "transactions" + + +- A transaction keeps all changes to pre-existing memory "local" + + +- The changes are made visible only when the transaction "commits" + + +- The transaction will "abort" if a conflict is detected, and + it will be transparently retried + + +- Non-reversible operations like I/O turn the transaction "inevitable" + and stop progress in the other threads + + +- __pypy__.thread.last_abort_info() -> traceback-like information + + +- (GC-supported structure: when we want to modify a pre-existing object, + we first copy it into "local" memory, and when we commit, it becomes + the newer version of the old pre-existing object; we end up with a + chained list of versions, and we have to make sure we always use the + latest one. We rely on GC major collections to free them eventually.) + + +- alternative: HTM...? + + +Higher level: not threads +--------------------------- + + +- based on (and fully compatible with) threads + + * existing multithreaded programs work + + +- but opens up unexpected alternatives + + * we can run multiple threads but at the same time use ``atomic`` + + * with the GIL-based idea of ``atomic`` it doesn't make sense: + we have multiple threads but they're all using ``atomic``, i.e. + only one at a time will ever run... except no :-) + + +- transaction.py + + * demo + + * illusion of serial execution: can "sanely" reason about algorithms + + * "Conflict tracebacks" + + * Might need to debug them --- but they are performance bugs, not + correctness bugs + + * The idea is that we fix only XX% of the bugs and we are done + + * Maybe some new "performance debugger" tools might help us too + + +- TigerQuoll, 1st March: same idea with JavaScript (for servers) + + * various models possible: + + . events dispatchers + + . futures + + . map/reduce, scatter/gather + + +- Event dispatchers + + * twisted, tulip, etc. + + * run the event dispatcher in one thread (e.g. the main thread), + and schedule the actual events to run on a different thread from + a pool + + * the events are run with ``atomic``, so that they appear to run + serially + + * this tweaked event loop should work with just any existing program + + +- Futures + + * e.g. twisted's deferred + + ... _______________________________________________ pypy-commit mailing list pypy-commit@python.org http://mail.python.org/mailman/listinfo/pypy-commit