Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   global interpreter lock (http://www.velocityreviews.com/forums/t348229-global-interpreter-lock.html)

Paul Rubin 08-19-2005 09:16 AM

Re: global interpreter lock
 
km <km@mrna.tn.nic.in> writes:
> is true parallelism possible in python ? or atleast in the coming versions ?
> is global interpreter lock a bane in this context ?


http://poshmodule.sf.net

Robin Becker 08-19-2005 09:33 AM

Re: global interpreter lock
 
Paul Rubin wrote:
> km <km@mrna.tn.nic.in> writes:
>
>>is true parallelism possible in python ? or atleast in the coming versions ?
>>is global interpreter lock a bane in this context ?

>
>
> http://poshmodule.sf.net


Is posh maintained? The page mentions 2003 as the last date.
--
Robin Becker


Paul Rubin 08-19-2005 09:40 AM

Re: global interpreter lock
 
Robin Becker <robin@reportlab.com> writes:
> > http://poshmodule.sf.net

> Is posh maintained? The page mentions 2003 as the last date.


Dunno, and I suspect not. I've been wondering about it myself.

Grant Edwards 08-19-2005 02:28 PM

Re: global interpreter lock
 
On 2005-08-20, km <km@mrna.tn.nic.in> wrote:

> is true parallelism possible in python?


No, not for some values of "true parallelism".

> or atleast in the coming versions?


Not that I'm aware of.

> is global interpreter lock a bane in this context?


In what context?

--
Grant Edwards grante Yow! I think I'll do BOTH
at if I can get RESIDUALS!!
visi.com

Bryan Olson 08-19-2005 03:37 PM

Re: global interpreter lock
 
km wrote:
> Hi all,
>
> is true parallelism possible in python ? or atleast in the
> coming versions ? is global interpreter lock a bane in this
> context ?


No; maybe; and currently, not usually.

On a uniprocessor system, the GIL is no problem. On multi-
processor/core systems, it's a big loser.


--
--Bryan

Donn Cave 08-19-2005 05:26 PM

Re: global interpreter lock
 
In article <91nNe.620$zD3.198@newssvr29.news.prodigy.net>,
Bryan Olson <fakeaddress@nowhere.org> wrote:

> km wrote:
> > Hi all,
> >
> > is true parallelism possible in python ? or atleast in the
> > coming versions ? is global interpreter lock a bane in this
> > context ?

>
> No; maybe; and currently, not usually.
>
> On a uniprocessor system, the GIL is no problem. On multi-
> processor/core systems, it's a big loser.


I rather suspect it's a bigger winner there.

Someone who needs to execute Python instructions in parallel
is out of luck, of course, but that has to be a small crowd.
I would have to assume that in most applications that need
the kind of computational support that implies, are doing most
of the actual computation in C, in functions that run with the
lock released. Rrunnable threads is 1 interpreter, plus N
"allow threads" C functions, where N is whatever the OS will bear.

Meanwhile, the interpreter's serial concurrency limits the
damage. The unfortunate reality is that concurrency is a
bane, so to speak -- programming for concurrency takes skill
and discipline and a supportive environment, and Python's
interpreter provides a cheap and moderately effective support
that compensates for most programmers' unrealistic assessment
of their skill and discipline. Not that you can't go wrong,
but the chances you'll get nailed for it are greatly reduced -
especially in an SMP environment.

Donn Cave, donn@u.washington.edu

km 08-20-2005 01:47 AM

global interpreter lock
 
Hi all,

is true parallelism possible in python ? or atleast in the coming versions ?
is global interpreter lock a bane in this context ?

regards,
KM

Paul Rubin 08-20-2005 07:32 AM

Re: global interpreter lock
 
Mike Meyer <mwm@mired.org> writes:
> > I don't see much point in trying to convince programmers that
> > they don't really want concurrent threads. They really do. Some
> > don't know how to use them, but that's largely because they
> > haven't had them. I doubt a language for thread-phobes has much
> > of a future.

>
> The real problem is that the concurrency models available in currently
> popular languages are still at the "goto" stage of language
> development. Better models exist, have existed for decades, and are
> available in a variety of languages.


But Python's threading system is designed to be like Java's, and
actual Java implementations seem to support concurrent threads just fine.

One problem with Python is it doesn't support synchronized objects
nearly as conveniently as Java, though. You need messy explicit
locking and unlocking all over the place. But it's not mysterious how
to do those explicit locks; it's just inconvenient.

Alan Kennedy 08-20-2005 01:30 PM

Re: global interpreter lock
 
[km]
> is true parallelism possible in python ?


cpython: no.
jython: yes.
ironpython: yes.

> or atleast in the coming versions ?


cpython: unknown.
pypy: don't have time to research. Anyone know?

> is global interpreter lock a bane in this context ?


beauty/bane-is-in-the-eye-of-the-beholder-ly y'rs

--
alan kennedy
------------------------------------------------------
email alan: http://xhaus.com/contact/alan

Donn Cave 08-20-2005 04:00 PM

Re: global interpreter lock
 
Quoth Paul Rubin <http://phr.cx@NOSPAM.invalid>:
| Mike Meyer <mwm@mired.org> writes:

|> The real problem is that the concurrency models available in currently
|> popular languages are still at the "goto" stage of language
|> development. Better models exist, have existed for decades, and are
|> available in a variety of languages.
|
| But Python's threading system is designed to be like Java's, and
| actual Java implementations seem to support concurrent threads just fine.

I don't see a contradiction here. "goto" is "just fine", too --
you can write excellent programs with goto. 20 years of one very
successful software engineering crusade against this feature have
made it a household word for brokenness, but most current programming
languages have more problems in that vein that pass without question.
If you want to see progress, it's important to remember that goto
was a workable, useful, powerful construct that worked fine in the
right hands - and that wasn't enough.

Anyway, to return to the subject, I believe if you follow this
subthread back you will see that it has diverged a little from
simply whether or how Python could support SMP.

Mike, care to mention an example or two of the better models you
had in mind there?

Donn Cave, donn@drizzle.com


All times are GMT. The time now is 11:11 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.