4 ms·

What a nice talk. It's a shame the only question we got to hear him answer from the audience (only time left for 1) was such a lame troll. If you attend confere

by hueving 10y ago

What a nice talk. It's a shame the only question we got to hear him answer from the audience (only time left for 1) was such a lame troll. If you attend conferences, please don't waste everyone's time with nonsense. This is a python conference talking about a long-known perf issue and the guy just asked why not use another language. It's like going to WWDC and asking why everyone isn't using Android.

airless_bar 10y ago
I think it's a very valid question. Given that the constraints by the Python BDFL rule out any reasonable solution, why not move on?
- sametmax 10y ago
  The problem is that the question is in the wrong context. Somebody is trying very hard to do something despite those constraints. For free. Why would you even try to discourage him to do so ?
  - airless_bar 10y ago
    To save him time and frustration due to his project going nowhere?
    - sametmax 10y ago
      Since when trolling convinced somebody of anything? This was definitly not the intent of the troll, just a joke. But a badly executed one. It's like going to a political meeting, hearing somebody's plan to improve economy, and as a question asking him why not just change country. It makes little sense. Plus, everybody should consider the resume of the guy, cause he is not just a newcomer trying to show off. He is a hell of a good dev.
      - airless_bar 10y ago
        I don't believe that the question was meant to be a joke or a trolling attempt. The guy's competence isn't the issue. It's the requirements of what the fix can and cannot do. _Everything_ is a mess due to the massive technical debt of never improving key parts of the runtime. I mean what's the point of a runtime where adding threads makes things magnitudes slower than running in a single-thread? "But that's just the state right now, they will fix this!" No, they won't. Just as a perspective: People usually fight over a single percent of improvement or less when working on runtime concurrency. Nobody just goes in and fixes _magnitudes_ of performance issues without rethinking what has been done and picking a completely different approach. This is not about making things "faster". This is literally going from doing necessary work to discovering a way of not having to do the work at all anymore. That's just not going to happen. Neither locks nor reference counting have anywhere near this optimization potential given the current language semantics. I think the whole (C)Python community missed the train more than a decade ago. Things that necessarily had to happen just didn't happen. Many communities and groups of developers "professionalize" over time. This doesn't seem to have happened in Python. Just an example: C extensions. It has been clear for at least a decade that the existing C interface won't work for threading, "real" garbage collection, etc. What would have been smart: Providing a better interface 10 years ago, effectively giving C ext devs 10 years of time to migrate their code. This way efforts to remove the GIL today would have to satisfy one fewer constraint that's currently crippling all of the efforts. Same with a lot of other things ... getting rid of the GIL would have required changes to various parts of the stack over the years (GC, language -> Python 3?, APIs ...), turning the actual removal of the GIL just into a final act of a multi-step process. What actually happened: Nothing. And now they just try to break the large lock into millions of smaller locks ... in 2016. WAT? This just tells me that key people in the Python community never really gave a damn about the issue and therefore this guy will waste his time. I have never expected Python's demise, but it now seems that largely its culture and not its lacking technology brought it down for good. From my perspective, they should have never released Python 3 with a GIL. That's what broke Python's neck, finally.
        l1ambda 10y ago
        Interesting train of thought. So if I understand correctly the gist of it is that it starts to becomes so costly to fix Python than to use another language that already has threading...so why not just use another language.
needusername 10y ago
I have been subjected to more than a decade of Python propaganda about the GIL how it is a good thing because: * it prevents deadlocks * it prevents livelocks * it means you don't have to lock when you share across threads and how it's not a big deal because * you're IO-bound anyway * you can easily write performance critical parts in C * you can use multiple processes, in fact that's better design anyway So I would have asked more critical questions. Feel free to call that trolling if you want.
- booop 10y ago
  It seems to be a common mindset among python developers. You often hear the reason you can't have something in Python is because it's theoretically impossible, impractical and too difficult - but then it happens in another language. I was convinced that dynamic languages would always be slow (see https://wiki.python.org/moin/Why%20is%20Python%20slower%20than%20the%20xxx%20language https://wiki.python.org/moin/Why%20is%20Python%20slower%20th...) but then Google gave us V8.
soupshield 10y ago
I almost didn't watch this because it's over my head, but the speaker was enthusiastic and made it fun. It's a shame there wasn't time for questions. I'm now going to watch the original Larry Hastings GIL talk: https://www.youtube.com/watch?v=4zeHStBowEk https://www.youtube.com/watch?v=4zeHStBowEk

by hueving 10y ago

airless_bar 10y ago

I think it's a very valid question. Given that the constraints by the Python BDFL rule out any reasonable solution, why not move on?

sametmax 10y ago
The problem is that the question is in the wrong context. Somebody is trying very hard to do something despite those constraints. For free. Why would you even try to discourage him to do so ?
- airless_bar 10y ago
  To save him time and frustration due to his project going nowhere?
  - sametmax 10y ago
    Since when trolling convinced somebody of anything? This was definitly not the intent of the troll, just a joke. But a badly executed one. It's like going to a political meeting, hearing somebody's plan to improve economy, and as a question asking him why not just change country. It makes little sense. Plus, everybody should consider the resume of the guy, cause he is not just a newcomer trying to show off. He is a hell of a good dev.
    - airless_bar 10y ago
      I don't believe that the question was meant to be a joke or a trolling attempt. The guy's competence isn't the issue. It's the requirements of what the fix can and cannot do. _Everything_ is a mess due to the massive technical debt of never improving key parts of the runtime. I mean what's the point of a runtime where adding threads makes things magnitudes slower than running in a single-thread? "But that's just the state right now, they will fix this!" No, they won't. Just as a perspective: People usually fight over a single percent of improvement or less when working on runtime concurrency. Nobody just goes in and fixes _magnitudes_ of performance issues without rethinking what has been done and picking a completely different approach. This is not about making things "faster". This is literally going from doing necessary work to discovering a way of not having to do the work at all anymore. That's just not going to happen. Neither locks nor reference counting have anywhere near this optimization potential given the current language semantics. I think the whole (C)Python community missed the train more than a decade ago. Things that necessarily had to happen just didn't happen. Many communities and groups of developers "professionalize" over time. This doesn't seem to have happened in Python. Just an example: C extensions. It has been clear for at least a decade that the existing C interface won't work for threading, "real" garbage collection, etc. What would have been smart: Providing a better interface 10 years ago, effectively giving C ext devs 10 years of time to migrate their code. This way efforts to remove the GIL today would have to satisfy one fewer constraint that's currently crippling all of the efforts. Same with a lot of other things ... getting rid of the GIL would have required changes to various parts of the stack over the years (GC, language -> Python 3?, APIs ...), turning the actual removal of the GIL just into a final act of a multi-step process. What actually happened: Nothing. And now they just try to break the large lock into millions of smaller locks ... in 2016. WAT? This just tells me that key people in the Python community never really gave a damn about the issue and therefore this guy will waste his time. I have never expected Python's demise, but it now seems that largely its culture and not its lacking technology brought it down for good. From my perspective, they should have never released Python 3 with a GIL. That's what broke Python's neck, finally.
      - l1ambda 10y ago
        Interesting train of thought. So if I understand correctly the gist of it is that it starts to becomes so costly to fix Python than to use another language that already has threading...so why not just use another language.

needusername 10y ago

I have been subjected to more than a decade of Python propaganda about the GIL how it is a good thing because: * it prevents deadlocks * it prevents livelocks * it means you don't have to lock when you share across threads and how it's not a big deal because * you're IO-bound anyway * you can easily write performance critical parts in C * you can use multiple processes, in fact that's better design anyway So I would have asked more critical questions. Feel free to call that trolling if you want.

booop 10y ago
It seems to be a common mindset among python developers. You often hear the reason you can't have something in Python is because it's theoretically impossible, impractical and too difficult - but then it happens in another language. I was convinced that dynamic languages would always be slow (see https://wiki.python.org/moin/Why%20is%20Python%20slower%20than%20the%20xxx%20language https://wiki.python.org/moin/Why%20is%20Python%20slower%20th...) but then Google gave us V8.

soupshield 10y ago

I almost didn't watch this because it's over my head, but the speaker was enthusiastic and made it fun. It's a shame there wasn't time for questions. I'm now going to watch the original Larry Hastings GIL talk: https://www.youtube.com/watch?v=4zeHStBowEk https://www.youtube.com/watch?v=4zeHStBowEk