7 ms·

I'd like to know why people are downvoting this.

dragonwriter 9y ago
Probably because it treats a high-level feature (M:N threading) as equivalent to a lower-level feature (coroutines) and then compounds that by treating as equivalent languages where the former is built into the core with ones where the latter is available as a third-party library, all as a way of dismissing the value of languages where the former feature is built in to the core, and layered with scorn and derision on top of being doubly wrong. Now, I preferred correction to downvoting, but I can easily see why others would choose downvoting.
thehardsphere 9y ago
People often downvote anything that's remotely negative, even if it is true or merely a critical question.
supremesaboteur 9y ago
For Python there is no native support for threads because of GIL. You can get around this through multiprocessing etc but these are hacks
- pjmlp 9y ago
  Only relevant on CPython, other implementations don't have a GIL.
  - gebruikersnaam 9y ago
    PyPy has a GIL : http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-...
    - pjmlp 9y ago
      Ok, but ZipPy, Jython and IronPython do not.
      - weberc2 9y ago
        Have Jython and IronPython reached compatibility with Python 3 yet? Last I checked they hadn't, or it was still in alpha.
        pjmlp 9y ago
        I don't know, but Python 3 still isn't relevant to many people. For example, I have to explicitly install 2.7 to be able to use Cocos2d-x build scripts.
        weberc2 9y ago
        Maybe, but it seems like a bad idea to invest in Python 2 (which is teaching is ended of life) just to get parallelism when there are other programming languages that have great concurrency stories and a bright future. That said, if PyPy3 ditches the GIL, let me know!
        throwaway7645 9y ago
        Someone posted an article awhile back...people are moving over by a significant amount now.
        sli 9y ago
        Yeah, "not relevant to many people" is a wildly false claim. If it were anywhere near true, we wouldn't see the level of Python 3 support that we have in the major packages (95.8%). http://py3readiness.org/ http://py3readiness.org/
        throwaway7645 9y ago
        Yes, but ain't nobody really using Jython or IronPython. Yes some people are, but I'd bet a very small group of the greater Python whole. You also introduce incompatibilities that way. Perl6 has this in the base implementation, so I don't have to switch to a lesser maintained distribution.
    - reubano 9y ago
      But not PyPySTM
- askvictor 9y ago
  There is native support for threads, it's just that they don't run concurrently.
  - nothrabannosir 9y ago
    At this point the word is so far removed from the meaning in this thread you might as well say a haberdasher supports threads.
    - askvictor 9y ago
      There are valid reasons for programming with threads with only a single CPU (indeed when I learnedb thread programming in the 90s pretty much only single core cpus were available). For instance, IO blocking.
  - weberc2 9y ago
    While we're being pedantic, they do run concurrently (for example, dispatching a dozen concurrent HTTP requests), they just the GIL prevents most CPU work from executing in parallel.
  - dragonwriter 9y ago
    They do run in parallel, so long as all but one are running low-level library code which has released the GIL, but you can't call back into the runtime without grabbing the GIL.
- e12e 9y ago
  Afaik erlang has a lock as well - in fact I think most green thread implementations do: what you want/need at a minimum is one os process or thread per cpu core that works as a scheduler and then some form of (co-operative) scheduling with only user-mode/low-overhead context switching?
  - yellowapple 9y ago
    That doesn't sound right re: Erlang; its everything-is-immutable model is supposed to avoid the need for a GIL. Erlang processes are also preemptive, so there's no possibility for a process to lock up the whole VM (unless it calls into a long-running NIF, but native code is always dangerous in a "crash BEAM if you don't get it right" kind of way).
    - dragonwriter 9y ago
      IIRC, Erlang uses shared mutable state internally, though its not exposed, so it needs to lock around accesses to that, but this isn't equivalent to the Python GIL.
  - brightball 9y ago
    Scheduling and locking aren't the same thing. Here's a brief excerpt from Joe Armstrong that I found on SO while looking for a good explanation. > [Erlang] is a concurrent language – by that I mean that threads are part of the programming language, they do not belong to the operating system. That's really what's wrong with programming languages like Java and C++. It's threads aren't in the programming language, threads are something in the operating system – and they inherit all the problems that they have in the operating system. One of the problems is granularity of the memory management system. The memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size of a page. That's actually too big. > If you add more memory to your machine – you have the same number of bits that protects the memory so the granularity of the page tables goes up – you end up using say 64kB for a process you know running in a few hundred bytes. With Erlang, there are threads running concurrently across multiple CPU's and a preemptive scheduler within each of those threads. This is all transparent through use of Erlang processes. Essentially, many concurrent schedulers managing hundreds of thousands of processes that start out at 0.5kb each. A JVM thread is 1024kb by comparison and a goroutine is 2kb. You're getting legitimate concurrency with Erlang, as well as isolation. There are only so many things that a single CPU can do at the same time and that's where the scheduler becomes necessary. The scheduler also ensure that if you fire off 100,000 processes and one of them is CPU intensive that it can't hog the processor and preventing the others allocated to that processor from executing.
- anonacct37 9y ago
  You might have chosen bad words, but people reading this should know this statement it false. Python has threads. You can create them and (if you're using linux) see them in the /proc filesystem. A more accurate statement is: "python bytecode can't execute concurrently w/o something like multiprocessing". The key difference? You can do multithreaded I/O all day long, which is a pretty important use case of threading. You can also hand off work to C and release the GIL, although this isn't as common. Example: XML parsing, regex, numeric work. FWIW all these gotchas are one of the reasons I love just having complete threading support built in to my language.
  - chrisseaton 9y ago
    > A more accurate statement is: "python bytecode can't execute concurrently No this isn't any more accurate. Python bytecode does execute concurrently if you have multiple threads. It just doesn't execute in parallel.
  - ensiferum 9y ago
    In fact it is quite common. If you look into the c modules you see a pattern where they release the gil before performing some operation and then reacquire it
StevePerkins 9y ago
Ehh... I don't really understand the impulse to "call out" downvotes, or ask people to explain why they're downvoting something that you wrote or agree with. It's probably just my age, as I started out online when most discussion forums lacked explicit voting mechanisms. Before social media came along, and "gamified" human conversation. Maybe it helps police trolls, but at the cost of encouraging group-think and excessive meme-referencing, and just making a lot of people more neurotic and insecure in general. Overall, I think that online discussion is worse than it was 15 years ago, due to the psychological effects of all the imaginary Internet points. But anyhoo, at the time I saw this (45 minutes after my original comment), my comment had 25 votes and was the top-most thing on this page. More often than not, if you wait an hour, the crowd straightens out the impact of any early outliers.
- rootlocus 9y ago
  There's a difference between downvoting because you don't like the tone or don't agree on something subjective and downvoting because something is incorrect or inaccurate. If people downvote because it's incorrect I'd like to know what's incorrect about it. > But anyhoo, at the time I saw this (45 minutes after my original comment), my comment had 25 votes and was the top-most thing on this page. It was grayed out at the bottom of the page when I saw it.
- reitanqild 9y ago
  Ehh... I don't really understand the impulse to "call out" downvotes, or ask people to explain why they're downvoting something that you wrote or agree with. Sometimes there is some really weird voting dynamic here and it would be interesting to know what goes on. For a lack of a better word you can call it intellectual curiosity or something.
  - sanderjd 9y ago
    I can't remember the last time I saw a reasonable comment more than a half hour or so old greyed out. But I often see highly-voted comment with an old greyed-out reply saying "why is this being downvoted". All that's happening is that the sample size of votes is too small early on to be meaningful.
lackbeard 9y ago
Because it not a helpful comment. It's wrong in a lot of ways and misleading in others. Like dragonwriter said, having coroutines in your language or a fiber library is not close to the same thing as the language having a scheduler that maps those fibers onto native threads for you. Some of the languages mentioned can't even execute multiple threads on multiple cores in parallel.
kafkaesq 9y ago
I'd like to know why people are downvoting this. Because for some people, it's not enough to think of others as misinformed, or not so well-spoken. They need to be thought of as blundering idiots, and castigated accordingly.

Probably because it treats a high-level feature (M:N threading) as equivalent to a lower-level feature (coroutines) and then compounds that by treating as equivalent languages where the former is built into the core with ones where the latter is available as a third-party library, all as a way of dismissing the value of languages where the former feature is built in to the core, and layered with scorn and derision on top of being doubly wrong. Now, I preferred correction to downvoting, but I can easily see why others would choose downvoting.

thehardsphere 9y ago

People often downvote anything that's remotely negative, even if it is true or merely a critical question.

supremesaboteur 9y ago

For Python there is no native support for threads because of GIL. You can get around this through multiprocessing etc but these are hacks

pjmlp 9y ago
Only relevant on CPython, other implementations don't have a GIL.
- gebruikersnaam 9y ago
  PyPy has a GIL : http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-...
  - pjmlp 9y ago
    Ok, but ZipPy, Jython and IronPython do not.
    - weberc2 9y ago
      Have Jython and IronPython reached compatibility with Python 3 yet? Last I checked they hadn't, or it was still in alpha.
      - pjmlp 9y ago
        I don't know, but Python 3 still isn't relevant to many people. For example, I have to explicitly install 2.7 to be able to use Cocos2d-x build scripts.
        weberc2 9y ago
        Maybe, but it seems like a bad idea to invest in Python 2 (which is teaching is ended of life) just to get parallelism when there are other programming languages that have great concurrency stories and a bright future. That said, if PyPy3 ditches the GIL, let me know!
        throwaway7645 9y ago
        Someone posted an article awhile back...people are moving over by a significant amount now.
        sli 9y ago
        Yeah, "not relevant to many people" is a wildly false claim. If it were anywhere near true, we wouldn't see the level of Python 3 support that we have in the major packages (95.8%). http://py3readiness.org/ http://py3readiness.org/
      - throwaway7645 9y ago
        Yes, but ain't nobody really using Jython or IronPython. Yes some people are, but I'd bet a very small group of the greater Python whole. You also introduce incompatibilities that way. Perl6 has this in the base implementation, so I don't have to switch to a lesser maintained distribution.
  - reubano 9y ago
    But not PyPySTM
askvictor 9y ago
There is native support for threads, it's just that they don't run concurrently.
- nothrabannosir 9y ago
  At this point the word is so far removed from the meaning in this thread you might as well say a haberdasher supports threads.
  - askvictor 9y ago
    There are valid reasons for programming with threads with only a single CPU (indeed when I learnedb thread programming in the 90s pretty much only single core cpus were available). For instance, IO blocking.
- weberc2 9y ago
  While we're being pedantic, they do run concurrently (for example, dispatching a dozen concurrent HTTP requests), they just the GIL prevents most CPU work from executing in parallel.
- dragonwriter 9y ago
  They do run in parallel, so long as all but one are running low-level library code which has released the GIL, but you can't call back into the runtime without grabbing the GIL.
e12e 9y ago
Afaik erlang has a lock as well - in fact I think most green thread implementations do: what you want/need at a minimum is one os process or thread per cpu core that works as a scheduler and then some form of (co-operative) scheduling with only user-mode/low-overhead context switching?
- yellowapple 9y ago
  That doesn't sound right re: Erlang; its everything-is-immutable model is supposed to avoid the need for a GIL. Erlang processes are also preemptive, so there's no possibility for a process to lock up the whole VM (unless it calls into a long-running NIF, but native code is always dangerous in a "crash BEAM if you don't get it right" kind of way).
  - dragonwriter 9y ago
    IIRC, Erlang uses shared mutable state internally, though its not exposed, so it needs to lock around accesses to that, but this isn't equivalent to the Python GIL.
- brightball 9y ago
  Scheduling and locking aren't the same thing. Here's a brief excerpt from Joe Armstrong that I found on SO while looking for a good explanation. > [Erlang] is a concurrent language – by that I mean that threads are part of the programming language, they do not belong to the operating system. That's really what's wrong with programming languages like Java and C++. It's threads aren't in the programming language, threads are something in the operating system – and they inherit all the problems that they have in the operating system. One of the problems is granularity of the memory management system. The memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size of a page. That's actually too big. > If you add more memory to your machine – you have the same number of bits that protects the memory so the granularity of the page tables goes up – you end up using say 64kB for a process you know running in a few hundred bytes. With Erlang, there are threads running concurrently across multiple CPU's and a preemptive scheduler within each of those threads. This is all transparent through use of Erlang processes. Essentially, many concurrent schedulers managing hundreds of thousands of processes that start out at 0.5kb each. A JVM thread is 1024kb by comparison and a goroutine is 2kb. You're getting legitimate concurrency with Erlang, as well as isolation. There are only so many things that a single CPU can do at the same time and that's where the scheduler becomes necessary. The scheduler also ensure that if you fire off 100,000 processes and one of them is CPU intensive that it can't hog the processor and preventing the others allocated to that processor from executing.
anonacct37 9y ago
You might have chosen bad words, but people reading this should know this statement it false. Python has threads. You can create them and (if you're using linux) see them in the /proc filesystem. A more accurate statement is: "python bytecode can't execute concurrently w/o something like multiprocessing". The key difference? You can do multithreaded I/O all day long, which is a pretty important use case of threading. You can also hand off work to C and release the GIL, although this isn't as common. Example: XML parsing, regex, numeric work. FWIW all these gotchas are one of the reasons I love just having complete threading support built in to my language.
- chrisseaton 9y ago
  > A more accurate statement is: "python bytecode can't execute concurrently No this isn't any more accurate. Python bytecode does execute concurrently if you have multiple threads. It just doesn't execute in parallel.
- ensiferum 9y ago
  In fact it is quite common. If you look into the c modules you see a pattern where they release the gil before performing some operation and then reacquire it

StevePerkins 9y ago

Ehh... I don't really understand the impulse to "call out" downvotes, or ask people to explain why they're downvoting something that you wrote or agree with. It's probably just my age, as I started out online when most discussion forums lacked explicit voting mechanisms. Before social media came along, and "gamified" human conversation. Maybe it helps police trolls, but at the cost of encouraging group-think and excessive meme-referencing, and just making a lot of people more neurotic and insecure in general. Overall, I think that online discussion is worse than it was 15 years ago, due to the psychological effects of all the imaginary Internet points. But anyhoo, at the time I saw this (45 minutes after my original comment), my comment had 25 votes and was the top-most thing on this page. More often than not, if you wait an hour, the crowd straightens out the impact of any early outliers.

rootlocus 9y ago
There's a difference between downvoting because you don't like the tone or don't agree on something subjective and downvoting because something is incorrect or inaccurate. If people downvote because it's incorrect I'd like to know what's incorrect about it. > But anyhoo, at the time I saw this (45 minutes after my original comment), my comment had 25 votes and was the top-most thing on this page. It was grayed out at the bottom of the page when I saw it.
reitanqild 9y ago
Ehh... I don't really understand the impulse to "call out" downvotes, or ask people to explain why they're downvoting something that you wrote or agree with. Sometimes there is some really weird voting dynamic here and it would be interesting to know what goes on. For a lack of a better word you can call it intellectual curiosity or something.
- sanderjd 9y ago
  I can't remember the last time I saw a reasonable comment more than a half hour or so old greyed out. But I often see highly-voted comment with an old greyed-out reply saying "why is this being downvoted". All that's happening is that the sample size of votes is too small early on to be meaningful.

lackbeard 9y ago

Because it not a helpful comment. It's wrong in a lot of ways and misleading in others. Like dragonwriter said, having coroutines in your language or a fiber library is not close to the same thing as the language having a scheduler that maps those fibers onto native threads for you. Some of the languages mentioned can't even execute multiple threads on multiple cores in parallel.

kafkaesq 9y ago

I'd like to know why people are downvoting this. Because for some people, it's not enough to think of others as misinformed, or not so well-spoken. They need to be thought of as blundering idiots, and castigated accordingly.