[pypy-dev] Thinking about the GIL
alex.gaynor at gmail.com
Mon Mar 28 03:01:28 CEST 2011
On Sun, Mar 27, 2011 at 8:53 PM, hyarion at iinet.net.au
<hyarion at iinet.net.au>wrote:
> On Fri Mar 25 21:41 , Armin Rigo sent:
> >On Fri, Mar 18, 2011 at 1:44 AM, hyarion at iinet.net.au
> >hyarion at iinet.net.au> wrote:
> >> (...) Wrapping each bytecode in an STM
> >> transaction would give you an as-if-serial execution order, again with
> >> about which order. You get transaction overheads instead of lock/unlock
> >> but some STM systems can be quite efficient for short transactions that
> >> conflict.
> >Yes, I also thought about this as one of the solutions that would "fit
> >the model" of PyPy by not needing changes all over the place.
> >However, I am unsure that the performance of STM is good enough for
> >that application so far. Maybe I'm wrong, but I fear (a priori, with
> >no precise experience) that it would be really too slow to wrap *all*
> >memory reads and writes with the STM machinery.
> Yeah, I suppose to get the performance I'm thinking of you probably need to
> what you're sharing (and for it not to be everything). You wouldn't need
> all memory
> reads and writes to be transactional, just ones to interpreter-level values
> that are
> mutable and shared between threads, and ones to things that represent
> shareable values.
> The STM system I worked on was for a declarative language with immutable
> data. In
> that context it turns out the system only had to be careful when retrieving
> references from STM; what the reference points to could still be used as
> normal non-
> shared data. In a language like Python I guess almost any bit of memory
> potentially be (or later become) a shared value that another thread could
> be using.
> What's the "success-rate" of the JIT's malloc-removal like? You could omit
> transactional overhead for those values. Would that get close enough for
> important 20% of code? You could probably do some other jiggery-pokery
> under the
> hood to minimise the amount of data protected by STM overhead too.
> If I had more time I'd love to look at this sort of thing.
> -- Ben
> pypy-dev at codespeak.net
info on the success rate of allocation removal.
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pypy-dev