Will multithreading make python less popular?

[Tim Rowe]

That Python is so much slower than C is yet another area where Python
can use improvement.

No, because we don't use Python where C would be more appropriate.
Sure nobody would complain if Python were faster, but it's not for
speed that we choose Python. Not speed of /execution/ that is.
Different languages have different trade-offs. Python's trade-offs
suit us. If they don't suit you, use a language with trade-offs that
do.

 

[Tim Rowe]

Hi again

I really want to imply that i am not in search of a perfect language.
Python for programming productivity is a great language but there are
some real world facts. Some people want a language that provides great
flexibility. A language can provide threads and processes and
programmer choose the way. I really believe that GIL is a design
error.

It's only an error if it gets in the way. It's the experience of a lot
of programmers that it doesn't, so it's not an error.

 

[Steve Holden]

It's only an error if it gets in the way. It's the experience of a lot
of programmers that it doesn't, so it's not an error.

And it's not a feature of the language, rather of one or two
implementations. Neither JPython not IronPython use a GIL to the best of
my knowledge, so you are still quite at liberty to use them.

regards
Steve

 

[Tim Wintle]

If such
speedups were useless or unimportant, we would not have blown our hard
earned cash replacing perfectly good older hardware, so we have to
accept the concept that speed matters and ignore those platitudes that
say otherwise.

Kind of agree (although I use a netbook at lot at the moment, and I
don't use that because of speed-ups!)

It used to be that new computers were faster than the old ones because
they ran at higher clock rates. That was great, no software changes
at all were required to benefit from the higher speed. Now, they get
the additional speed by having more cores. That's better than nothing
but making use of it requires fixing the GIL.

My opinion on this (when talking about personal computers rather than
servers) is that:

(1)
Computers *appear* faster now because they have more cores - you can
have one doing the fancy GUI effects of Compiz etc. in the background,
while the other core actually does the work.

(2)
Actual speedups aren't that related to either clock speed or cores at
the moment, they're related to the switch to 64-bit processors, the
massive increases in RAM and the increase in system bus speeds and other
IO (and of course graphics cards). I suspect that the next common
increase will be solid state hard disks.

e.g. I used to expect my computer to be paging all the time, although
I'd try to reduce it - these days I'm really upset when I see I've had
to page *anything* to disk!

Another massive increase (which I am willing to pay more for with the
work I do) is the processor cache - at first it was amazing when we got
significant level2 cache advertised on pc equipment, now I can fit
massive amounts of code into my 4mb level-2 cache *on my laptop*! That's
a huge impact for numerical work.

(3)
Multiple cores scale processing power linearly at best with the number
of cores (since you're normally going to be IO based at some point).
Perhaps the GIL will be relaxed a bit, but it's not going to have a
massive effect.

Tim Wintle

 

[Mensanator]

How old is your computer, why did you buy it, and is it the first one
you ever owned?

For most of us, I suspect, it is not our first one, and we bought it
to get a processing speedup relative to the previous one.  If such
speedups were useless or unimportant, we would not have blown our hard
earned cash replacing perfectly good older hardware, so we have to
accept the concept that speed matters and ignore those platitudes that
say otherwise.

It used to be that new computers were faster than the old ones because
they ran at higher clock rates.  That was great, no software changes
at all were required to benefit from the higher speed.  Now, they get
the additional speed by having more cores.  That's better than nothing
but making use of it requires fixing the GIL.

When I run I Python program, the Windows task manager shows both
cores running (usually a 60/40 split) for an overall 50% usage.

What am I actually seeing? If Python only uses one of the cores,
why do both light up? Is everything much more complicated (due to
OS scheduling, etc.) than the simple explanations of GIL?

 

[Paul Rubin]

No, because we don't use Python where C would be more appropriate.

C is basically never appropriate. C should be outlawed by Congress
with the ban enforced by roving pie-throwing squads <wink>. If a
Python program is too slow, making Python faster is far preferable to
switching to C.

Sure nobody would complain if Python were faster, but it's not for
speed that we choose Python. Not speed of /execution/ that is.

I would say, slow execution is a drawback that we put up with in order
to gain benefits of Python programming that are mostly unrelated to
the causes of the slowness. The slowness itself can be addressed by
technical means, such as native-code compilation and eliminating the
GIL. I believe (for example) that the PyPy project is doing both of
these.

Different languages have different trade-offs. Python's trade-offs
suit us. If they don't suit you, use a language with trade-offs that
do.

I don't think Python's slowness is inherent in the language. It's
mostly a shortcoming of the implementation that should be fixed like
any other such shortcoming.

 

[Falcolas]

Right, that's basically the issue here: the cost of using multiple
Python processes is unnecessarily high.  If that cost were lower then
we could more easily use multiple cores to make oru apps faster.

I was actually referring to the time cost of researching or developing
a parallel execution algorithm which would be suitable for multiple
processes.

The system overhead of using the Python multiprocess module is fairly
negligible for the systems I work on.

Different languages have different trade-offs. Python's trade-offs
suit us. If they don't suit you, use a language with trade-offs that
do.

+1

~G

 

[Paul Rubin]

It's only an error if it gets in the way. It's the experience of a lot
of programmers that it doesn't, so it's not an error.

It does get in the way of quite a few of us, but I wouldn't exactly
call it an error. It was a sensible decision at the time it was made.
Changing technology and changing requirements have turned it into a
problem since then.

A sensible decision later becoming a problem is a fairly normal
occurrence, not just in software but in just about every area of human
endeavor. The sensible response to the changed landscape is to
recognize the problem and figure out what to do about it. Denying the
problem's existence is not sensible.

 

[Steve Holden]

If such
speedups were useless or unimportant, we would not have blown our hard
earned cash replacing perfectly good older hardware, so we have to
accept the concept that speed matters and ignore those platitudes that
say otherwise.

Kind of agree (although I use a netbook at lot at the moment, and I
don't use that because of speed-ups!) [...]
(3)
Multiple cores scale processing power linearly at best with the number
of cores (since you're normally going to be IO based at some point).
Perhaps the GIL will be relaxed a bit, but it's not going to have a
massive effect.

There are significant classes of problems which *are* compute bound, and
as computers are applied more and more to planning and design problems
it seems likely that kind of application will become more significant.

In twenty years time our laptops will probably be continually optimizing
aspects of our lives using advanced linear algebra algorithms over
matrices with hundreds or thousands of millions of elements. I wouldn't
like Python to be excluded from solving such problems, and others we
currently fail to foresee.

Though my own interest does tend to lie in the areas where interaction
of various kinds dominates the need for large chunks of processing
power, I can't ignore the obvious. Many compute-bound problems do exist,
and they are important.

regards
Steve

 

[Steve Holden]

C is basically never appropriate. C should be outlawed by Congress
with the ban enforced by roving pie-throwing squads <wink>. If a
Python program is too slow, making Python faster is far preferable to
switching to C.

Unfortunately it's also far more difficult. I speak with the experience
of the "Need for Speed" sprint behind me: the accumulated brainpower at
that event should have been able to pick all the low-hanging fruit, and
yet the resultant net speedup was worthwhile, but definitely not immense.

I would say, slow execution is a drawback that we put up with in order
to gain benefits of Python programming that are mostly unrelated to
the causes of the slowness. The slowness itself can be addressed by
technical means, such as native-code compilation and eliminating the
GIL. I believe (for example) that the PyPy project is doing both of
these.

And IronPython and JPython already have. (How many times do I have to
say this before somebody with access to decent multi-processor hardware
runs some actual benchmarks? Where's snakebite.org when you need it? ;-)

I don't think Python's slowness is inherent in the language. It's
mostly a shortcoming of the implementation that should be fixed like
any other such shortcoming.

Reasonable, and true. Some people talk about the GIL as though it were
something other than an implementation artifact.

What Guido doesn't seem to have accepted yet is that slowing [C]Python
down by 50% on a single-processor CPU will actually be a worthwhile
tradeoff in ten years time, when nothing will have less than eight cores
and the big boys will be running at 64 kilo-cores.

regards
Steve

 

[MRAB]

Tim Wintle wrote:
[snip]

Yes, we're coming to a point where we're going to have tens of cores in
a chip, but by that time someone far cleverer than me (possibly someone
who's on this list) will have solved that problem. The top experts in
many fields use Python, and if they weren't able to make use of multiple
core chips, then there wouldn't be any demand for them.

Perhaps we should ask Guido who it is; after all, he's the one with the
time machine!

 

[Terry Reedy]

I would say, slow execution is a drawback that we put up with in order
to gain benefits of Python programming that are mostly unrelated to
the causes of the slowness. The slowness itself can be addressed by
technical means, such as native-code compilation and eliminating the
GIL.

Given that the GIL remains to make Python run faster in the usual (up to
now, at least) case of 1 processor, that seems a strange statement.

 

[Steve Holden]

Given that the GIL remains to make Python run faster in the usual (up to
now, at least) case of 1 processor, that seems a strange statement.

From a historical perspective, that's going to seem like a very

parochial PoV in (say) twenty years.

regards
Steve

 

[Steve Holden]

It's only an error if it gets in the way. It's the experience of a lot
of programmers that it doesn't, so it's not an error.

[...] Denying the
problem's existence is not sensible.

And if wishes were horses then beggars would ride

 

[Paul Rubin]

Given that the GIL remains to make Python run faster in the usual (up
to now, at least) case of 1 processor, that seems a strange statement.

We've had this discussion before. The 1-processor slowdown that you
refer to comes from replacing the GIL with the blunt instrument of a
lock around each reference count operation. That has the advantage of
not breaking CPython in a million places, but has the drawback of
taking a big performance hit. The long term fix is to replace
reference counts with a tracing GC. That is apparently not feasible
in the framework of CPython and the many extension modules that have
been written for it, so it would have to be accompanied by an
implementation switch (e.g. PyPy).

Steve Holden has mentioned Jython and Ironpython a few times in this
thread. Those are reasonable proofs of the concept of a GIL-less
Python, but for various reasons (spelled J-V-M and W-i-n-d-o-w-s) are
not all that suitable for many current Python users.

 

[Steve Holden]

Tim Wintle wrote:
[snip]

Yes, we're coming to a point where we're going to have tens of cores in
a chip, but by that time someone far cleverer than me (possibly someone
who's on this list) will have solved that problem. The top experts in
many fields use Python, and if they weren't able to make use of multiple
core chips, then there wouldn't be any demand for them.

Perhaps we should ask Guido who it is; after all, he's the one with the
time machine!

But he clearly hasn't been using it lately.

<heresy>Perhaps it's time Python stopped being a dictatorship?</heresy>

regards
Steve

 

[Steve Holden]

When I run I Python program, the Windows task manager shows both
cores running (usually a 60/40 split) for an overall 50% usage.

What am I actually seeing? If Python only uses one of the cores,
why do both light up? Is everything much more complicated (due to
OS scheduling, etc.) than the simple explanations of GIL?

You are seeing your Python program running on one core, and the usual
Windows crap keeping the other one busy.

regards
Steve

 

[Mensanator]

You are seeing your Python program running on one core, and the usual
Windows crap keeping the other one busy.

I thought of that, but the usual Windows crap accounts for only a
couple percent prior to the Python program running. Christian Heimes
answer sounds more realistic.

But what do I know?

 

[Steve Holden]

I thought of that, but the usual Windows crap accounts for only a
couple percent prior to the Python program running. Christian Heimes
answer sounds more realistic.

But what do I know?

At least as much as I do, probably.

regards
Steve

 

[Steven D'Aprano]

And it's not a feature of the language, rather of one or two
implementations. Neither JPython not IronPython use a GIL to the best of
my knowledge, so you are still quite at liberty to use them.

I found this interesting benchmark on the relative speeds of CPython 2.3,
IronPython 0.1 and Jython 2.1. It's from six years ago, so not exactly
reporting on the state of the art, but it suggests to me that IronPython is
faster at the fundamentals but much slower at some things.

http://www.python.org/~jeremy/weblog/031209a.html