Author: Antonio Cuni <[email protected]> Branch: extradoc Changeset: r4224:c5ccff3ae018 Date: 2012-06-30 10:39 +0200 http://bitbucket.org/pypy/extradoc/changeset/c5ccff3ae018/
Log: merge heads diff --git a/talk/ep2012/stm/stm.txt b/talk/ep2012/stm/stm.txt new file mode 100644 --- /dev/null +++ b/talk/ep2012/stm/stm.txt @@ -0,0 +1,113 @@ + + +Problem +------- + + Python is slow-ish, by some factor N + + (Python / other lang) ~= N ~= const + + CPU speed used to grow exponentially, but no longer + + one program written in Python runs on one core only + + which means that one program written in Python will in the future run + exponentially slower, when compared with "other lang" + + does not matter for all programs... or does it? think about it this way: + + 1. my script runs anyway in 0.1 seconds. + + Yes, but what if you were running it on 2002 hardware? it would take + 3 seconds. On 1982 hardware? One hour. So if the CPU speed growth + stop had occurred in 1982 already, then your script would still take + one hour today to run in Python. (Or half an hour thanks to the + continuing hard work of a dedicated core team...) + + 2. I can use other solutions involving launching multiple processes + and exchanging data between them. + + Yes, which is fine. For some problems it is the "correct" + solution (separation for security, etc.). But for some other + problems it doesn't apply or at least not easily. Imagine a + Python without GC. You can of course handle manually allocating + and freeing objects, like in C++. But you're missing a vast + simplification that you get for free in Python. + + +This presentation is not about removing the GIL +----------------------------------------------- + +pypy-stm is a Python without the GIL, the fourth in this category: + + - Python 1.4 patch by Greg Stein in 1996 + - Jython + - IronPython + +Demo pypy-stm + +No JIT integration so far, about 4x slower than a JIT-less PyPy + +Will talk later about "STM". + +Some hardware support (HTM) coming in 2013 (Intel's Haswell CPU), +which promizes to make it easy to do the same with CPython + +So removing the GIL is suddenly around the corner + + +The catch +--------- + +You have to use threads + + +Threads +------- + +Threads are messy to use correctly + +Similar to doing explicit memory management: I would like my program to +figure it automatically, not have to worry about it every single line of +code. + +Debugging a race condition is a nightmare, totally non-reproductible. + + +This presentation is really about this new feature +-------------------------------------------------- + +Demo: pypy-stm using the "transaction" module + +Demo how to insert usage of it in pypy/rpython/rtyper.py + + +What you get +------------ + +A fool-proof API that gives multicore usages *without using threads* + +Implemented in pypy-stm --- slowly, but who cares? :-) when you have +an unlimited supply of cores... (ok, I agree we care anyway.) + +How? See below. + + +What about CPython? +------------------- + +HTM coming in Intel's Haswell CPU is not going to be enough at all for +this. It'll eventually get there, but in how many years? and how many +more years before we can assume that every CPU out there has it? + +In the meantime there seem to be no move from the CPython core +developers to try to implement STM. It would be a major undertaking. + +So the future looks to me like: (CPython / other lang) will go down +exponentially until the point, in 10-20 years, where HTM is good +enough for CPython. A "dark age" of CPython... + + +Transactional Memory +-------------------- + diff --git a/talk/ep2012/stm/talk.rst b/talk/ep2012/stm/talk.rst --- a/talk/ep2012/stm/talk.rst +++ b/talk/ep2012/stm/talk.rst @@ -56,6 +56,8 @@ moved from 'alpha' to 'beta': it runs e.g. a big part of **PyOpenSSL** and **lxml** +* py3k in progress (but 2.7 support never going away) + PyPy organization ----------------- _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
