[Python-Dev] GIL, Python 3, and MP vs. UP

[Gregory P. Smith]

On Mon, Sep 19, 2005 at 09:12:05PM +0100, Michael Hudson wrote:
> Martin Blais <blais at furius.ca> writes:
> > On 9/18/05, Guido van Rossum <guido at python.org> wrote:
> >> On 9/17/05, John J Lee <jjl at pobox.com> wrote:
> >> > I realize that not all algorithms (nor all computational problems) scale
> >> > well to MP hardware.  Is it feasible to usefully compile both MP and a UP
> >> > binaries from one Python source code base?
> >> 
> >> That's an understatement. I expect that *most* problems (even most
> >> problems that we will be programming 10-20 years from now) get little
> >> benefit out of MP.
> >
> > Some are saying it won't be a matter of choice if we want to get the
> > software to run faster (you know, that "MORE MORE MORE!" thing we all
> > seem to suffer from):
> 
> People have been saying this for _years_, and it hasn't happened yet.
> This time around it's a bit more convincing, but I reserve the right
> to remain a touch skeptical.

good! :)

> > http://www.gotw.ca/publications/concurrency-ddj.htm
> > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
> > Herb Sutter
> > March 2005
> 
> I was disappointed that that article (hey, it was the only issue of
> ddj I've ever actually bought! :) didn't consider any concurrency
> models other than shared memory threading.

Beware.  Multi-core and/or multi-threaded cpus are the only thing the
high end CPU manufacturers are able to produce today that they can
still claim to be "faster."  There is a HUGE incentive for them to
create demand for their design lest it become irrelevant and they be
forced to sell only low-margin commodity single core hardware.  This
means we'll see a ton of papers and people paid or coerced into
suggesting that this is the best thing since time sliced bread.

-g