Re:Progress on the Gilectomy
by Animats on Friday June 02, 2017 @01:03AM
(#14467580)
Multithreading in Python is all uphill. In Python, any thread can store into anything at any time. By name, even, using "setattr". There's no thread-local data. This implies excessive locking activity. That's why this guy is working so hard to do things that ought to be simple.
A few restrictions on the language would make it easier, but when this is suggested, Guido has a cow.
Re:Progress on the Gilectomy
by benhoyt on Friday June 02, 2017 @08:46AM
(#14469430)
"Guido has a cow". Hmmm, or maybe he knows this would be mean huge, backwards-incompatible changes to the language's dynamic nature, and especially after the experience with the changes (I think much lesser ones compared to this) from Python 2 to Python 3, he's very wary of that.
Still, if you were going to propose "a few restrictions on the language" to make it less dynamic and easier to do multi-threading / optimization, what would they look like?
Re:Progress on the Gilectomy
by VectorLock on Friday June 02, 2017 @10:20AM
(#14470071)
From seeing the "Status of the Gilectomy" talk at PyCon it sounded more like the big blocker is not breaking the C API too bad. Now if somebody suggested a Python 4 with a totally backwards incompatible but thread-safe C API now that I could see him having a cow over (even though I like that idea)
Re:Progress on the Gilectomy
by simcop2387 on Friday June 02, 2017 @03:48AM
(#14468221)
To be fair at least towards #1, that's a really difficult one to get right. Perl has had that kind of threading for a long time and it's almost always considered a bad decision to try to use them. I'm sure it could be done better, but perl did it via a complete copy on write setup in order to create the mostly non-shared data. But you end up with a lot of locking and other contention for the shared data because there's no good way to expose the fact that it's shared and changing it requires such restrictions. Instead the method usually used is to take advantage of most OS's built in COW when forking a new process and communicating via sockets, or some other method instead that forces you to deal with the limitations (copying data, or if you used shared memory you have to do explicit sharing and locking/serialization yourself).
Re:Progress on the Gilectomy
by omginternets on Friday June 02, 2017 @10:32AM
(#14470166)
>when this is suggested, Guido has a cow.
Like what?
My first reaction is to think "and he's [probably] right!"
Python's added value is it's very rich and flexible object model. Imposing restrictions on the object model is robbing Peter to pay Paul in an environment where Peter is more important, albeit for historical reasons.
Re:Progress on the Gilectomy
by stickfigure on Friday June 02, 2017 @02:19AM
(#14467877)
I don't really understand the problem with the GIL. Sure, people doing exotic high performance stuff probably hate it, but Python probably isn't their go-to language anyways.
For boring old web development and business processing, the GIL seems to be a very efficient way of utilizing a CPU+caches without resorting to the horrible event-driven programming model of Node. Want twice the throughput? Run twice the processes. I kinda wish Java would bring back the option of green threads, it was a perfect programming model for web development.
Re:Progress on the Gilectomy
by saghul on Friday June 02, 2017 @02:52AM
(#14467992)
The problem is with CPU intensive tasks. Being as expressive as Python is, it would be nice if CPU intensive algorithms could be written in it, without blocking all other Python threads while the algorithm runs. For example.
Re:Progress on the Gilectomy
by crdoconnor on Friday June 02, 2017 @05:14AM
(#14468565)
>it would be nice if CPU intensive algorithms could be written in it
It would be nicer if instead of trying to turn python into something it is not (a language for writing CPU intensive tasks), it was made better at what it is (glue code).
It would be especially nice if there were tighter, more seamless integration between python and rust so that hot paths in python can easily be migrated to rust.
Re:Progress on the Gilectomy
by sevensor on Friday June 02, 2017 @10:52AM
(#14470302)
I'm not a Rust guy, so take this with a grain of salt, but I was under the impression that Rust did a great job with C interoperability, which is all you need for writing Python extensions. Some hasty googling brings up https://github.com/PyO3/setuptools-rust, which appears to be exactly the thing you're asking for. In other words, it's not heavily advertised, but it appears to be entirely feasible to build Python extensions in Rust, and not spectacularly complicated either.
Re:Progress on the Gilectomy
by srean on Friday June 02, 2017 @06:54AM
(#14468973)
The problem is the overhead of memory copy.
Linux is somewhat smart about it with its copy on write semantics (a double edged sword really). However, the moment you refer to an existing Python object the underlying data-structure gets mutated because of reference counting and boom now you have to copy the whole thing.
This can be worked around with creative stealing and by keeping a sharp lookout for references but it gets really painful and annoying.
Even if that were resolved its still not as flexible as one would want. One cant really go about spawning and terminating process too frequently. This forces one to move larger and larger parts of the logic into C.
Re:Progress on the Gilectomy
by toyg on Friday June 02, 2017 @02:58AM
(#14468014)
> Python probably isn't their go-to language anyways.
That is the real problem. Any sufficiently popular language will inevitably be used in scenarios it is not suited for. Python has now reached that threshold, so all sorts of communities are trying to stretch it and pull it every other way. Sometimes this makes the language better, sometimes it's just a source of complication and frustration.
There is also the issue that some quarters feel python's role is being eroded by newer stuff like golang and nodejs, which were built with high-performance multithreading in mind from the start. I personally think this is not much of a concern (if you are willing to trade python for golang or nodejs, you were not really using python because of its expressiveness and conciseness in the first place), but clearly a lot of people do.
Re:Progress on the Gilectomy
by yumaikas on Friday June 02, 2017 @03:16AM
(#14468086)
What other tradeoff targets would be the considered as sharing python's expressiveness and conciseness? One of the python variants like stackless? C?
I'd be very curious as to the answer here. Some times you do like the pretty code from something like Python, but you get backed into a performance corner, at least I could see that happening.
Re:Progress on the Gilectomy
by lmitchell on Friday June 02, 2017 @03:25AM
(#14468121)
I don't even think it's about pretty code - I think it's more related to what one sibling of the post you replied to mentioned, which is that there are tons of communities (among them machine learning, but including tons of stats-heavy academic programming) which would REALLY like to do some extremely heavy work in Python, not because it's necessarily the best, but because it's what they know. Academics in particular (not CS academics, but stats and experimental sciences people) can be forgiven for wanting to stick with Python - they aren't programmers, they don't want to waste time learning programming language skills that are largely irrelevant to their job. All they want is to pick up an easy language and be able to do their work in it, but once their work gets heavy, the language starts to fight them. And that's a really popular use case for Python, I think.
Re:Progress on the Gilectomy
by srean on Friday June 02, 2017 @06:46AM
(#14468945)
That's bit of a circular argument.
Agreed that compute code for ML is not written in Python, but if GIL wasn't a problem there would be one less reason to drop down to C. Many users would appreciate that. Cython helps with the C part but to a degree.
Re:Progress on the Gilectomy
by ATsch on Friday June 02, 2017 @11:08AM
(#14470421)
You are forgetting python is (depending on the benchmark) still 100-400x slower than a language compiled to native machine code. Removing the GIL might slightly help in some cases but anything CPU bound requiring
high performance will still need to drop down to something faster.
Re:Progress on the Gilectomy
by Someone on Friday June 02, 2017 @06:02AM
(#14468775)
Yes, but the light work, run on a single Python thread, will in some cases take a significant part of execution time.
If you have 16 CPUs in your system, seeing your load at 6% for the first 10% an last 10% of running time, and at 100% in-between surely will make people think there must be easy wins in that Python code. More so since many users will have effectively _zero_ knowledge of C.
Re:Progress on the Gilectomy
by VectorLock on Friday June 02, 2017 @10:22AM
(#14470086)
Its a perception problem. I think the simple perception of the GIL as making multithreading untennable in Python has given Go a big boost and has hurt Python considerably.
Re:Progress on the Gilectomy
by omginternets on Friday June 02, 2017 @10:35AM
(#14470183)
>has hurt Python considerably
Has it? Why the assumption that Go is a direct competitor?
My impression is that Go excels where Python does not, and vice-versa. I use both languages a lot for my day-job, and when using Go, I very much miss having an interpreter and a fully-interactive debugger (Delve is excellent considering the limitations imposed by Go, but much less flexible than pdb).
Re:Progress on the Gilectomy
by nemo1618 on Saturday June 03, 2017 @01:10AM
(#14475096)
Anecdotal, but in 2010 the creators of Go noted in a blog post [1]:
>We had anticipated interest from C, C++, and Java programmers, but the flurry of interest from users of dynamically-typed languages like Python and JavaScript was unexpected.
Re:Progress on the Gilectomy
by krallja on Thursday June 01, 2017 @11:22PM
(#14467194)
Thanks for posting this summary. The video of the talk was posted in May, but I never got around to watching it, because video always feels like it needs a much larger block of uninterrupted time than reading.
Re:Progress on the Gilectomy
by absoluute on Friday June 02, 2017 @11:24AM
(#14470554)
Getting rid of the GIL is easy - just move everything into the interpreter instance struct and add an interpreter pointer as the first parameter in every C API call except create. This should have been done in Python 3 since they broke the API anyway. Now everyone will have to go through another painful transition when they come to their senses. The current thread local storage hacks and PyThreadState/PyEval_SaveThread/PyEval_RestoreThread/PyThreadState_Swap are ridiculous.
A few restrictions on the language would make it easier, but when this is suggested, Guido has a cow.
Still, if you were going to propose "a few restrictions on the language" to make it less dynamic and easier to do multi-threading / optimization, what would they look like?
- VecPy, for number-crunching.[2]
- Newthreading, which I wrote in 2010.[3]
[1] https://lwn.net/Articles/650489/ [2] https://www.andrew.cmu.edu/user/dfarrow/proposal.html [3] http://www.animats.com/papers/languages/newthreadingintro.ht...
Like what?
My first reaction is to think "and he's [probably] right!"
Python's added value is it's very rich and flexible object model. Imposing restrictions on the object model is robbing Peter to pay Paul in an environment where Peter is more important, albeit for historical reasons.
For boring old web development and business processing, the GIL seems to be a very efficient way of utilizing a CPU+caches without resorting to the horrible event-driven programming model of Node. Want twice the throughput? Run twice the processes. I kinda wish Java would bring back the option of green threads, it was a perfect programming model for web development.
It would be nicer if instead of trying to turn python into something it is not (a language for writing CPU intensive tasks), it was made better at what it is (glue code).
It would be especially nice if there were tighter, more seamless integration between python and rust so that hot paths in python can easily be migrated to rust.
compare https://doc.rust-lang.org/1.2.0/book/rust-inside-other-langu... to http://usehelix.com/ for example; the former is only using what the language knows, the latter is a nice library built on top.
There's been some effort for nicer Python integration, but I haven't seen anything super super slick yet.
Yeah, I've tried it and it didn't work.
It's certainly feasible it's just not very well developed.
Ah yes, let's not focus on something python is not. Let's appeal to the majority use case.
What minor planet are people here from?
Linux is somewhat smart about it with its copy on write semantics (a double edged sword really). However, the moment you refer to an existing Python object the underlying data-structure gets mutated because of reference counting and boom now you have to copy the whole thing.
This can be worked around with creative stealing and by keeping a sharp lookout for references but it gets really painful and annoying.
Even if that were resolved its still not as flexible as one would want. One cant really go about spawning and terminating process too frequently. This forces one to move larger and larger parts of the logic into C.
That is the real problem. Any sufficiently popular language will inevitably be used in scenarios it is not suited for. Python has now reached that threshold, so all sorts of communities are trying to stretch it and pull it every other way. Sometimes this makes the language better, sometimes it's just a source of complication and frustration.
There is also the issue that some quarters feel python's role is being eroded by newer stuff like golang and nodejs, which were built with high-performance multithreading in mind from the start. I personally think this is not much of a concern (if you are willing to trade python for golang or nodejs, you were not really using python because of its expressiveness and conciseness in the first place), but clearly a lot of people do.
I'd be very curious as to the answer here. Some times you do like the pretty code from something like Python, but you get backed into a performance corner, at least I could see that happening.
Python added the "horrible event-driven programming model of Node" in Python 3.6. The syntax is said to be better, though.
The compute code for ML is emphatically not written in Python – Python is essentially a lightweight API wrapper around it.
Agreed that compute code for ML is not written in Python, but if GIL wasn't a problem there would be one less reason to drop down to C. Many users would appreciate that. Cython helps with the C part but to a degree.
If you have 16 CPUs in your system, seeing your load at 6% for the first 10% an last 10% of running time, and at 100% in-between surely will make people think there must be easy wins in that Python code. More so since many users will have effectively _zero_ knowledge of C.
Has it? Why the assumption that Go is a direct competitor?
My impression is that Go excels where Python does not, and vice-versa. I use both languages a lot for my day-job, and when using Go, I very much miss having an interpreter and a fully-interactive debugger (Delve is excellent considering the limitations imposed by Go, but much less flexible than pdb).
And let's not even talk about metaprogramming...
>We had anticipated interest from C, C++, and Java programmers, but the flurry of interest from users of dynamically-typed languages like Python and JavaScript was unexpected.
[1]: https://blog.golang.org/go-one-year-ago-today
In my experience, these people are using both languages for the reasons mentioned above.