Re: The Future of Python Threading

Yes, but if you reduce the coupling between threads in Java (by using the recommended Python approach of communicating with Queues) you get the full speed of all the cores in your CPU. i wonder why we can't have this in Java; it will be very good for servers! > As for Java, making code thread saf

Re: The Future of Python Threading

On Aug 11, 12:59 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > Have you checked out the processing [1] package? I've currently the > impression that people want to change the whole language before they > checkout a new package. It would be nice to read a review. > > [1]http://cheeseshop.python.org/

Re: The Future of Python Threading

On Aug 11, 5:43 am, Seun Osewa <[EMAIL PROTECTED]> wrote: > > I think I've heard Guido say the last attempt at removing the Global > > Interpreter Lock (GIL) resulted in a Python that was much slower... > > What is it about Python that makes a thread-safe CPython version much > slower? Why doesn't

Re: The Future of Python Threading

On Aug 10, 5:13 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 8/10/07, Ben Sizer <[EMAIL PROTECTED]> wrote: > > > On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]> > > wrote: > > > Last I checked, multiple processes can run concurrently on multi-core > > > systems. That's a well-established way

Re: The Future of Python Threading

Nick Craig-Wood wrote: > Bjoern Schliessmann <[EMAIL PROTECTED]> >> So, how much performance gain would you get? Again, managing >> fine-grained locking can be much more work than one simple lock. > > Assuming that you are not IO bound, but compute bound and that > compute is being done in pyth

Re: The Future of Python Threading

Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > [GIL] > > That is certainly true. However the point being is that running > > on 2 CPUs at once at 95% efficiency is much better than running on > > only 1 at 99%... > > How do you define this percent efficiency? Those

Re: The Future of Python Threading

Have you checked out the processing [1] package? I've currently the impression that people want to change the whole language before they checkout a new package. It would be nice to read a review. [1] http://cheeseshop.python.org/pypi/processing -- http://mail.python.org/mailman/listinfo/python-l

Re: The Future of Python Threading

Justin T. wrote: > On Aug 10, 2:02 pm, [EMAIL PROTECTED] (Luc Heinrich) wrote: >> Justin T. <[EMAIL PROTECTED]> wrote: >>> What these seemingly unrelated thoughts come down to is a perfect >>> opportunity to become THE next generation language. >> Too late: >> >> :) >> >> -

Re: The Future of Python Threading

In article <[EMAIL PROTECTED]>, Chris Mellon <[EMAIL PROTECTED]> wrote: . . . >There's nothing "undocumented" about IPC. It's been around as a >technique for decades. Message passing is as old as the hills.

Re: The Future of Python Threading

In article <[EMAIL PROTECTED]>, Seun Osewa <[EMAIL PROTECTED]> wrote: >> I think I've heard Guido say the last attempt at removing the Global >> Interpreter Lock (GIL) resulted in a Python that was much slower... > >What is it about Python that makes a thread-safe CPython version much >slower? Wh

Re: The Future of Python Threading

Justin T. wrote: > True, but Python seems to be the *best* place to tackle this problem, > at least to me. It has a large pool of developers, a large standard > library, it's evolving, and it's a language I like :). Languages that > seamlessly support multi-threaded programming are coming, as are >

Re: The Future of Python Threading

Seun Osewa <[EMAIL PROTECTED]> writes: > What is it about Python that makes a thread-safe CPython version much > slower?... > I'm thinking it might be the reference counting approach to memory > management... Yes. In the implementation that was benchmarked, if I understand correctly, every refco

Re: The Future of Python Threading

> I think I've heard Guido say the last attempt at removing the Global > Interpreter Lock (GIL) resulted in a Python that was much slower... What is it about Python that makes a thread-safe CPython version much slower? Why doesn'ttrue threading slow down other languages like Perl and Java? I'm t

Re: The Future of Python Threading

Btw, although overly simple (single CPU system!), this benchmark is pretty interesting: http://muharem.wordpress.com/2007/07/31/erlang-vs-stackless-python-a-first-benchmark/ About the GIL: I think I've heard Guido say the last attempt at removing the Global Interpreter Lock (GIL) resulted in

Re: The Future of Python Threading

On Aug 10, 10:34 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > >I'm not an expert, but I understand that much. What greenlets do is > >force the programmer to think about concurrent programming. It doesn't > >force them to think about real threads, which is good, because a > >computer shoul

Re: The Future of Python Threading

Nick Craig-Wood wrote: [GIL] > That is certainly true. However the point being is that running > on 2 CPUs at once at 95% efficiency is much better than running on > only 1 at 99%... How do you define this percent efficiency? >>> The truth is that the future (and present reality) of almost >>>

Re: The Future of Python Threading

On Aug 10, 2:02 pm, [EMAIL PROTECTED] (Luc Heinrich) wrote: > Justin T. <[EMAIL PROTECTED]> wrote: > > What these seemingly unrelated thoughts come down to is a perfect > > opportunity to become THE next generation language. > > Too late: > > :) > > -- > Luc Heinrich Uh oh

Re: The Future of Python Threading

Justin T. <[EMAIL PROTECTED]> wrote: > What these seemingly unrelated thoughts come down to is a perfect > opportunity to become THE next generation language. Too late: :) -- Luc Heinrich -- http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

On Fri, 10 Aug 2007 16:37:19 -, "Justin T." <[EMAIL PROTECTED]> wrote: >On Aug 10, 3:52 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >> On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote: >> >Hello, >> >> >While I don't pretend to be an authority on the subject, a f

Re: The Future of Python Threading

On Aug 10, 3:57 am, Steve Holden <[EMAIL PROTECTED]> wrote: > Justin T. wrote: > > Hello, > > > While I don't pretend to be an authority on the subject, a few days of > > research has lead me to believe that a discussion needs to be started > > (or continued) on the state and direction of multi-thr

Re: The Future of Python Threading

On Aug 10, 3:52 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote: > >Hello, > > >While I don't pretend to be an authority on the subject, a few days of > >research has lead me to believe that a discussion needs to be star

Re: The Future of Python Threading

In article <[EMAIL PROTECTED]>, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > >This would of course make C extensions more complicated... It's even worse than that. One of the goals for Python is to make it easy to call into random libraries, and there are still plenty around that aren't thread-s

Re: The Future of Python Threading

brad wrote: > This is all anecdotal... threads in Python work great for me. I like > Ruby's green threads too, I forgot to mention that Ruby is moving to a GIL over green threads in v2.0 -- http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

On 8/10/07, Ben Sizer <[EMAIL PROTECTED]> wrote: > On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]> > wrote: > > "Justin T." <[EMAIL PROTECTED]> writes: > > > The truth is that the future (and present reality) of almost every > > > form of computing is multi-core, and there currently is no effectiv

Re: The Future of Python Threading

Justin T. wrote: > Hello, > > While I don't pretend to be an authority on the subject, a few days of > research has lead me to believe that a discussion needs to be started > (or continued) on the state and direction of multi-threading python. This is all anecdotal... threads in Python work great

Re: The Future of Python Threading

On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]> wrote: > "Justin T." <[EMAIL PROTECTED]> writes: > > The truth is that the future (and present reality) of almost every > > form of computing is multi-core, and there currently is no effective > > way of dealing with concurrency. > > Your post seems

Re: The Future of Python Threading

Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: > Justin T. wrote: > > > The detrimental effects of the GIL have been discussed several > > times and nobody has ever done anything about it. > > Also it has been discussed that dropping the GIL concept requires > very fine locking mechanisms ins

Re: The Future of Python Threading

In article <[EMAIL PROTECTED]>, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: >Justin T. wrote: > >> The detrimental effects of the GIL have been discussed several >> times and nobody has ever done anything about it. > >Also it has been discussed that dropping the GIL concept requires >very fine

Re: The Future of Python Threading

> All of which is avoided by designing the program to operate as > discrete processes communicating via well-defined IPC mechanisms. Hi Ben, i would like to learn more about this, have you got any links to give me so i can have a look ? -- http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

"Justin T." <[EMAIL PROTECTED]> writes: > The truth is that the future (and present reality) of almost every > form of computing is multi-core, and there currently is no effective > way of dealing with concurrency. Your post seems to take threading as the *only* way to write code for multi-core s

Re: The Future of Python Threading

In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > >I doubt that a thread on c.l.py is going to change much. It's the >python-dev and py3k lists where you'll need to take up the cudgels, >because I can almost guarantee nobody is going to take the GIL out of >2.6 or 2.7.

Re: The Future of Python Threading

On Aug 10, 5:57 am, Steve Holden <[EMAIL PROTECTED]> wrote: > Justin T. wrote: > > Hello, > > > The nice thing is that this requires a fairly doable amount of work. > > First, stackless should be integrated into the core. Then there should > > be an effort to remove the reliance on the GIL for pyth

Re: The Future of Python Threading

Justin T. wrote: > The detrimental effects of the GIL have been discussed several > times and nobody has ever done anything about it. Also it has been discussed that dropping the GIL concept requires very fine locking mechanisms inside the interpreter to keep data serialised. The overhead managi

Re: The Future of Python Threading

On 10 Aug, 12:01, "Justin T." <[EMAIL PROTECTED]> wrote: > > While I don't pretend to be an authority on the subject, a few days of > research has lead me to believe that a discussion needs to be started > (or continued) on the state and direction of multi-threading python. > > Python is not multi-

Re: The Future of Python Threading

Justin T. wrote: > Hello, > > While I don't pretend to be an authority on the subject, a few days of > research has lead me to believe that a discussion needs to be started > (or continued) on the state and direction of multi-threading python. [...] > What these seemingly unrelated thoughts come d

Re: The Future of Python Threading

On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote: >Hello, > >While I don't pretend to be an authority on the subject, a few days of >research has lead me to believe that a discussion needs to be started >(or continued) on the state and direction of multi-threading python. >

The Future of Python Threading

Hello, While I don't pretend to be an authority on the subject, a few days of research has lead me to believe that a discussion needs to be started (or continued) on the state and direction of multi-threading python. Python is not multi-threading friendly. Any code that deals with the python inte