Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.009 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'correct.': 0.07; 'memory.': 0.07; 'modifying': 0.07; 'referring': 0.07; '*the': 0.09; 'alternatives': 0.09; 'bug.': 0.09; 'executed': 0.09; 'slow.': 0.09; 'stack,': 0.09; 'stack.': 0.09; 'sure,': 0.09; 'runs': 0.10; 'python': 0.11; 'cheers': 0.12; 'thread': 0.14; 'article.': 0.16; 'brass': 0.16; 'concurrent': 0.16; 'correctness': 0.16; 'erlang,': 0.16; 'feasible': 0.16; 'haskell,': 0.16; 'infinitely': 0.16; 'introduces': 0.16; 'reproduce': 0.16; 'stuart': 0.16; 'subject:? - ': 0.16; 'subject:Pypy': 0.16; 'subject:threads': 0.16; 'tasks,': 0.16; 'threads,': 0.16; 'threads.': 0.16; 'weird': 0.16; 'language': 0.16; 'wrote:': 0.18; 'library': 0.18; 'bit': 0.19; 'module': 0.19; 'basically': 0.19; 'producing': 0.19; 'stack': 0.19; 'feb': 0.22; 'memory': 0.22; 'example': 0.22; 'programming': 0.22; 'email addr:gmail.com>': 0.22; 'saying': 0.22; 'separate': 0.22; '(such': 0.24; 'errors.': 0.24; 'tue': 0.24; 'paul': 0.24; 'looks': 0.24; 'software.': 0.24; "i've": 0.25; 'certain': 0.27; 'point': 0.28; 'testing': 0.29; '[1]': 0.29; 'possibility': 0.29; "doesn't": 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'url:mailman': 0.30; 'that.': 0.31; 'apparently': 0.31; 'option.': 0.31; 'routine': 0.31; 'scripting,': 0.31; 'staying': 0.31; 'writes:': 0.31; 'probably': 0.32; 'quite': 0.32; 'worked': 0.33; 'url:python': 0.33; 'comment': 0.34; "can't": 0.35; 'except': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'are,': 0.36; 'executing': 0.36; 'reality': 0.36; 'ryan': 0.36; 'url:listinfo': 0.36; "didn't": 0.36; 'thanks': 0.36; 'subject:?': 0.36; 'similar': 0.36; 'url:org': 0.36; 'should': 0.36; 'so,': 0.37; 'too': 0.37; 'problems': 0.38; 'others.': 0.38; 'to:addr:python-list': 0.38; 'fact': 0.38; 'bad': 0.39; 'though,': 0.39; 'to:addr:python.org': 0.39; 'enough': 0.39; 'space': 0.40; 'url:mail': 0.40; 'how': 0.40; 'even': 0.60; 'easy': 0.60; 'most': 0.60; 'balance': 0.61; 'matter': 0.61; 'further': 0.61; 'making': 0.63; 'address': 0.63; 'story': 0.63; 'real': 0.63; 'skip:n 10': 0.64; '8bit%:10': 0.64; 'more': 0.64; 'different': 0.65; 'approaches': 0.68; 'default': 0.69; 'sharing': 0.69; 'stated': 0.69; 'programs,': 0.74; '\xe2\x80\x93': 0.77; 'article': 0.77; 'transfer': 0.82; '"it': 0.84; '"it': 0.84; '2015': 0.84; 'bitten': 0.84; 'clearly.': 0.84; 'different.': 0.84; 'guessed': 0.84; 'lightweight': 0.84; 'me).': 0.84; 'much,': 0.84; 'multicore': 0.84; 'stm': 0.84; 'undoubtedly': 0.84; 'careful': 0.91; 'involved.': 0.91; 'subject:Are': 0.93; 'state.': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=iGTPerQojmTaVGjRJogiklnk3FxIf4c7jhgA+VWEAOE=; b=jjga4pgGTnsOsAiym998cN+da/xkT6qT9Or2GJsHIYxFNaCdNt4Upm+yqiLb7najCc e6LUKTulheYAVQn/Q9QRojGYTd29mBVTK810yOxz275XQ1jfFLT6R0Y16JiUx4ezELqs 3LFVjIydW3rBBIMurB6SfNuvJDNOwRYvJrxpMhJbN3gwueL/gcJ01gQah2Bjc8X0Umq1 yVa1I8e8Y7rik4VbdiwyaeRZ7WeAIiVbSVJL/iCwlC3JUG0ARYWzU1BhspZyyqvBwCFY wOhpTsctjsXhC5pkaGSz55rhJwLQLl0BHdP06PICQsrBHv7iva/CAjoqDlpL/0OaYW+p 9l5w== X-Received: by 10.69.27.15 with SMTP id jc15mr963318pbd.126.1424825975553; Tue, 24 Feb 2015 16:59:35 -0800 (PST) MIME-Version: 1.0 References: <87fv9xdb22.fsf@jester.gateway.pace.com> <54ea7ff4$0$12983$c3e8da3$5496439d@news.astraweb.com> <87zj85bcyu.fsf@jester.gateway.pace.com> <87lhjpb89i.fsf@jester.gateway.pace.com> <87h9udb1eq.fsf@jester.gateway.pace.com> <87bnkkb22u.fsf@jester.gateway.pace.com> <87lhjnang1.fsf@jester.gateway.pace.com> From: Ryan Stuart Date: Wed, 25 Feb 2015 00:59:34 +0000 Subject: Re: Are threads bad? - was: Future of Pypy? To: python-list@python.org Content-Type: multipart/alternative; boundary=001a113835ac23c460050fdf268c X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 193 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1424825985 news.xs4all.nl 2925 [2001:888:2000:d::a6]:49089 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:86366 --001a113835ac23c460050fdf268c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue Feb 24 2015 at 3:32:47 PM Paul Rubin wrote= : > Ryan Stuart writes: > Sure, the shared memory introduces the possibility of some bad errors, > I'm just saying that I've found that by staying with a certain > straightforward style, it doesn't seem difficult in practice to avoid > those errors. > And all I'm saying is that it doesn't matter how careful you are, all it takes is someone up the stack to not be as careful and you will be bitten. And even if they are careful, it's still very easy to be bitten because everything runs in shared memory. > I don't understand what you mean about malloc. > My point is malloc, something further up (down?) the stack, is making modifications to shared state when threads are involved. Modifying shared state makes it infinitely more difficult to reason about the correctness of your software. > That article was interesting in some ways but confused in others. One > way it was interesting is it said various non-thread approaches (such as > coroutines) had about the same problems as threads. Some ways it > was confused were: > We clearly got completely different things from the article. My interpretation was that it was making *the exact opposite* point to what you stated mainly because non-threading approaches don't share state. It states that quite clearly. For example "it is =E2=80=93 literally =E2=80=93= exponentially more difficult to reason about a routine that may be executed from an arbitrary number of threads concurrently". > 1) thinking Haskell threads were like processes with separate address > spaces. In fact they are in the same address space and programming > with them isn't all that different from Python threads, though the > synchronization primitives are a bit different. There is also an STM > library available that is ingenious though apparently somewhat slow. > I don't know Haskell, so I can't comment too much, except to say that by default Haskell looks to use lightweight threads where only 1 thread can be executing at a time [1] (sounds similar to the GIL to me). That doesn't seem to be shared state multithreading, which is what the article is referring to. But again, they will undoubtedly be someone sharing state higher up the stack. > 2) it has a weird story about the brass cockroach, that basically > signified that they didn't have a robust enough testing system to be > able to reproduce the bug. That is what they should have worked on. > The point was that it wasn't feasible to have a robust testing suite because, you guessed it, shared state and concurrent threads producing n*n complexity. > 3) It goes into various hazards of the balance transfer example not > mentioning that STM (available in Haskell and Clojure) completely > solves it. > This is probably correct. Is there any STM implementations out that that don't significantly compromise performance? Anyway, I got one thing out of this, which is that the multiprocessing > module looks pretty nice and I should try it even when I don't need > multicore parallelism, so thanks for that. > It's 1 real advantage is that it side-steps the GIL. So, if you need to utilise multiple cores for CPU bound tasks, then it might well be the only option. Cheers > In reality though, Python is still my most productive language for > throwaway, non-concurrent scripting, but for more complicated concurrent > programs, alternatives like Haskell, Erlang, and Go all have significant > attractions. > -- > https://mail.python.org/mailman/listinfo/python-list > --001a113835ac23c460050fdf268c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue Feb 24 2015 at 3:32:47 P= M Paul Rubin <no.email@nospam.invalid> wrote:
Ryan Stuart <ryan.stuart.85@gmail.com> writes:
Sure, the shared memory introduces the possibility of some bad errors,
I'm just saying that I've found that by staying with a certain
straightforward style, it doesn't seem difficult in practice to avoid those errors.

And all I'm saying is= that it doesn't matter how careful you are, all it takes is someone up= the stack to not be as careful and you will be bitten. And even if they ar= e careful, it's still very easy to be bitten because everything runs in= shared memory.
=C2=A0
I don't understand what you mean about malloc.=C2=A0

My point is malloc, something further up (down?) the stac= k, is making modifications to shared state when threads are involved. Modif= ying shared state makes it infinitely more difficult to reason about the co= rrectness of your software.
=C2=A0
That article was interesting in some ways but confused in others.=C2=A0 One=
way it was interesting is it said various non-thread approaches (such as coroutines) had about the same problems as threads.=C2=A0 Some ways it was= =C2=A0confused were:

We clearly got com= pletely different things from the article. My interpretation was that it wa= s making *the exact opposite* point to what you stated mainly because non-t= hreading approaches don't share state. It states that quite clearly. Fo= r example "it is =E2=80=93 literally =E2=80=93 exponentially more diff= icult to reason about a routine that may be executed from an arbitrary numb= er of threads concurrently".
=C2=A0
=C2=A0 1) thinking Haskell threads were like processes with separate addres= s
=C2=A0 spaces.=C2=A0 In fact they are in the same address space and program= ming
=C2=A0 with them isn't all that different from Python threads, though t= he
=C2=A0 synchronization primitives are a bit different.=C2=A0 There is also = an STM
=C2=A0 library available that is ingenious though apparently somewhat slow.=

I don't know Haskell, so I can'= ;t comment too much, except to say that by default Haskell looks to use lig= htweight threads where only 1 thread can be executing at a time [1] (sounds= similar to the GIL to me). That doesn't seem to be shared state multit= hreading, which is what the article is referring to. But again, they will u= ndoubtedly be someone sharing state higher up the stack.
=C2=A0
=C2=A0 2) it has a weird story about the brass cockroach, that basically =C2=A0 signified that they didn't have a robust enough testing system t= o be
=C2=A0 able to reproduce the bug.=C2=A0 That is what they should have worke= d on.

The point was that it wasn't = feasible to have a robust testing suite because, you guessed it, shared sta= te and concurrent threads producing n*n complexity.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =C2=A0 3) It goes into various hazards of the balance transfer example not<= br> =C2=A0 mentioning that STM (available in Haskell and Clojure) completely =C2=A0 solves it.

This is probably corr= ect. Is there any STM implementations out that that don't significantly= compromise performance?

Anyway, I got one thing out of this, which is that the multiprocessing
module looks pretty nice and I should try it even when I don't need
multicore parallelism, so thanks for that.

<= div>It's 1 real advantage is that it side-steps the GIL. So, if you nee= d to utilise multiple cores for CPU bound tasks, then it might well be the = only option.

Cheers
=C2=A0
In reality though, Python is still my most productive language for
throwaway, non-concurrent scripting, but for more complicated concurrent programs, alternatives like Haskell, Erlang, and Go all have significant attractions.
--
https://mail.python.org/mailman/listinfo/python-list
--001a113835ac23c460050fdf268c--