Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!bcyclone04.am1.xlned.com!bcyclone04.am1.xlned.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
References: <jbijea5ph9m7sd9gqvp64ci1j708u5vkuq@4ax.com> <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> <mailman.19009.1424611670.18130.python-list@python.org> <pqrjeahei7v04lu0nqgsm01jrebj10hj8e@4ax.com> <mailman.19018.1424625741.18130.python-list@python.org> <87fv9xdb22.fsf@jester.gateway.pace.com> <54ea7ff4$0$12983$c3e8da3$5496439d@news.astraweb.com> <87zj85bcyu.fsf@jester.gateway.pace.com>
From: Ryan Stuart <ryan.stuart.85@gmail.com>
Date: Mon, 23 Feb 2015 03:16:39 +0000
Subject: Re: Future of Pypy?
To: Paul Rubin <no.email@nospam.invalid>, python-list@python.org
Content-Type: multipart/alternative; boundary=047d7b2e1365b0c1df050fb8d401
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19048.1424661403.18130.python-list@python.org>
Lines: 227
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86186

--047d7b2e1365b0c1df050fb8d401
Content-Type: text/plain; charset=UTF-8

On Mon Feb 23 2015 at 12:05:46 PM Paul Rubin <no.email@nospam.invalid>
wrote:

> I don't see what the big deal is.  I hear tons of horror stories about
> threads and I believe them, but the thing is, they almost always revolve
> around acquiring and releasing locks in the wrong order, forgetting to
> lock things, stuff like that.  So I've generally respected the terror
> and avoided programming in that style, staying with a message passing
> style that may take an efficiency hit but seems to avoid almost all
> those problems.  TM also helps with lock hazards and it's a beautiful
> idea--I just haven't had to use it yet.  The Python IRC channel seems to
> rage against threads and promote Twisted for concurrency, but Twisted
> has always reminded me of Java.  I use threads in Python all the time
> and haven't gotten bitten yet.
>
>
Many people have written at length about why it's bad. The most recent
example I have come across is here ->
https://glyph.twistedmatrix.com/2014/02/unyielding.html

It's not a specific Python problem. I must be in the limited crowd that
believes that the GIL is a *feature* of Python. Then again, maybe it isn't
so limited since the GIL-less python implementations haven't really taken
off.

I have yet to come across a scenario I couldn't solve with either
Processes, NumPy or event loops. Yes, when using processes, the passing of
data can be annoying sometimes. But that is far less annoying then trying
to debug something that shares state across threads.

It's great that you haven't been bitten yet. But, the evidence seems to
suggest the either you *will* be bitten at some point or, you already have
been, and you just don't know it.

Cheers


> > Writing multithreaded code is *hard*. It is not a programming model
> > which comes naturally to most human beings. Very few programs are
> > inherently parallelizable, although many programs have *parts* which
> > can be successfully parallelized.
>
> Parallel algorithms are complicated and specialized but tons of problems
> amount to "do the same thing with N different pieces of data", so-called
> embarassingly parallel.  The model is you have a bunch of worker threads
> reading off a queue and processing the items concurrently.  Sometimes
> separate processes works equally well, other times it's good to have
> some shared data in memory instead of communicating through sockets.  If
> the data is mutable then have one thread own it and access it only with
> message passing, Erlang style.  If it's immutable after initialization
> (protect it with a condition variable til initialization finishes) then
> you can have read-only access from anywhere.
>
> > if you're running single-thread code on a single-core machine and
> > still complaining about the GIL, you have no clue.
>
> Even the Raspberry Pi has 4 cores now, and fancy smartphones have had
> them for years.  Single core cpu's are specialized and/or historical.
>
> > for some programs, the simplest way to speed it up is to vectorize the
> > core parts of your code by using numpy.  No threads needed.
>
> Nice for numerical codes, not so hot for anything else.
>
> > Where are the people flocking to use Jython and IronPython?
>
> Shrug, who knows, those implementations were pretty deficient from what
> heard.
>
> > For removal of the GIL to really make a difference: ...
> > - you must be performing a task which is parallelizable and not
> inherently
> > sequential (no point using multiple threads if each thread spends all its
> > time waiting for the previous thread);
>
> That's most things involving concurrency these days.
>
> > - the task must be one that moving to some other multi-processing model
> > (such as greenlets, multiprocess, etc.) is infeasible;
>
> I don't understand this--there can be multiple ways to solve a problem.
>
> > - your threading bottleneck must be primarily CPU-bound, not I/O bound
> > (CPython's threads are already very effective at parallelising I/O
> tasks);
>
> If your concurrent program's workload makes it cpu-bound even 1% of the
> time, then you gain something by having it use your extra cores at those
> moments, instead of having those cores always do nothing.
>
> > - and you must be using libraries and tools which prevent you moving to
> > Jython or IronPython or some other alternative.
>
> I don't get this at all.  Why should I not want Python to have the same
> capabilities?
> --
> https://mail.python.org/mailman/listinfo/python-list
>

--047d7b2e1365b0c1df050fb8d401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote">On Mon Feb 23 2015 at 12:05:46 =
PM Paul Rubin &lt;no.email@nospam.invalid&gt; wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I don&#39;t see what the big deal is.=C2=A0 I hear tons of ho=
rror stories about<br>
threads and I believe them, but the thing is, they almost always revolve<br=
>
around acquiring and releasing locks in the wrong order, forgetting to<br>
lock things, stuff like that.=C2=A0 So I&#39;ve generally respected the ter=
ror<br>
and avoided programming in that style, staying with a message passing<br>
style that may take an efficiency hit but seems to avoid almost all<br>
those problems.=C2=A0 TM also helps with lock hazards and it&#39;s a beauti=
ful<br>
idea--I just haven&#39;t had to use it yet.=C2=A0 The Python IRC channel se=
ems to<br>
rage against threads and promote Twisted for concurrency, but Twisted<br>
has always reminded me of Java.=C2=A0 I use threads in Python all the time<=
br>
and haven&#39;t gotten bitten yet.<br>
<br></blockquote><div><br></div><div>Many people have written at length abo=
ut why it&#39;s bad. The most recent example I have come across is here -&g=
t;=C2=A0<a href=3D"https://glyph.twistedmatrix.com/2014/02/unyielding.html"=
>https://glyph.twistedmatrix.com/2014/02/unyielding.html</a></div><div><br>=
</div><div>It&#39;s not a specific Python problem. I must be in the limited=
 crowd that believes that the GIL is a *feature* of Python. Then again, may=
be it isn&#39;t so limited since the GIL-less python implementations haven&=
#39;t really taken off.</div><div><br></div><div>I have yet to come across =
a scenario I couldn&#39;t solve with either Processes, NumPy or event loops=
. Yes, when using processes, the passing of data can be annoying sometimes.=
 But that is far less annoying then trying to debug something that shares s=
tate across threads.</div><div><br></div><div>It&#39;s great that you haven=
&#39;t been bitten yet. But, the evidence seems to suggest the either you *=
will* be bitten at some point or, you already have been, and you just don&#=
39;t know it.</div><div><br></div><div>Cheers</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
&gt; Writing multithreaded code is *hard*. It is not a programming model<br=
>
&gt; which comes naturally to most human beings. Very few programs are<br>
&gt; inherently parallelizable, although many programs have *parts* which<b=
r>
&gt; can be successfully parallelized.<br>
<br>
Parallel algorithms are complicated and specialized but tons of problems<br=
>
amount to &quot;do the same thing with N different pieces of data&quot;, so=
-called<br>
embarassingly parallel.=C2=A0 The model is you have a bunch of worker threa=
ds<br>
reading off a queue and processing the items concurrently.=C2=A0 Sometimes<=
br>
separate processes works equally well, other times it&#39;s good to have<br=
>
some shared data in memory instead of communicating through sockets.=C2=A0 =
If<br>
the data is mutable then have one thread own it and access it only with<br>
message passing, Erlang style.=C2=A0 If it&#39;s immutable after initializa=
tion<br>
(protect it with a condition variable til initialization finishes) then<br>
you can have read-only access from anywhere.<br>
<br>
&gt; if you&#39;re running single-thread code on a single-core machine and<=
br>
&gt; still complaining about the GIL, you have no clue.<br>
<br>
Even the Raspberry Pi has 4 cores now, and fancy smartphones have had<br>
them for years.=C2=A0 Single core cpu&#39;s are specialized and/or historic=
al.<br>
<br>
&gt; for some programs, the simplest way to speed it up is to vectorize the=
<br>
&gt; core parts of your code by using numpy.=C2=A0 No threads needed.<br>
<br>
Nice for numerical codes, not so hot for anything else.<br>
<br>
&gt; Where are the people flocking to use Jython and IronPython?<br>
<br>
Shrug, who knows, those implementations were pretty deficient from what<br>
heard.<br>
<br>
&gt; For removal of the GIL to really make a difference: ...<br>
&gt; - you must be performing a task which is parallelizable and not inhere=
ntly<br>
&gt; sequential (no point using multiple threads if each thread spends all =
its<br>
&gt; time waiting for the previous thread);<br>
<br>
That&#39;s most things involving concurrency these days.<br>
<br>
&gt; - the task must be one that moving to some other multi-processing mode=
l<br>
&gt; (such as greenlets, multiprocess, etc.) is infeasible;<br>
<br>
I don&#39;t understand this--there can be multiple ways to solve a problem.=
<br>
<br>
&gt; - your threading bottleneck must be primarily CPU-bound, not I/O bound=
<br>
&gt; (CPython&#39;s threads are already very effective at parallelising I/O=
 tasks);<br>
<br>
If your concurrent program&#39;s workload makes it cpu-bound even 1% of the=
<br>
time, then you gain something by having it use your extra cores at those<br=
>
moments, instead of having those cores always do nothing.<br>
<br>
&gt; - and you must be using libraries and tools which prevent you moving t=
o<br>
&gt; Jython or IronPython or some other alternative.<br>
<br>
I don&#39;t get this at all.=C2=A0 Why should I not want Python to have the=
 same<br>
capabilities?<br>
--<br>
<a href=3D"https://mail.python.org/mailman/listinfo/python-list" target=3D"=
_blank">https://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</blockquote></div></div>

--047d7b2e1365b0c1df050fb8d401--