Re: Why GIL? (was Re: what's the point of rpython?)

In article <7xr62ufv1c@ruckus.brouhaha.com>, Paul Rubin wrote: >a...@pythoncraft.com (Aahz) writes: >> >> CPython's "primitive" storage management has a lot to do with the >> simplicity of interfacing CPython with external libraries. Any solution >> that propose

Re: Why GIL? (was Re: what's the point of rpython?)

Rhamphoryncus writes: > IMO it's possible to rewrite only the core while keeping the refcount > API for external compatibility, but a tracing GC API in portable C is > hideous. It's done all the time for other languages, and is less hassle than the incref/decref stuff and having to remember the

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 27, 12:47 pm, Steve Holden wrote: > Paul Rubin wrote: > > GIL-less Python (i.e. Jython) already exists and beats CPython in > > performance a lot of the time, including on single processors. > > Whether the GIL can be eliminated from CPython without massive rework > > to every extension mod

Re: Why GIL? (was Re: what's the point of rpython?)

Paul Rubin wrote: > Bryan Olson writes: >> I'm a fan of lock-free data structure and software transactional >> memory, but I'm also a realist. Heck, I'm one of this group's >> outspoken advocates of threaded architectures. Theoretical >> breakthroughs will happen, but in real world of today, threa

Re: Why GIL? (was Re: what's the point of rpython?)

Bryan Olson writes: > I'm a fan of lock-free data structure and software transactional > memory, but I'm also a realist. Heck, I'm one of this group's > outspoken advocates of threaded architectures. Theoretical > breakthroughs will happen, but in real world of today, threads are > great but GIL-l

Re: Why GIL? (was Re: what's the point of rpython?)

Bryan Olson wrote: > Paul Rubin wrote: >> Bryan Olson writes: >>> An object's __dict__ slot is *not* mutable; thus we could gain some >>> efficiency by protecting the object and its dict with the same lock. I >>> do not see a major win in Mr. Banks' point that we do not need to lock >>> the object

Re: Why GIL? (was Re: what's the point of rpython?)

Paul Rubin wrote: Bryan Olson writes: An object's __dict__ slot is *not* mutable; thus we could gain some efficiency by protecting the object and its dict with the same lock. I do not see a major win in Mr. Banks' point that we do not need to lock the object, just its dict. If the dict conten

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 24, 12:05 pm, Carl Banks wrote: > The default metatype for Python classes would be > mutable_dict_type, which is a type wherein the object itself would be > mutable but it would still have all the mutator methods __init__, > __setattr__, etc., but they could only act on the __dict__. Not

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 24, 12:40 am, "Gabriel Genellina" wrote: > En Sat, 24 Jan 2009 06:06:02 -0200, Carl Banks   > escribió: > > > > > On Jan 23, 11:45 pm, Bryan Olson wrote: > >> Carl Banks wrote: > >> > Classes in Python are mutable types, usually.  Class instances are > >> > (except for the refcount) immut

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks wrote: > On Jan 23, 8:22 pm, Bryan Olson wrote: >> Paul Rubin wrote: >>> Bryan Olson writes: > BTW, class instances are usually immutable and thus don't require a > mutex in the system I described. Then you are describing a language radically different from Python. >>> That

Re: Why GIL? (was Re: what's the point of rpython?)

En Sat, 24 Jan 2009 06:06:02 -0200, Carl Banks escribió: On Jan 23, 11:45 pm, Bryan Olson wrote: Carl Banks wrote: > Classes in Python are mutable types, usually.  Class instances are > (except for the refcount) immutable objects, usually. There's where we disagree. I assert that class insta

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 11:45 pm, Bryan Olson wrote: > Carl Banks wrote: > > Classes in Python are mutable types, usually.  Class instances are > > (except for the refcount) immutable objects, usually. > > There's where we disagree. I assert that class instances are usually > mutable objects. Nope, you're dea

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks wrote: Bryan Olson wrote: Paul Rubin wrote: Bryan Olson writes: BTW, class instances are usually immutable and thus don't require a mutex in the system I described. Then you are describing a language radically different from Python. That one threw me for a minute too, but I th

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 10:55 pm, Bryan Olson wrote: > Carl Banks wrote: > > Paul Rubin wrote: > >> Bryan Olson writes: > BTW, class instances are usually immutable and thus don't require a > mutex in the system I described. > >>> Then you are describing a language radically different from Python. >

Re: Why GIL? (was Re: what's the point of rpython?)

Bryan Olson writes: > An object's __dict__ slot is *not* mutable; thus we could gain some > efficiency by protecting the object and its dict with the same lock. I > do not see a major win in Mr. Banks' point that we do not need to lock > the object, just its dict. If the dict contents don't chang

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks wrote: Paul Rubin wrote: Bryan Olson writes: BTW, class instances are usually immutable and thus don't require a mutex in the system I described. Then you are describing a language radically different from Python. That one threw me for a minute too, but I think the idea is that t

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks writes: > > What's more, this matters when considering a GIL-less implementation. > > Typical method calls can traverse lots of mutable stuff just to find the > > function to invoke. > > Now that doesn't make sense at all. What is all this mutable stuff > you have to go through, and w

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 8:22 pm, Bryan Olson wrote: > Paul Rubin wrote: > > Bryan Olson writes: > >>> BTW, class instances are usually immutable and thus don't require a > >>> mutex in the system I described. > >> Then you are describing a language radically different from Python. > > > That one threw me for a

Re: Why GIL? (was Re: what's the point of rpython?)

Bryan Olson writes: > The meaning of 'immutable' is well-established in the Python > literature. Python's immutable types include tuple, frozenset, and > various kinds of numbers and strings. Class instances, not so much. But we are talking about objects as they live in the C implementation, not

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 7:19 pm, Paul Rubin wrote: > Bryan Olson writes: > > > BTW, class instances are usually immutable and thus don't require a > > > mutex in the system I described. > > Then you are describing a language radically different from Python. > > That one threw me

Re: Why GIL? (was Re: what's the point of rpython?)

Paul Rubin wrote: Bryan Olson writes: BTW, class instances are usually immutable and thus don't require a mutex in the system I described. Then you are describing a language radically different from Python. That one threw me for a minute too, but I think the idea is that the class instance

Re: Why GIL? (was Re: what's the point of rpython?)

Steven D'Aprano writes: > For example... is this instance immutable? > > class Foo: > bar = None > > f = Foo() > f.baz = True > If so, what do you mean by immutable? If I understand Carl, yes, f is immutable. When you set f.bar, the contents of f.__dict__ changes but f itself does not chan

Re: Why GIL? (was Re: what's the point of rpython?)

On Fri, 23 Jan 2009 18:54:18 -0800, Carl Banks wrote: > On Jan 23, 5:48 pm, Bryan Olson wrote: >> Carl Banks wrote: >> >> [...] >> >> > BTW, class instances are usually immutable and thus don't require a >> > mutex in the system I described. >> >> Then you are describing a language radically diff

Re: Why GIL? (was Re: what's the point of rpython?)

Bryan Olson writes: > > BTW, class instances are usually immutable and thus don't require a > > mutex in the system I described. > Then you are describing a language radically different from Python. That one threw me for a minute too, but I think the idea is that the class instance itself is immu

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 5:48 pm, Bryan Olson wrote: > Carl Banks wrote: > > [...] > > > BTW, class instances are usually immutable and thus don't require a > > mutex in the system I described. > > Then you are describing a language radically different from Python. Bzzt. Hint: aside from the reference count,

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks wrote: [...] BTW, class instances are usually immutable and thus don't require a mutex in the system I described. Then you are describing a language radically different from Python. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list

Re: Why GIL? (was Re: what's the point of rpython?)

Rhamphoryncus wrote: [... eighty-eight quoted lines ...] > > I'm sorry, you're right, I misunderstood your context. Perhaps you could trim your posts to quote only the relevant context? Thanks. -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holden

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 23, 7:33 am, s...@pobox.com wrote: >     >> You mean every time you access a list or dictionary or class >     >> instance, you have to acquire a mutex?  That sounds like a horrible >     >> slowdown. > >     Steve> Indeed it would, but hey, let's not let that stop us repeating >     Steve>

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 11:09 pm, Carl Banks wrote: > On Jan 22, 9:38 pm, Rhamphoryncus wrote: > > > > > On Jan 22, 9:38 pm, Carl Banks wrote: > > > > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > > > > > In article <7xd4ele060@ruckus.brouhaha.com>, > > > > Paul Rubin  

Re: Why GIL? (was Re: what's the point of rpython?)

s...@pobox.com writes: > Also, every object is mutable at some level. Tuples, ints and floats are > definitely mutable at creation time. You need to hold a mutex then, so > Carl's notion of three types of objects breaks down then. Hopefully, at creation time, they will usually be in a scope wher

Re: Why GIL? (was Re: what's the point of rpython?)

>> You mean every time you access a list or dictionary or class >> instance, you have to acquire a mutex? That sounds like a horrible >> slowdown. Steve> Indeed it would, but hey, let's not let that stop us repeating Steve> the thinking that's gone into CPython over the last

Re: Why GIL? (was Re: what's the point of rpython?)

Paul Rubin wrote: > Carl Banks writes: >> 3. If you are going to use the low-level API on a mutable object, or >> are going to access the object structure directly, you need to acquire >> the object's mutex. Macros such as Py_LOCK(), Py_LOCK2(), Py_UNLOCK() >> would be provided. > > You mean ever

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 10:15 pm, Paul Rubin wrote: > Carl Banks writes: > > 3. If you are going to use the low-level API on a mutable object, or > > are going to access the object structure directly, you need to acquire > > the object's mutex. Macros such as Py_LOCK(), Py_LOCK2(

Re: Why GIL? (was Re: what's the point of rpython?)

Carl Banks writes: > 3. If you are going to use the low-level API on a mutable object, or > are going to access the object structure directly, you need to acquire > the object's mutex. Macros such as Py_LOCK(), Py_LOCK2(), Py_UNLOCK() > would be provided. You mean every time you access a list or

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 9:38 pm, Rhamphoryncus wrote: > On Jan 22, 9:38 pm, Carl Banks wrote: > > > > > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > > > > In article <7xd4ele060@ruckus.brouhaha.com>, > > > Paul Rubin   wrote: > > > > >alex23 writes: > > > > >> He

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 9:38 pm, Carl Banks wrote: > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > > > > > In article <7xd4ele060@ruckus.brouhaha.com>, > > Paul Rubin   wrote: > > > >alex23 writes: > > > >> Here's an article by Guido talking about the last attempt

Re: Why GIL? (was Re: what's the point of rpython?)

a...@pythoncraft.com (Aahz) writes: > CPython's "primitive" storage management has a lot to do with the > simplicity of interfacing CPython with external libraries. Any solution > that proposes to get rid of the GIL needs to address that. This, I don't understand. Other languages like Lisp and J

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > In article <7xd4ele060@ruckus.brouhaha.com>, > Paul Rubin   wrote: > > >alex23 writes: > > >> Here's an article by Guido talking about the last attempt to remove > >> the GIL and the performance issues that

Why GIL? (was Re: what's the point of rpython?)

In article <7xd4ele060@ruckus.brouhaha.com>, Paul Rubin wrote: >alex23 writes: >> >> Here's an article by Guido talking about the last attempt to remove >> the GIL and the performance issues that arose: >> >> "I'd welcome a set of patches into Py3k *only if* th