Guido's Blog: It isn't Easy to Remove the GIL

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Guido's Blog: It isn't Easy to Remove the GIL

Stephen McInerney
[A great discussion of something complex which I was too timid to ask about
on the list:]
Article: http://www.artima.com/weblogs/viewpost.jsp?thread=214235
Responses: http://www.artima.com/forums/flat.jsp?forum=106&thread=214235

- Essentially the GIL will not go away and the C-implementation of Python
will stay single-threaded, unless some code wizard _other than Guido_ goes
through the effort of
removing it (e.g. for 3.0), and showing that its removal doesn't slow down
single-threaded Python code.
- Includes description of the unpromising prior attempt at this on a fork of
1.5 with 2x slowdown

Guido> "[...] I'd welcome it if someone did another experiment along the
lines of Greg's patch (which I haven't found online), and 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 decrease.

I would also be happy if someone volunteered to maintain a GIL-free fork of
Python, in case that the single-threaded performance goal can't be met but
there is significant value for multi-threaded CPU-bound applications. We
might even end up with all the changes permanently part of the code base,
but enabled only on request at compile time.

However, I want to warn that there are many downsides to removing the GIL.
It complicates life for extension modules, who can no longer expect that
they are invoked in a "safe zone" protected by the GIL -- as soon as an
extension has any global mutable data, will have to be prepared with
concurrent calls from multiple threads. There might also be changes in the
Python/C API necessitated by the need to lock certain objects for the
duration of a sequence of calls.

While it is my personal opinion, based upon the above considerations, that
there isn't enough value in removing the GIL to warrant the effort, I will
welcome and support attempts to show that times have changed. However, there
is no point in pleading alone -- Python is open source and I have my hands
full dealing with the efforts to produce a quality 3.0 language definition
and implementation on time. I want to point out one more time that the
language doesn't require the GIL -- it's only the CPython virtual machine
that has historically been unable to shed it."

_________________________________________________________________
Get a FREE small business Web site and more from Microsoft® Office Live!
http://clk.atdmt.com/MRT/go/aub0930003811mrt/direct/01/


_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Shannon -jj Behrens
On 9/11/07, Stephen McInerney <[hidden email]> wrote:

> [A great discussion of something complex which I was too timid to ask about
> on the list:]
> Article: http://www.artima.com/weblogs/viewpost.jsp?thread=214235
> Responses: http://www.artima.com/forums/flat.jsp?forum=106&thread=214235
>
> - Essentially the GIL will not go away and the C-implementation of Python
> will stay single-threaded, unless some code wizard _other than Guido_ goes
> through the effort of
> removing it (e.g. for 3.0), and showing that its removal doesn't slow down
> single-threaded Python code.
> - Includes description of the unpromising prior attempt at this on a fork of
> 1.5 with 2x slowdown
>
> Guido> "[...] I'd welcome it if someone did another experiment along the
> lines of Greg's patch (which I haven't found online), and 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 decrease.
>
> I would also be happy if someone volunteered to maintain a GIL-free fork of
> Python, in case that the single-threaded performance goal can't be met but
> there is significant value for multi-threaded CPU-bound applications. We
> might even end up with all the changes permanently part of the code base,
> but enabled only on request at compile time.
>
> However, I want to warn that there are many downsides to removing the GIL.
> It complicates life for extension modules, who can no longer expect that
> they are invoked in a "safe zone" protected by the GIL -- as soon as an
> extension has any global mutable data, will have to be prepared with
> concurrent calls from multiple threads. There might also be changes in the
> Python/C API necessitated by the need to lock certain objects for the
> duration of a sequence of calls.
>
> While it is my personal opinion, based upon the above considerations, that
> there isn't enough value in removing the GIL to warrant the effort, I will
> welcome and support attempts to show that times have changed. However, there
> is no point in pleading alone -- Python is open source and I have my hands
> full dealing with the efforts to produce a quality 3.0 language definition
> and implementation on time. I want to point out one more time that the
> language doesn't require the GIL -- it's only the CPython virtual machine
> that has historically been unable to shed it."

<jj crazy mode>
For several months, I've been fascinated by the idea of a Pythonic
version of Erlang.  The most important thing is to combine
Erlang-style concurrency with Python's elegant syntax.

However, there are some real challenges here.  In Python, classes,
instances, modules, etc. are dicts, which is a fundamental problem
when trying to support Erlang-style concurrency.  Message passing
(within process) is cheap in Erlang because they can pass by reference
instead of by value and rest assured that the data will not be
modified.  Remember, Erlang gets away from the need for locks because
two "processes" cannot modify the same data.  That's a real challenge
for a language like Python where even writing a def is adding a new
value to a dict (for the class or module).  Sure, you can make it so
that you can only pass tuples of strings and ints, but that's no fun
because what you probably want to pass is some combination of dicts,
lists, and instances.

In Haskell, there's a tree data type that is optimized for
non-destructive updates.  Just like you can create a new list by
consing an element with another list without harming the other list,
you can do the same thing with a tree.  Of course, it's a little less
efficient than "updating" a list.  I wonder if it'd be possible to
replace Python's reliance on dicts with such a tree.  Hence, adding a
new def would update your own processes view of the tree without
harming the old tree which all the other processes are pointing to.

There are other difficulties, but if I actually had two years of free
time and about 20 extra IQ points, and money to live on, I'd probably
take a shot at it ;)

/me giggles
</jj crazy mode>

Happy Hacking!
-jj

--
http://jjinux.blogspot.com/
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
I thought the discussion was very interesting. I think true parallel
programming is the challenge of our time, so I'm quite disappointed
that the Python powers that be do not seem to feel any imperative to
address it. I've always been kind of assuming that Python would
provide a "pythonic" parallel programming paradigm that would "just
work" and be as elegant as the rest of the language.

Regarding the non-modifiable data idea, Python already provide "set"
and "frozenset". Maybe the same sort of arrangement could be done with
dicts, instances, etc. Then you could pass frozen objects between
threads.

-Andy
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Guido van Rossum
On 9/13/07, Andy Wiggin <[hidden email]> wrote:
> I thought the discussion was very interesting. I think true parallel
> programming is the challenge of our time, so I'm quite disappointed
> that the Python powers that be do not seem to feel any imperative to
> address it. I've always been kind of assuming that Python would
> provide a "pythonic" parallel programming paradigm that would "just
> work" and be as elegant as the rest of the language.

I'm sorry, but this attitude just really pisses me off. Python is the
work of many people. If you want something to happen, make it happen.
Don't wait for someone else to solve your problem for you.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

William Deegan-2
In reply to this post by Stephen McInerney
...

> However, I want to warn that there are many downsides to removing the GIL.
> It complicates life for extension modules, who can no longer expect that
> they are invoked in a "safe zone" protected by the GIL -- as soon as an
> extension has any global mutable data, will have to be prepared with
> concurrent calls from multiple threads. There might also be changes in the
> Python/C API necessitated by the need to lock certain objects for the
> duration of a sequence of calls.
...

I don't know much about the implementation of extension modules, but
might it work to effectively have GIL around modules which don't
register their ability to handle multiple threads?

So python's engine would run multi-threaded, when it calls an
extension module, it would use a lock on entry/exit to any module
which is not thread aware?

I'm sure there's huge holes in this idea, but I thought I'd put it out there.

-Bill
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Adam Ulvi
In reply to this post by Stephen McInerney
I thought that telling people to "write it yourself if you want it so damn much" was the open-source version of Godwin's law.  ;-)

Seriously, I wasn't aware the GIL was such a hot-button, I'll try to avoid bringing it up in polite company from now on.

- A

----- Original Message ----
From: Guido van Rossum <[hidden email]>
To: Andy Wiggin <[hidden email]>
Cc: [hidden email]
Sent: Friday, September 14, 2007 12:23:29 PM
Subject: Re: [Baypiggies] Guido's Blog: It isn't Easy to Remove the GIL

On 9/13/07, Andy Wiggin <[hidden email]> wrote:
> I thought the discussion was very interesting. I think true parallel
> programming is the challenge of our time, so I'm quite disappointed
> that the Python powers that be do not seem to feel any imperative to
> address it. I've always been kind of assuming that Python would
> provide a "pythonic" parallel programming paradigm that would "just
> work" and be as elegant as the rest of the language.

I'm sorry, but this attitude just really pisses me off. Python is the
work of many people. If you want something to happen, make it happen.
Don't wait for someone else to solve your problem for you.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies





       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
In reply to this post by Guido van Rossum
> I'm sorry, but this attitude just really pisses me off. Python is the
> work of many people. If you want something to happen, make it happen.
> Don't wait for someone else to solve your problem for you.

I think it's a point well taken. It doesn't help the situation to
express this disappointment.

I do think that running single-threaded on the commodity machines of
the near future will be a handicap for any program, and running one
process per core is not going to work too well either (unless you're
IO-bound), so the GIL might limit where and when one can use pure
Python (or at least the CPython VM) as a solution. Hence my
disappointment, as I'd use Python everywhere if I could.
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Guido van Rossum
On 9/14/07, Andy Wiggin <[hidden email]> wrote:

> > I'm sorry, but this attitude just really pisses me off. Python is the
> > work of many people. If you want something to happen, make it happen.
> > Don't wait for someone else to solve your problem for you.
>
> I think it's a point well taken. It doesn't help the situation to
> express this disappointment.
>
> I do think that running single-threaded on the commodity machines of
> the near future will be a handicap for any program, and running one
> process per core is not going to work too well either (unless you're
> IO-bound), so the GIL might limit where and when one can use pure
> Python (or at least the CPython VM) as a solution. Hence my
> disappointment, as I'd use Python everywhere if I could.

You haven't really read the blogs, have you? The high-level bit is
that there are no easy solutions. Concurrency is hard, period.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Dennis Allison
In reply to this post by Andy Wiggin

Software that takes advantage of multi-core machines is going to be hard
to write on a number of counts -- python is not the only system which will
have to contend with shared locks.  At the moment, most people appear to
just ignore the issue and accept whatever degredation occurs due to
cross processor sharing of the GIL.

It would be nice if we had some measured data on the performance cost in
multicore machines due to the GIL--itself, hard to measure and quantify.

Guido mentioned to me once that there had been an attempt to replace the
GIL (a simple and low overhead solution) with local locks, but that the
result was slow and unstable.   I do know who did it.  Another approach
might be to use wait-free locking techniques and eliminates the GIL by
eliminating locks (that is, replacing locks with compare-and-swap) at the
cost of possibly redundant computation. It is not clear whether this is a
good trade--and would make for a nice project.  



On Fri, 14 Sep 2007, Andy Wiggin wrote:

> > I'm sorry, but this attitude just really pisses me off. Python is the
> > work of many people. If you want something to happen, make it happen.
> > Don't wait for someone else to solve your problem for you.
>
> I think it's a point well taken. It doesn't help the situation to
> express this disappointment.
>
> I do think that running single-threaded on the commodity machines of
> the near future will be a handicap for any program, and running one
> process per core is not going to work too well either (unless you're
> IO-bound), so the GIL might limit where and when one can use pure
> Python (or at least the CPython VM) as a solution. Hence my
> disappointment, as I'd use Python everywhere if I could.

_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
In reply to this post by Guido van Rossum
I'm not quite following you... I'm just talking about what the
hardware is going to be like, and my understanding of the type of
software that will be able to take advantage of it. The complexity is
being driven by our good friends the CPU vendors, and the realities of
device physics and IC packaging. Whether or not it's easy to program,
I think that's the kind of hardware we're going to get.
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Guido van Rossum
Read this:

http://marknelson.us/2007/07/30/multicore-panic/

On 9/14/07, Andy Wiggin <[hidden email]> wrote:
> I'm not quite following you... I'm just talking about what the
> hardware is going to be like, and my understanding of the type of
> software that will be able to take advantage of it. The complexity is
> being driven by our good friends the CPU vendors, and the realities of
> device physics and IC packaging. Whether or not it's easy to program,
> I think that's the kind of hardware we're going to get.
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Charles Merriam
At the risk of fanning the flames, here is a random vignettes:

Many years ago at a dinner with Bjarne Stroustrup (of C++ fame),
Bjarne laid out , on the back of a napkin, a graph of parallel
programming fads over thirty years.  His premise was that it took
about sixty operations to fully switch a process and about one to just
change the PC register.  On one point of the fad, everything was a
separate process communication over RPC (or a common file, or a shared
buffer, or, now, an XML stream) and people would complain about the
swizzeling involved and the cost of switching processes.   A new fad
would emerge where a bit more careful specification was required by
the programmer in return for less swizzeling  and better performance.
 Another fad would move to light weight threads with more care
required by programmers to avoid subtle bugs.  Eventually, each thread
would be required to mange its own concurrency system in a blindly
fast execution.  Then the cycle would reverse, with some new
improvements preventing esoteric bugs at the cost of some performance.
  He charted the period at about eight years.

Now in Python, we worry about the overhead of the interpreter
footprint.  Are we still just chasing this cycle around?


On 9/14/07, Guido van Rossum <[hidden email]> wrote:

> Read this:
>
> http://marknelson.us/2007/07/30/multicore-panic/
>
> On 9/14/07, Andy Wiggin <[hidden email]> wrote:
> > I'm not quite following you... I'm just talking about what the
> > hardware is going to be like, and my understanding of the type of
> > software that will be able to take advantage of it. The complexity is
> > being driven by our good friends the CPU vendors, and the realities of
> > device physics and IC packaging. Whether or not it's easy to program,
> > I think that's the kind of hardware we're going to get.
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Baypiggies mailing list
> [hidden email]
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
In reply to this post by Guido van Rossum
That's certainly the story we'd all like to hear. There's probably
some truth to it besides. His assumption that core multiplication will
follow Moore's law may not be right, though. It may go faster because
the thermal savings are non-linear with CPU frequency, so we may get
more and slower cores sooner than his model predicts. His point that
the future is uncertain and that there are countervailing forces is
undeniable.

-Andy
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Dennis Reinhardt
In reply to this post by Guido van Rossum
At 05:03 PM 9/14/2007, Andy Wiggin wrote:
>His assumption that core multiplication will
>follow Moore's law may not be right, though.


Well, sorta.  Moore's law is a transistor count scaling law.  More
transistors is a great fit for direct increase in cores.

>It may go faster because
>the thermal savings are non-linear with CPU frequency, so we may get
>more and slower cores sooner than his model predicts.

Ignoring threshold effects (a huge assumption), joint reductions in voltage
and frequency yield a 3rd order (X**3) reduction in power.

The reduction in frequency maps into a direct reduction in throughput,
ignoring fact that IO and off-chip peripheral are probably not reduced.

The performance scaling of more processors often follows Amdahl's law, a
form of diminishing returns.  As a rule of thumb, and IIRC, two processors
at speed X have the performance of a single processor at speed 1.8X.  It
gets less favorable with more processors so 4 processors  at speed X are
worth about 1 processor at 3X.  Again, rules of thumb and very dependent on
the specifics.

Chip manufactures are *well aware* of the thermal vs. number of cores and
any roadmap has that already baked in.

regards, Dennis
  ---------------------------------
| Dennis    | [hidden email]    |
| Reinhardt | http://www.dair.com |
  ---------------------------------

_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
> Ignoring threshold effects (a huge assumption), joint reductions in voltage
> and frequency yield a 3rd order (X**3) reduction in power.

The example I'm looking at, the chip vendor reduces core vdd by 10%
(1.2 -> 1.09) and core clock frequency by 30% (3.0GHz -> 2.3GHz) and
this cuts power by 50%. This allows them to put two of these things
(in essence, at least) in one package because there within the thermal
budget.

So you can get 2 cores at 3GHz or 4 cores at 2.3GHz, for roughly the
same price I am told. The vendor claims a 70% increase in peak flops
for the 4 core version.

Ignoring the vdd scaling (since basically no one cares about core vdd
when they're buying CPUs), this seems non-linear to me because you
give up 30% in CPU frequency and get 50% in power savings.

I'm guessing that your assumptions are more in terms of moving from
one process node to  the next, whereas the example I'm looking at (I'm
pretty sure) is based on two thermally bound designs at the same
process node. Also, within one process node, I believe the opportunity
for voltage scaling is limited, so I don't believe you can freely
scale it the way you can freely scale (down, at least) clock speed.

Regards,
Andy
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Dennis Reinhardt
In reply to this post by Dennis Reinhardt
At 08:55 PM 9/14/2007, Andy Wiggin wrote:

>DR> Ignoring threshold effects (a huge assumption), joint reductions in
>voltage
> > and frequency yield a 3rd order (X**3) reduction in power.
>AW>I'm guessing that your assumptions are more in terms of moving from
>one process node to  the next, whereas the example I'm looking at (I'm
>pretty sure) is based on two thermally bound designs at the same
>
>AW>The example I'm looking at, the chip vendor reduces core vdd by 10%
>(1.2 -> 1.09) and core clock frequency by 30% (3.0GHz -> 2.3GHz) and
>this cuts power by 50%. This allows them to put two of these things
>(in essence, at least) in one package because there within the thermal
>budget.


Actually, no, I am not talking about different processes.

Circuit power (CMOS) is proportional to V**2f where V is voltage and f is
operating frequency.  Where V is significantly greater than transistor
threshold voltage (0.7 volts), then f is proportional to V and power is
proportional to f**3, as I said above.

In the example you cite, working with CV**2f and substituting 10 and 30%,
we see power reduction of .9**2 x .7 = .57, consistent with the 50% you
cite allowing for the granularity of the numbers.

We are talking about the same basic situation.

Dennis
  ---------------------------------
| Dennis    | [hidden email]    |
| Reinhardt | http://www.dair.com |
  ---------------------------------

_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Adam Hupp-2
In reply to this post by Stephen McInerney
On 9/11/07, Stephen McInerney <[hidden email]> wrote:

> - Includes description of the unpromising prior attempt at this on a fork of
> 1.5 with 2x slowdown

According to[0], a large part of the 2X slowdown was lock contention
around dictionary access:

> The largest problem was dealing with dictionaries.
> Since you never knew whether a specific dictionary was shared (between
> threads) or not, you always had to lock the access. And since all namespaces
> use dictionaries...

[0] http://mail.python.org/pipermail/python-dev/2001-August/017099.html

One solution to this would be implementing dict with Cliff Click's
lock-free hashmap, described here:

http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html

A presentation on it:

http://video.google.com/videoplay?docid=2139967204534450862&q=cliff+click&total=197&start=0&num=10&so=0&type=search&plindex=0

That of course does not solve visibility problems but at least the
dict state is guaranteed to be consistent.

--
Adam Hupp | http://hupp.org/adam/
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Shannon -jj Behrens
In reply to this post by Adam Ulvi
In a former life, I was hanging out at a PHP users' group meeting, and
I asked Rasmus Lerdorf what he had against exceptions and why he had
left them out the language.  This was in the PHP 3 days.  He said, "I
just don't know how to implement them.  If you can figure out how to
do it, I'd be happy to include them."  Hahaha.  Ah, history!

(I'm not really trying to prove anything--it's just a funny story.)

-jj

On 9/14/07, Adam Ulvi <[hidden email]> wrote:

> I thought that telling people to "write it yourself if you want it so damn much" was the open-source version of Godwin's law.  ;-)
>
> Seriously, I wasn't aware the GIL was such a hot-button, I'll try to avoid bringing it up in polite company from now on.
>
> - A
>
> ----- Original Message ----
> From: Guido van Rossum <[hidden email]>
> To: Andy Wiggin <[hidden email]>
> Cc: [hidden email]
> Sent: Friday, September 14, 2007 12:23:29 PM
> Subject: Re: [Baypiggies] Guido's Blog: It isn't Easy to Remove the GIL
>
> On 9/13/07, Andy Wiggin <[hidden email]> wrote:
> > I thought the discussion was very interesting. I think true parallel
> > programming is the challenge of our time, so I'm quite disappointed
> > that the Python powers that be do not seem to feel any imperative to
> > address it. I've always been kind of assuming that Python would
> > provide a "pythonic" parallel programming paradigm that would "just
> > work" and be as elegant as the rest of the language.
>
> I'm sorry, but this attitude just really pisses me off. Python is the
> work of many people. If you want something to happen, make it happen.
> Don't wait for someone else to solve your problem for you.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Baypiggies mailing list
> [hidden email]
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
>
>
>
>
>
> ____________________________________________________________________________________
> Need a vacation? Get great deals
> to amazing places on Yahoo! Travel.
> http://travel.yahoo.com/
> _______________________________________________
> Baypiggies mailing list
> [hidden email]
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>


--
http://jjinux.blogspot.com/
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Guido's Blog: It isn't Easy to Remove the GIL

Andy Wiggin
FYI: I'm sure many of you have already seen this since it's been out
for almost a year, but if not, you might find it an interesting
overview of parallel/multi-core computing.

  http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html

and associated wiki

  http://view.eecs.berkeley.edu/wiki/Main_Page

-Andy
_______________________________________________
Baypiggies mailing list
[hidden email]
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies