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: what's the point of rpython?

On Jan 17, 5:55 pm, "Brendan Miller" wrote: > The python devs seem to > consider the GIL a non-issue, though they may change their mind in 3 > years when we all have 32 core desktops, For what it's worth, I am currently using Python to perform a scientific computation on 1400+ cores, and it seems

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

Re: what's the point of rpython?

Ross Ridge writes: > The same cache coherency mechanism that prevents ordinary "unlocked" > instructions from simulanteously modifying the same cache line on > two different processors also provides the guarantee with "locked" > instructions. There's no additional hardware locks involved, and no

Re: what's the point of rpython?

Paul Rubin wrote: Ross Ridge writes: Scott David Daniels wrote: The opcode cannot simply talk to its cache, it must either go directly to off-chip memory or communicate to other processors that it (and it alone) owns the increment target. The cache coherency mechanism automatically preven

Re: what's the point of rpython?

In article , Ross Ridge wrote: >Scott David Daniels wrote: >> >>The opcode cannot simply talk to its cache, it must either go directly >>to off-chip memory or communicate to other processors that it (and it >>alone) owns the increment target. > >In fact all it does simply talk to its cache. Fr

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

Re: what's the point of rpython?

On Jan 21, 9:46 pm, Paul Rubin wrote: > Rhamphoryncus writes: > > a) The contended case is the issue, not the uncontended case.  An > > uncontended lock is just constant overhead, not a barrier to > > scalability > > a1) Really what matters is the actual mix between

Re: what's the point of rpython?

Rhamphoryncus writes: > a) The contended case is the issue, not the uncontended case. An > uncontended lock is just constant overhead, not a barrier to > scalability a1) Really what matters is the actual mix between contended and uncontended accesses, and the synchronization strategy affects the

Re: what's the point of rpython?

Brendan Miller writes: > Actually this article explicitly mentions CMPXCHG as lock free. > http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms I see, that clears up some mysteries. Thanks. -- http://mail.python.org/mailman/listinfo/python-list

Re: what's the point of rpython?

Ross Ridge writes: > Scott David Daniels wrote: > >The opcode cannot simply talk to its cache, it must either go directly > >to off-chip memory or communicate to other processors that it (and it > >alone) owns the increment target. > The cache coherency mechanism automatically prevents tw

Re: what's the point of rpython?

On Jan 21, 12:57 pm, MRAB wrote: > I'm not sure whether multicore processors share a cache or, if not, have > some other on-chip mechanism. Multiprocessor machines, however, are a > different matter... They share some, but also have some exclusive. How much of which depends entirely on which CPU

Re: what's the point of rpython?

Scott David Daniels wrote: >The opcode cannot simply talk to its cache, it must either go directly >to off-chip memory or communicate to other processors that it (and it >alone) owns the increment target. In fact all it does simply talk to its cache. From the "Intel 64 and IA-32 Architectures S

Re: what's the point of rpython?

Brendan Miller wrote: On Wed, Jan 21, 2009 at 8:19 AM, Scott David Daniels wrote: Brendan Miller wrote: On Tue, Jan 20, 2009 at 10:03 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: Of course I'm aware of the LOCK prefix but it slows down the instruction enormously compared with

Re: what's the point of rpython?

On Wed, Jan 21, 2009 at 8:19 AM, Scott David Daniels wrote: > Brendan Miller wrote: >> >> On Tue, Jan 20, 2009 at 10:03 PM, Paul Rubin >> <"http://phr.cx"@nospam.invalid> wrote: >>> >>> Of course I'm aware of the LOCK prefix but it slows >>> down the instruction enormously compared with a no

Re: what's the point of rpython?

Brendan Miller wrote: On Tue, Jan 20, 2009 at 10:03 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: Of course I'm aware of the LOCK prefix but it slows down the instruction enormously compared with a non-locked instruction. I'm curious about that. I've been looking around for timi

Re: what's the point of rpython?

Brendan> Intuitively, given that the processor is much Brendan> faster than the bus, and you are just waiting for processor to Brendan> complete an addition or comparison before put the new memory Brendan> value on the bus... I think in Python's case the reference count will often

Re: what's the point of rpython?

Brendan Miller writes: > I'm curious about that. I've been looking around for timing > information on the lock signal, but am having some trouble finding > them. Intuitively, given that the processor is much faster than the > bus, and you are just waiting for processor to complete an addition or >

Re: what's the point of rpython?

On Tue, Jan 20, 2009 at 10:03 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > "Rhodri James" writes: >> You asked a question about CPUs with atomic update, strongly implying >> there were none. All I did was supply a counter-example, > > Well, more specifically, atomic update without loc

Re: what's the point of rpython?

"Rhodri James" writes: > You asked a question about CPUs with atomic update, strongly implying > there were none. All I did was supply a counter-example, Well, more specifically, atomic update without locking, but I counted the LOCK prefix as locking while other people didn't, and that caused so

Re: what's the point of rpython?

On Wed, 21 Jan 2009 05:37:44 -, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: "Rhodri James" writes: In that case I'd second the suggestion of taking a long, hard look at the Linux core locking and synchronisation primatives. Do you understand what the issue is, about CPython's re

Re: what's the point of rpython?

"Rhodri James" writes: > I tend to live in single-core worlds, so "inc" on its lonesome works > just fine. In a single core world we wouldn't be having these endless angsty conversations about eliminating the GIL. > > That has already been tried, and found to be unacceptably slow for the > > pur

Re: what's the point of rpython?

On Tue, Jan 20, 2009 at 6:29 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > "Rhodri James" writes: >> > What cpu's do you know of that can atomically increment and decrement >> > integers without locking? >> >> x86 (and pretty much any 8080 derivative, come to think of it). > > It would

Re: what's the point of rpython?

On Wed, 21 Jan 2009 02:29:01 -, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: "Rhodri James" writes: > What cpu's do you know of that can atomically increment and decrement > integers without locking? x86 (and pretty much any 8080 derivative, come to think of it). It would not ha

Re: what's the point of rpython?

"Rhodri James" writes: > > What cpu's do you know of that can atomically increment and decrement > > integers without locking? > > x86 (and pretty much any 8080 derivative, come to think of it). It would not have occurred to me that "lock inc" increments "without locking". I understand that's d

Re: what's the point of rpython?

Rhodri> Just do the locking properly and worry about optimisations Rhodri> later. The locking is already done properly (assuming we are discussing CPython's reference counting). Now is later. People are thinking about lots of optimizations, this is just one of them. -- Skip Montanaro -

Re: what's the point of rpython?

On Tue, 20 Jan 2009 04:19:26 -, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: "Brendan Miller" writes: Maybe I'm missing something here but a lock free algorithm for reference counting seems pretty trivial. As long as you can atomically increment and decrement an integer without loc

Re: what's the point of rpython?

Paul Rubin wrote: >Those links describe using the LOCK prefix, which as the name implies, >asserts a lock, so it is no longer "lockless reference counting". No, it doesn't assert a lock in the sense used in this thread. On modern Intel systems it's normally handle

Re: what's the point of rpython?

On Jan 20, 2:39 pm, Paul Rubin wrote: > Rhamphoryncus writes: > > "lock free" is largely meaningless.  What it really means is "we use > > small hardware locks rather than big software locks, thereby reducing > > (but not eliminating!) the contention". > > At least i

Re: what's the point of rpython?

Rhamphoryncus writes: > "lock free" is largely meaningless. What it really means is "we use > small hardware locks rather than big software locks, thereby reducing > (but not eliminating!) the contention". At least in the case of Haskell's "software transactional memory", reads are genuinely loc

Re: what's the point of rpython?

"Brendan Miller" writes: > > http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety > > I think you are misreading that. It says that multiple assignments to > different copies of a share_ptr in different threads are fine. I'll respond to this later. > http://www.codema

Re: what's the point of rpython?

On Jan 19, 9:00 pm, "Brendan Miller" wrote: > Maybe I'm missing something here but a lock free algorithm for > reference counting seems pretty trivial. As long as you can atomically > increment and decrement an integer without locking you are pretty much > done. "lock free" is largely meaningless

Re: what's the point of rpython?

On Jan 16, 5:37 pm, "Brendan Miller" wrote: > So I kind of wanted to ask this question on the pypy mailing list.. > but there's only a pypy-dev list, and I don't want to put noise on the > dev list. > > What's the point of RPython? By this, I don't

Re: what's the point of rpython?

Carl Banks wrote: >I just looked at the boost documentation, which claims that multiple >asynchronous writes to the same shared_ptr results in undefined >behavior. That will not suffice for Python reference counting. If you read the Boost documentation you'll see that while multiple simulaneous

Re: what's the point of rpython?

On Tue, Jan 20, 2009 at 3:46 AM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > s...@pobox.com writes: >> Carl, I'm quite unfamiliar with Boost and am not a C++ person, so may have >> read what you saw but not recognized it in the C++ punctuation soup. I >> couldn't find what you referred to

Re: what's the point of rpython?

s...@pobox.com writes: > Carl, I'm quite unfamiliar with Boost and am not a C++ person, so may have > read what you saw but not recognized it in the C++ punctuation soup. I > couldn't find what you referred to. Can you provide a URL? http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr

Re: what's the point of rpython?

Carl> I just looked at the boost documentation, which claims that Carl> multiple asynchronous writes to the same shared_ptr results in Carl> undefined behavior. That will not suffice for Python reference Carl> counting. Carl, I'm quite unfamiliar with Boost and am not a C++ perso

Re: what's the point of rpython?

On 17 Jan., 01:37, "Brendan Miller" wrote: > Is this going anywhere or is this just architecture astronautics? > > The RPython project seems kind of interseting to me and I'd like to > see more python implementations, but looking at the project I can't > help but think that they haven't really ex

Re: what's the point of rpython?

"Brendan Miller" writes: > As long as you can atomically increment and decrement an integer > without locking you are pretty much done. Most cpu's can't do that. > For a reference implementation of lock free reference counting on all > common platforms check out boosts implementation of shared_p

Re: what's the point of rpython?

On Jan 19, 8:00 pm, "Brendan Miller" wrote: > Maybe I'm missing something here but a lock free algorithm for > reference counting seems pretty trivial. As long as you can atomically > increment and decrement an integer without locking you are pretty much > done. You're missing that most of the pl

Re: what's the point of rpython?

"Brendan Miller" writes: > Maybe I'm missing something here but a lock free algorithm for > reference counting seems pretty trivial. As long as you can atomically > increment and decrement an integer without locking you are pretty much > done. What cpu's do you know of that can atomically increme

Re: what's the point of rpython?

Maybe I'm missing something here but a lock free algorithm for reference counting seems pretty trivial. As long as you can atomically increment and decrement an integer without locking you are pretty much done. For a reference implementation of lock free reference counting on all common platforms

Re: what's the point of rpython?

s...@pobox.com writes: > http://letmegooglethatforyou.com/?q=lock+free+reference+counting I found a paper by Detlefs et al describing a method which is a) patented b) can potentially lock out some threads from ever running, and c) relies on a hardware instruction (double compare and swap) that

Re: what's the point of rpython?

Paul> That's interesting, got a reference? (no pun intended) http://letmegooglethatforyou.com/?q=lock+free+reference+counting -- Skip Montanaro - s...@pobox.com - http://smontanaro.dyndns.org/ -- http://mail.python.org/mailman/listinfo/python-list

Re: what's the point of rpython?

"Brendan Miller" writes: > That's interesting, I hadn't heard the reference counting mechanism > was related to the GIL. Is it just that you need to lock the reference > count before mutating it if there's no GIL? Yes. Someone tried inserting such a lock but it slowed down the single-cpu case u

Re: what's the point of rpython?

On Sat, Jan 17, 2009 at 7:57 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> 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* the performance for

Re: what's the point of rpython?

On Jan 18, 8:56 am, andrew cooke wrote: > Since this is a PyPy bashing thread, maybe it's an appropriate place > to suggest that the project has got a little bit waylaid by exploring > cool things instead of releasing a useful final result? > > I am not questioning rpython directly - the case for

Re: what's the point of rpython?

The goals are listed here: http://codespeak.net/pypy/dist/pypy/doc/architecture.html Speed is mentioned, but as a secondary concern. The main goal seems to be to create a vehicle into exploring the concept of dynamic languages themselves. If that seems amorphous then it is because it is a researc

Re: what's the point of rpython?

Since this is a PyPy bashing thread, maybe it's an appropriate place to suggest that the project has got a little bit waylaid by exploring cool things instead of releasing a useful final result? I am not questioning rpython directly - the case for something like that is obvious. But there's a que

Re: what's the point of rpython?

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* the performance for > a single-threaded program (and for a multi-threaded but I/O-bound > program) *does not

Re: what's the point of rpython?

On Jan 18, 9:55 am, "Brendan Miller" wrote: > > The *actual* goal as outlined by their official docs is to > > implement Python in Python, at every level. > Ok fair enough. In some ways I see that as more of a purely > intellectual exercise than the practical endeavor that I assumed the > project

Re: what's the point of rpython?

>> The goals of the pypy project seems to be to create a fast python >> implementation. I may be wrong about this, as the goals seem a little >> amorphous if you look at their home page. > > The home page itself is ambiguous, and does oversell the performance > aspect. The *actual* goal as outlined

Re: what's the point of rpython?

On Jan 17, 10:37 am, "Brendan Miller" wrote: > What's the point of RPython? By this, I don't mean "What is RPython"? > I get that. I mean, why? This is more or less covered in the FAQ: "The restrictions are to ensure that type inference (and so, ultim

Re: what's the point of rpython?

On Jan 16, 9:37 pm, "Brendan Miller" wrote: > So I kind of wanted to ask this question on the pypy mailing list.. > but there's only a pypy-dev list, and I don't want to put noise on the > dev list. > > What's the point of RPython? By this, I don't

what's the point of rpython?

So I kind of wanted to ask this question on the pypy mailing list.. but there's only a pypy-dev list, and I don't want to put noise on the dev list. What's the point of RPython? By this, I don't mean "What is RPython"? I get that. I mean, why? The goals of the pypy