Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86105 > unrolled thread

Future of Pypy?

Back to article view | Back to comp.lang.python

Contents

  Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-22 12:45 +0000
    Re: Future of Pypy? jkn <jkn_gg@nicorp.f9.co.uk> - 2015-02-22 04:58 -0800
      Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-22 15:30 +0000
        [OT] - BASIC is still not a bad choice, was Re: Future of Pypy? Michael Torrie <torriem@gmail.com> - 2015-02-23 17:24 -0700
    Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-22 14:27 +0100
      Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-22 15:36 +0000
        Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-22 18:22 +0100
          Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 11:02 -0800
            Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-22 20:51 +0100
              Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 12:14 -0800
                Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-22 23:13 +0100
                  Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 18:45 -0800
            Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-23 12:18 +1100
              Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 18:04 -0800
                Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-23 13:16 +1100
                Re: Future of Pypy? Ryan Stuart <ryan.stuart.85@gmail.com> - 2015-02-23 03:16 +0000
                  Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 19:45 -0800
                    Re: Future of Pypy? Ryan Stuart <ryan.stuart.85@gmail.com> - 2015-02-23 04:00 +0000
                      Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-22 22:13 -0800
                        Re: Future of Pypy? Ryan Stuart <ryan.stuart.85@gmail.com> - 2015-02-23 07:32 +0000
                          Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 16:11 -0800
                            Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-24 11:31 +1100
                              Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 17:50 -0800
                                Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-24 13:03 +1100
                                  Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 20:40 -0800
                                    Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-24 17:57 +1100
                                      Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-27 13:40 -0800
                                        Re: Future of Pypy? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-27 18:47 -0500
                            Are threads bad? - was: Future of Pypy? Ryan Stuart <ryan.stuart.85@gmail.com> - 2015-02-24 00:35 +0000
                              Re: Are threads bad? - was: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 21:27 -0800
                                Re: Are threads bad? - was: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-24 16:57 +1100
                                  Re: Are threads bad? - was: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 22:23 -0800
                                  Re: Are threads bad? - was: Future of Pypy? Marko Rauhamaa <marko@pacujo.net> - 2015-02-24 10:08 +0200
                                    Re: Are threads bad? - was: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-24 15:53 -0800
                                      Re: Are threads bad? - was: Future of Pypy? Marko Rauhamaa <marko@pacujo.net> - 2015-02-25 07:25 +0200
                                        Re: Are threads bad? - was: Future of Pypy? Marcos Almeida Azevedo <marcos.al.azevedo@gmail.com> - 2015-02-25 13:34 +0800
                                          Re: Are threads bad? - was: Future of Pypy? Marko Rauhamaa <marko@pacujo.net> - 2015-02-25 07:46 +0200
                                            Re: Are threads bad? - was: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-25 16:54 +1100
                                            Re: Are threads bad? - was: Future of Pypy? Marcos Almeida Azevedo <marcos.al.azevedo@gmail.com> - 2015-02-25 13:58 +0800
                                            Re: Are threads bad? - was: Future of Pypy? Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-24 23:02 -0700
                                            Re: Are threads bad? - was: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-25 17:07 +1100
                                            Re: Are threads bad? - was: Future of Pypy? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-25 16:37 +0000
                                            Re: Are threads bad? - was: Future of Pypy? Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-25 10:00 -0700
                                            Re: Are threads bad? - was: Future of Pypy? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-25 17:16 +0000
                                            Re: Are threads bad? - was: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-26 04:22 +1100
                                            Re: Are threads bad? - was: Future of Pypy? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-25 19:44 -0500
                                Re: Are threads bad? - was: Future of Pypy? Ryan Stuart <ryan.stuart.85@gmail.com> - 2015-02-25 00:59 +0000
                                  Re: Are threads bad? - was: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-26 21:55 -0800
                Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-23 14:25 +1100
                Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-23 18:41 +1100
                  Re: Future of Pypy? Marko Rauhamaa <marko@pacujo.net> - 2015-02-23 10:16 +0200
                  Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-23 20:19 +1100
                    Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-24 17:56 +1100
                      Re: Future of Pypy? Chris Angelico <rosuav@gmail.com> - 2015-02-24 18:16 +1100
                        Re: Future of Pypy? wxjmfauth@gmail.com - 2015-02-23 23:57 -0800
                  Re: Future of Pypy? Ethan Furman <ethan@stoneleaf.us> - 2015-02-23 11:39 -0800
                    Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-24 13:15 +1100
                  Re: Future of Pypy? Paul Rubin <no.email@nospam.invalid> - 2015-02-23 17:47 -0800
                    Re: Future of Pypy? Marko Rauhamaa <marko@pacujo.net> - 2015-02-24 10:12 +0200
        Re: Future of Pypy? Emile van Sebille <emile@fenx.com> - 2015-02-24 09:57 -0800
    Re: Future of Pypy? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-23 01:05 +1100
      Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-22 15:44 +0000
        Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-22 19:20 +0000
          Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-22 22:45 +0100
            Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-23 14:04 +0000
              Re: Future of Pypy? Laura Creighton <lac@openend.se> - 2015-02-23 17:16 +0100
    Re: Future of Pypy? Terry Reedy <tjreedy@udel.edu> - 2015-02-23 01:34 -0500
    Re: Future of Pypy? Dave Cook <davecook@nowhere.net> - 2015-02-23 11:36 +0000
      Re: Future of Pypy? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-02-23 14:13 +0000
        Cython - was: Future of Pypy? Stefan Behnel <stefan_ml@behnel.de> - 2015-02-23 16:43 +0100
        Re: Future of Pypy? Dave Cook <davecook@nowhere.net> - 2015-02-23 23:23 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#86381 — Re: Are threads bad? - was: Future of Pypy?

On Wed, Feb 25, 2015 at 5:02 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Uhh, I have seen *heaps* of code whose performance suffers from too
>> much locking. At the coarsest and least intelligent level, a database
>> program that couldn't handle concurrency at all, so I wrote an
>> application-level semaphore that stopped two people from running it at
>> once. You want to use that program? Ask the other guy to close it.
>> THAT is a performance problem. And there are plenty of narrower cases,
>> where it ends up being a transactions-per-second throughput limiter.
>
> Is the name of that database program "Microsoft Access" perchance?

No, though it wouldn't surprise me if it had the same issue. No, the
program was a DBase-backed one of my own development; it was the DBase
engine itself that couldn't handle concurrency, so I added some
startup code that checked to see if anyone else had the file open, and
popped up a "retry or cancel" prompt until the semaphore cleared.

Later on, I was able to shift the entire content into DB2 (once we no
longer needed compatibility with an even older DBase-backed program),
and voila, we had concurrency. I still needed to make use of
record-level locking (if you open a record for editing, it holds a
lock for as long as you have the window open; chances are, anyone else
who wants the same record is actually doing the same job, so erroring
out is the best option), but no more database-level locks.

ChrisA

[toc] | [prev] | [next] | [standalone]

#86415 — Re: Are threads bad? - was: Future of Pypy?

On 25/02/2015 06:02, Ian Kelly wrote:
>
> Is the name of that database program "Microsoft Access" perchance?
>

Are you referring to the GUI, the underlying database engine, both, or what?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#86422 — Re: Are threads bad? - was: Future of Pypy?

On Wed, Feb 25, 2015 at 9:37 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 25/02/2015 06:02, Ian Kelly wrote:
>>
>>
>> Is the name of that database program "Microsoft Access" perchance?
>>
>
> Are you referring to the GUI, the underlying database engine, both, or what?

The engine. In theory it supports concurrent access. In practice, it
seems that access is frequently blocked by locks generated by some
other user who was working on it hours ago and is now out of the
office. Not to mention the times when the lock file gets so badly
corrupted that the resolution is to just delete it.

I haven't used it in some time though, so maybe it's gotten better.

[toc] | [prev] | [next] | [standalone]

#86425 — Re: Are threads bad? - was: Future of Pypy?

On 25/02/2015 17:00, Ian Kelly wrote:
> On Wed, Feb 25, 2015 at 9:37 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 25/02/2015 06:02, Ian Kelly wrote:
>>>
>>>
>>> Is the name of that database program "Microsoft Access" perchance?
>>>
>>
>> Are you referring to the GUI, the underlying database engine, both, or what?
>
> The engine. In theory it supports concurrent access. In practice, it
> seems that access is frequently blocked by locks generated by some
> other user who was working on it hours ago and is now out of the
> office. Not to mention the times when the lock file gets so badly
> corrupted that the resolution is to just delete it.
>
> I haven't used it in some time though, so maybe it's gotten better.
>

IIRC the underlying JET engine was replaced by SQL Server years ago. 
Maybe not the best technlogy in the world, but you'd be hard pushed to 
do worse than JET :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#86429 — Re: Are threads bad? - was: Future of Pypy?

On Thu, Feb 26, 2015 at 4:16 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> IIRC the underlying JET engine was replaced by SQL Server years ago. Maybe
> not the best technlogy in the world, but you'd be hard pushed to do worse
> than JET :)

The way I understood it, MS Access could connect to a variety of
database backends (SQL Server, or anything that uses ODBC, or whatever
else), but the only inbuilt engine - and therefore the one that you
get by default if you aren't running some other server - was MS Jet.
If they're incorporating SQL Server into MS Office, that would make it
huge... wait, I'm not sure we could tell the difference. But still,
that'd be a whopping great slab of database engine. It'd be like
Python incorporating PostgreSQL. I've at times said that the Python
stdlib ought to include a Postgres *client* (on par with psycopg2),
but not the full *server* :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#86456 — Re: Are threads bad? - was: Future of Pypy?

On Wed, 25 Feb 2015 17:16:36 +0000, Mark Lawrence <breamoreboy@yahoo.co.uk>
declaimed the following:

>On 25/02/2015 17:00, Ian Kelly wrote:
>> On Wed, Feb 25, 2015 at 9:37 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>> On 25/02/2015 06:02, Ian Kelly wrote:
>>>>
>>>>
>>>> Is the name of that database program "Microsoft Access" perchance?
>>>>
>>>
>>> Are you referring to the GUI, the underlying database engine, both, or what?
>>
>> The engine. In theory it supports concurrent access. In practice, it
>> seems that access is frequently blocked by locks generated by some
>> other user who was working on it hours ago and is now out of the
>> office. Not to mention the times when the lock file gets so badly
>> corrupted that the resolution is to just delete it.
>>
>> I haven't used it in some time though, so maybe it's gotten better.
>>
>
>IIRC the underlying JET engine was replaced by SQL Server years ago. 
>Maybe not the best technlogy in the world, but you'd be hard pushed to 
>do worse than JET :)

	No... JET is still there...

	SQL Server/MSDE was used for "Access Data Projects" but I think the
last two editions of Office have dropped ADP support (you can still /link/
to SQL Server as an ODBC source, but no longer have direct/invisible
access).

	JET is a file-server database -- just like SQLite; each client is
directly interacting with the database file rather than sending requests to
a stand-alone server program where the server is the only program accessing
the data files.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#86366 — Re: Are threads bad? - was: Future of Pypy?

[Multipart message — attachments visible in raw view] — view raw

On Tue Feb 24 2015 at 3:32:47 PM 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 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 – literally – 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
>

[toc] | [prev] | [next] | [standalone]

#86561 — Re: Are threads bad? - was: Future of Pypy?

Ryan Stuart <ryan.stuart.85@gmail.com> writes:
> 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.

If you're saying the libc malloc might have bugs that affect
multithreaded apps but not single threaded ones, then sure, but the
Linux kernel might also have such bugs and it's inherently
multithreaded, so there's no escape.  Even if your app is threaded
you're still susceptible to threading bugs in the kernel.  

If malloc works properly then it's thread-safe and you can use it
without worrying about how your app's state interacts with malloc's
internal state.

> 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 gave the example of asyncio, which is non-threaded but (according to
the article) was susceptible to shared state bugs because you could
accidentally insert yield points in critical sections, by doing things
like logging.

> It states that quite clearly. For example "it is – literally –
> exponentially more difficult to reason about a routine that may be
> executed from an arbitrary number of threads concurrently".

I didn't understand what it was getting at with that n**n claim.  Of
course arbitrary code (even single threaded) is incalculably difficult
to reason about (halting problem, Rice's theorem).  But we're talking
about code following a particular set of conventions, not arbitrary
code.  The conventions are supposed to facilitate reasoning and
verification.  Again there's tons of solid theory in the OS literature
about this stuff.

> by default Haskell looks to use lightweight threads where only 1
> thread can be executing at a time [1]... That doesn't seem to be
> shared state multithreading, which is what the article is referring to.

Haskell uses lightweight, shared state threads with synchronization
primitives that do the usual things (the API is somewhat different than
Posix threads though).  You have to use the +RTS command line option to
run on multiple cores: I don't know why the default is to stay on a
single core.  There might be a performance hit if you use the multicore
runtime with a single-threaded program, or something like that.

There is a book about Haskell concurrency and parallelism that I've been
wanting to read (full text online):

http://chimera.labs.oreilly.com/books/1230000000929/index.html

>     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. 
>
> The point was that it wasn't feasible to have a robust testing suite
> because, you guessed it,

No really, they observed this bug happening repeatedly under what
sounded like fairly light load with real users.  So a stress testing
framework should have been able to reproduce it.  Do you really think
it's impossible to debug this kind of problem?  OS developers do it all
the time.  There is no getting around it.  

> This is probably correct. Is there any STM implementations out that
> that don't significantly compromise performance?

STM is fast as long as there's not much contention for shared data
between threads.  In the "account balance" example that should almost
always be the case.  The slowdown is when multiple threads are fighting
over the same data and transactions keep having to be rolled back and
restarted.

>     multiprocessing module looks pretty nice and I should try it 
> 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.

It's 1 real advantage compared to what?  I thought you were saying it
avoids shared data hazards of threads.  The 4 alternatives in that
article were threads, multiprocessing, old-fashioned async (callback
hell), and asyncio (still contorted and relies on Python 3 coroutines).
If you eliminate threads because of data sharing and asyncio because you
need Python 2 compatibility, you're left with multiprocessing if you
want to avoid the control inversion of callback style.

It's true though, this started out about the GIL in PyPy (was Laura
going to post about that?) so using multicores is indeed maybe relevant.

[toc] | [prev] | [next] | [standalone]

#86188

On Mon, Feb 23, 2015 at 2:16 PM, Ryan Stuart <ryan.stuart.85@gmail.com> wrote:
> 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.

The GIL isn't a problem, per se. It's a solution to an underlying
problem (concurrent access to internal data structures) which comes
with its own tradeoffs. Every method of eliminating the GIL is really
an alternate solution to the same underlying problem, with its own
tradeoffs. The GIL has simplicity on its side.

ChrisA

[toc] | [prev] | [next] | [standalone]

#86200

Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> I'm sorry, but the instant somebody says "eliminate the GIL", they lose
>> credibility with me. Yes yes, I know that in *your* specific case you've
>> done your research and (1) multi-threaded code is the best solution for
>> your application and (2) alternatives aren't suitable.
> 
> 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.

Deadlocks, livelocks, and the simple fact that debugging threaded code is 
much, much, much harder than debugging single-thread code.

You'll notice that nowhere in my post did I say "Don't use threads!". But 
they aren't a panacea, and there are other concurrency models available 
which don't have the same disadvantages as threads (they have their own pros 
and cons instead).


[...]
>> For removal of the GIL to really make a difference: ...
[...]
>> - 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.

Yes, but my point is that if some other way solves the problem, then you 
should *use that other technique* rather than complain about the GIL. The 
GIL is not a bottleneck if you can bypass it.

I can sympathize with somebody who says "I have this problem that can only 
be solved with threads, anything else is too difficult, but the GIL makes it 
too slow".

But I don't sympathize with somebody who says "I have this problem that can 
be solved with threads or multiprocessing, but I insist that only threads 
can be used. And now the GIL makes it too slow. Python sux."

No. You [generic you] sux, for not investigating whether multiprocessing 
will do the job. It even has the same public API as threads.


>> - 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.

Not necessarily. Threading has overhead too. Even in GIL-less Python, two 
threads aren't twice as fast as one thread. So there comes a point of 
diminishing returns, where the benefit you get from threading is less than 
the cost of threading. Now your code will actually run slower with threads, 
GIL or no GIL.


>> - 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?

Python does have the same capabilities. Jython and IronPython aren't 
different languages, they are Python.

If you want *CPython* to work without a GIL, well, are you volunteering to 
do the work? It is a massive job, and the core devs aren't terribly 
interested. Probably because they understand that the GIL is not often an 
unsurmountable problem in real life. That brings us to the point I was 
making: I believe, and the core devs appear to think the same, that the 
*actual* number of people who would benefit from CPython losing the GIL is 
not large enough to justify the work it would require.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#86201

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Yes, but my point is that if some other way solves the problem, then
> you should *use that other technique* rather than complain about the
> GIL. The GIL is not a bottleneck if you can bypass it.
>
> I can sympathize with somebody who says "I have this problem that can
> only be solved with threads, anything else is too difficult, but the
> GIL makes it too slow".
>
> But I don't sympathize with somebody who says "I have this problem
> that can be solved with threads or multiprocessing, but I insist that
> only threads can be used. And now the GIL makes it too slow. Python
> sux."

I'm as "antithread" as anybody, but I think you are blaming the victim
here. I do sympathize with a person who wants to use threads and finds
out there is no true parallelism.

GIL is a downside you have to accept when using a language like Python
that has to "hold the world still" while it's manipulating its data
structures in a safe way. Because of the dynamism involved, effective
parallelism is difficult to achieve.

I must say I have never been bitten by this problem because I only use
threads under duress (occasionally when dealing with blocking APIs) and
because I have very modest performance requirements for Python. For
anything that needs to be fast, I use other programming languages.
Currently, my work is maybe 45% bash, 45% Python and 10% C/C++ (and even
in my C code, I generally steer clear of threads).


Marko

[toc] | [prev] | [next] | [standalone]

#86203

On Mon, Feb 23, 2015 at 6:41 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>>> - 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?
>
> Python does have the same capabilities. Jython and IronPython aren't
> different languages, they are Python.

Presuming that he meant CPython, one other good reason for wanting to
stick with it rather than jump to another interpreter is all the new
features of the recent versions. (Do Jython or IronPython support
Python 3.x at all, even?) Every new release of CPython has new and
cool features, and the other Pythons are generally playing catch-up.

ChrisA

[toc] | [prev] | [next] | [standalone]

#86300

Chris Angelico wrote:

> On Mon, Feb 23, 2015 at 6:41 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>>>> - 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?
>>
>> Python does have the same capabilities. Jython and IronPython aren't
>> different languages, they are Python.
> 
> Presuming that he meant CPython, one other good reason for wanting to
> stick with it rather than jump to another interpreter is all the new
> features of the recent versions. (Do Jython or IronPython support
> Python 3.x at all, even?) Every new release of CPython has new and
> cool features, and the other Pythons are generally playing catch-up.

Most people are not using the bleeding edge version of Python, and even 
those who do, aren't usually using it in production. There are still plenty 
of people using Python 2.3 in production, and even a few using 1.5.

But as you say, there are good reasons for wishing to stick to CPython over 
Jython, IronPython, PyPy or Stackless, let alone less mature or experimental 
implementations. I get that.

But the point I am trying to make is that there are an awful lot of people 
who mindlessly bash "Python" the language for "the GIL". The argument is 
even worse than "Python sux cos significant whitespace", because the 
whitespace issue at least is mostly a matter for personal preference, but 
the GIL appears to be a technical, objective judgement. Trouble is that it 
is *wrong*. Python the language doesn't have a GIL. Implementations with a 
GIL aren't slower because of it, they are faster. And removing the GIL 
doesn't necessarily speed up multithreaded code. So they are technically 
wrong, and in practical terms often wrong too.

I am *happy* when people come up with nuanced and considered opinions that 
they found that Python was unsuitable for some specific project, and can 
give good cogent reasons for it. If they can demonstrate reasons for 
believing that CPython would have been suitable *if the GIL was removed*, 
that's great. Given sufficiently many such projects, and 1- and 2-core CPUs 
gradually becoming obsolete, the time may come for somebody else to take a 
shot at removing the GIL from CPython again. That time might even be now, if 
there is a volunteer.

And C coders out there want a nice meaty project to work on during rainy 
weekends?



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#86302

On Tue, Feb 24, 2015 at 5:56 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Most people are not using the bleeding edge version of Python, and even
> those who do, aren't usually using it in production. There are still plenty
> of people using Python 2.3 in production, and even a few using 1.5.
>
> But as you say, there are good reasons for wishing to stick to CPython over
> Jython, IronPython, PyPy or Stackless, let alone less mature or experimental
> implementations. I get that.

Yes, not everyone is running Python 3.5 in production, I totally get
that :) But if I'm writing an app to run on Debian or Ubuntu, I can
depend on there being a CPython 3.x available, even on the oldest
currently-supported releases (Ubuntu Lucid and Debian Squeeze both
ship Python 3.1), and it won't be long before saying "requires Python
3.3" won't be a problem. Plus, you can always compile CPython from
source on any Unix-like system, or download the .msi for Windows, and
run 3.4 with no problems. But if you want to use PyPy, Jython, or any
other implementation of the language, you're quite possibly stuck on
2.x, or if 3.x support does exist, it's the new and experimental code.
Even a willingness to compile from source won't get you past that, so
using any of the new features of Python 3.x is likely to cut out some
of the alternate interpreters.

It's fine to use Python 2.3 if that's all you need (and if you don't
need any bug fixes from python.org, which presumably means you have
security support from someone else). But it's also fine to want to use
a newer Python. It'd be nice if all the major Pythons supported 3.4,
but the reality of volunteer time is that CPython is pretty much
always going to be in the lead.

ChrisA

[toc] | [prev] | [next] | [standalone]

#86303

Blah blah blah...

pypy fails as soon as one lives the ascii world.
(Not exactly for the same reasons as in CPy 3.3+.)

Regards.
jmf

[toc] | [prev] | [next] | [standalone]

#86258

[Multipart message — attachments visible in raw view] — view raw

On 02/22/2015 11:41 PM, Steven D'Aprano wrote:

> If you want *CPython* to work without a GIL, well, are you volunteering to 
> do the work? It is a massive job, and the core devs aren't terribly 
> interested. Probably because they understand that the GIL is not often an 
> unsurmountable problem in real life. That brings us to the point I was 
> making: I believe, and the core devs appear to think the same, that the 
> *actual* number of people who would benefit from CPython losing the GIL is 
> not large enough to justify the work it would require.

If memory serves, the first and primary point to losing the GIL is that single-threaded code must run just as fast (or
at least close to just as fast) as the GIL version, and previous attempts have all badly failed that requisite.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#86287

Ethan Furman wrote:

> On 02/22/2015 11:41 PM, Steven D'Aprano wrote:
> 
>> If you want *CPython* to work without a GIL, well, are you volunteering
>> to do the work? It is a massive job, and the core devs aren't terribly
>> interested. Probably because they understand that the GIL is not often an
>> unsurmountable problem in real life. That brings us to the point I was
>> making: I believe, and the core devs appear to think the same, that the
>> *actual* number of people who would benefit from CPython losing the GIL
>> is not large enough to justify the work it would require.
> 
> If memory serves, the first and primary point to losing the GIL is that
> single-threaded code must run just as fast (or at least close to just as
> fast) as the GIL version, and previous attempts have all badly failed that
> requisite.

That was then. Now even smartphones have multiple cores. It might be time to 
reconsider. If not now, then surely by the time entry-level machines have 8 
cores, the requirement that 1-core machines aren't penalized will surely be 
dropped :-)

It may turn out that removing the GIL doesn't improve things *enough*, who 
knows what will happen. I recall from the first attempt, back in Python 1.5 
days, that there was a 40% slowdown for single core machines, a very slight 
speedup for two-core, and increasing the number of cores beyond four made no 
real difference. So it might turn out that "removing the GIL" is great in 
theory and not so useful in practice, but I guess only time will tell.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#86283

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> Deadlocks, livelocks, and the simple fact that debugging threaded code is 
> much, much, much harder than debugging single-thread code.

Deadlocks and livelocks can happen in multi-process code just like with
threads.  Debugging threaded code hasn't been too bad a problem for me
so far.  The basic tactic is use the logging module a lot (it is thread
safe), log the i/o events coming into the system if you observe
misbehaviour, and play the log back through your test harness to
reproduce the problem and debug it by normal means.  You have to do
something like that anyway, if the indeterminacy in the system comes
from the unpredictable ordering of external i/o events.  IMHO you'd get
basicaly similar bugs with other concurrency mechanisms.

Other programs like Postgres are written in dangerous languages like C
and use millions of LOC and vast numbers of fine-grained locks and are
still considered very reliable.  Python threads communicating through
queues has to be a breeze by comparison.  Compared to what Linux kernel
hackers have to deal with, it's not even on the same planet.  This book
is amazing:

https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html

> No. You [generic you] sux, for not investigating whether multiprocessing 
> will do the job. It even has the same public API as threads.

I will give multiprocessing a try next time the matter comes up (it
hasn't always been available) but it doesn't seem as flexible.  E.g. say
I have an employee handling thread (untested pseudocode, forgive
errors):

   def employee_loop(queue):
     while True:
       func, args = queue.get()
       func(*args)

   def adjust_salary(person, update_func):
       salaries[person] = update_func(salaries[person])

   threading.Thread(target=employee_loop,
                    args=[employee_request_queue]).start()

Now in another thread, I want to give you a 50% raise:

    employee_request_queue.put(
      (adjust_salary, ('Steven', 
                         lambda old_salary: old_salary * 1.5)))

Can I do that with multiprocessing without a bunch more boilerplate?

> Even in GIL-less Python, two threads aren't twice as fast as one
> thread. So there comes a point of diminishing returns

Well if two threads are 1.5x as fast as one thread, that's a win.

> Python does have the same capabilities. Jython and IronPython aren't 
> different languages, they are Python.

Oh ok.  I think of Jython as a Java thing and IronPython as a Windows
thing and I don't want to deal with the monstrous JVM or CLR systems.
So I unconsciously didn't think of them as Python.  I do think of PyPy
as Python.

> If you want *CPython* to work without a GIL, well, are you
> volunteering to do the work? It is a massive job, and the core devs
> aren't terribly interested.

It's not a massive job, it's been done and it worked, the problem is
that locking all the CPython refcount updates slowed down the important
single-cpu case so it was never adopted.  So the real massive job would
be moving to a tracing GC and changing every extension module ever
written.  But, that's what PyPy is (among other things) so I'm waiting
to hear from Laura why PyPy has a GIL.

[toc] | [prev] | [next] | [standalone]

#86305

Paul Rubin <no.email@nospam.invalid>:

> Deadlocks and livelocks can happen in multi-process code just like
> with threads.

The main thing to avoid is to assume that writing can block until its
completion. At least one of the communicating parties must write in a
nonblocking manner and make sure it is always ready to read.

The remaining problem is flow control to prevent write buffer flooding.

All of that is easier to get right than the intricacies of
multithreading.


Marko

[toc] | [prev] | [next] | [standalone]

#86339

On 2/22/2015 9:22 AM, Laura Creighton wrote:

> There was, and still is, an enormous amount of resentment about this.
> For a lot of people, the perception was, and still is that the benefits
> of Python 3.x over Python 2.x was not worth breaking backwards
> compatibility.  And there still are plenty of places whose plan is
> to use Python 2.7 indefinitely into the far future.  I've got 15
> years worth of commercial python code out there in the world, and
> nobody wants it converted enough to pay me to do so.  Their position
> is that it runs quite well enough as it is.  I'm sure not
> going to convert the stuff for fun.  Practically every Python consultant on
> the planet is in the same boat.

+1

As a glue language, it's simply impractical to reapply the glue.

Emile

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web