Author: Armin Rigo <ar...@tunes.org> Branch: extradoc Changeset: r4148:9b2e5807749c Date: 2012-03-10 08:05 -0800 http://bitbucket.org/pypy/extradoc/changeset/9b2e5807749c/
Log: Change the approach in the lighting talk. diff --git a/talk/pycon2012/lightningtalk-tm.txt b/talk/pycon2012/by-example/tm.txt copy from talk/pycon2012/lightningtalk-tm.txt copy to talk/pycon2012/by-example/tm.txt diff --git a/talk/pycon2012/lightningtalk-tm.txt b/talk/pycon2012/lightningtalk-tm.txt --- a/talk/pycon2012/lightningtalk-tm.txt +++ b/talk/pycon2012/lightningtalk-tm.txt @@ -1,60 +1,288 @@ -Transactional Memory --------------------- -Software Transactional Memory: STM -Hardware Transactional Memory: HTM + Garbage Collection + ------------------ + PascalCon 1982 - | -thread 1 |XXXXXXXXXXXXXXXXXXXXXXXXXXXX... - | - +------------------------------> time - | -thread 1 |[XX] [X] [X] -thread 2 | [XX] [XX] -thread 3 | [XXX] [XX] [X] - +------------------------------> time - | -thread 1 |[XX][X][X] -thread 2 |[XX][XX] -thread 3 |[XXX][XX][X] - +------------------------------> time + you call malloc() - | -thread 1 |[XX][X-oups-[X][X] -thread 2 |[XX][XX] -thread 3 |[XX-oups-[XXX][XX][X] - +------------------------------> time + you don't need to call free() - | -thread 1 |[XXXXXXXXXX] [XXXXXXXXXXXXXX] [... - | - +------------------------------> time - | -thread 1 |[XXXXXXXXXX] [... -thread 2 |[XXXXXXXXXXXXXXXXX] - +------------------------------> time - | -thread 1 |[XXXXXXXXXX] [... -thread 2 |[XXX-oups-[XXXXXXXXXXXXXXXXX] - +------------------------------> time + + + costly, so likely just for a + fraction of the malloc()s + + + + + + + + + + open issues: + + integration is hard: + + pointers between GC-managed + and explicitly-managed memory + + + + + + + + + + "solution": put everything + in the GC-managed memory + + + + + + + + + + + + + theoretical answer: + horrible for performance + (memory and speed) + + + + + + + + + + + + for the foreseeable future: + just a solution of convenience + + not for real programmers + + + + + + + + + real programmers can live with + the mess of explicit memory + management + + + + + + + + ...30 years later: + + PyCon 2012 + ---------- + + + + + + + + + + + Garbage Collection is automatic + and everywhere + + + (but was hard work to get right) + + + + + + + + + + + we don't talk about Garbage Collection + + + + + + + + + + + + + + instead we talk about how to use + multiple cores + + + + + + + + + + + + + mess with locks, reentrant locks, + semaphores, events, ... + + + + + + + + + + in Python we have the GIL + + but *also* the threading module + + + + + + + + + + + + + + i.e. also, if we want, the mess + + + + + + + + Transactional Memory + -------------------- + + + + + + + + + + + + + + promises to give multicore usage + + + + + + + + + performance issues + + + and + + + hard integration issues: + + co-operation between transactional + and non-transactional code, I/O, etc + + + + + + + + + "solution": run everything in + Transactional Memory + + + + + + + + + your app answers to "events" + (web requests, anything) + + we can run these events + mostly in parallel + + we care for sync issues under the hood + + + + + + + "solution" + + + hard work, but likely worth + removing the quotes :-) + + + + + + + + + + + STM + + http://pypy.org/ + + + + + _______________________________________________ pypy-commit mailing list pypy-commit@python.org http://mail.python.org/mailman/listinfo/pypy-commit
