5 ms·

You have two choices when it comes to utilizing multiple cores: threads and processes. Threads are hard, but sharing data between processes is hardly any easier

You have two choices when it comes to utilizing multiple cores: threads and processes. Threads are hard, but sharing data between processes is hardly any easier. Maybe they're a bad idea, but these days you have no choice but to learn how to use threads. AMD's run-of-the-mill processors have 16 cores, Intel's 8. Servers have lots more. Heck even your iPhone has 6. The clock rate on CPUs isn't getting any better. It's just more cores from here on.

jovial_cavalier 7y ago
He says at the end that if you want true concurrency, use threads. But the point is that many people use threads where concurrency is not a requirement, or even desirable.
- deleted 7y ago
  [deleted]
- chrisseaton 7y ago
  > But the point is that many people use threads where concurrency is not a requirement, or even desirable. reply Why would you write a program using threads if you don't require concurrency? The only purpose of threads is to achieve concurrency. Can you give some examples?
  - plapetomain 7y ago
    Think of an object oriented system. You can have a thread per object at the extreme where each object has its own thread/queue to handle messages. For most cases with synchronous calls you’re not really getting any concurrency. Maybe it’s hard to imagine now, but in the 80s and 90s there were people that pushed this sort of architecture with a straight face. Even if not this extreme the idea of using threads for componentization rather than a focus on concurrency..which was possibly a side benefit was very much a thing (think COM/CORBA)) Hence why many articles like this and Ousterhout from the 90s, etc saying it was idiotic.
    - aidenn0 7y ago
      I worked on an embedded system with 1 thread per object and it was a very good ratio of code-to-expressivity (both when being used, and the implementation of the system). Each logical hardware port had its own thread, and was interacted with solely through message passing.
      - brandmeyer 7y ago
        This is pretty much exactly the kind of robust system architecture that Erlang advocates employ. In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty. I'm not convinced that the penalty in Linux is all that high, either. Its only when you're going after the C10K (or C1M?) problem that you start to notice.
        aidenn0 7y ago
        > In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty. Right, this system would run through the entire runlist at several kHz when idle and 0.5-1kHz under load on a PowerPC 405 that ran at about 200MIPS. Our shortest deadline was 10ms so it was plenty fast enough. Context switch was swapping out 12 machine words.
  - jandrese 7y ago
    I think that is referring to the case of "select() is too confusing, I'll use threads instead so I won't have to think about it."
    - chrisseaton 7y ago
      I think I'd still call that concurrency - you want multiple continuations to preserve state between IO calls.
  - sgerenser 7y ago
    Not the person you were asking the question to, but I can give you tons of examples. This is particularly true in the embedded space or people who write C or C++ that doesn’t have any standard event library. Basically, threads are a lowest-common denominator way to do blocking operations without stalling everything. I’ve seen a lot of code where there’s various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff, another thread that does nothing but blink an LED, etc.) But in reality, in most non-cpu bound workloads, using an event loop would make writing this kind of code much easier and you woulnd’t ever have to worry about mutexes, semaphores, deadlocks, etc. As a C++ programmer, using Qt (even for non-UI stuff) with its event loop is just so much easier than spinning up threads just to call a network endpoint. That being said, threads definitely have their place and are the only real way to take advantage of all the power offered by modern multi-core CPUs (well that and multi-process but that’s not really any easier to get right). But for the basic stuff I think running 80 threads when your app is only using 5% cpu is insane (something I see a lot in the C++ code I’m exposed to).
    - chrisseaton 7y ago
      Aren't all your examples still examples of concurrency? > way to do blocking operations without stalling everything Switching between multiple tasks doing IO - that's concurrency isn't it? > various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff Different tasks ready to run and switching between them as needed - that's concurrency again isn't it? Not really sure what everyone else in this thread is seeing that I'm not.
      - justincredible 7y ago
        The confusion might be due to everyone using concurrency to mean concurrency and/or parallelism.
      - sgerenser 7y ago
        OK, sure those are actually examples of concurrency. I was thinking of concurrency more along the lines of multiple threads of execution doing useful work at the same time, which threads are actually good at doing but these examples are not that.
  - mjpuser 7y ago
    I think that programmers are quick to jump to concurrency when they want to make something performant as opposed to using other structures, like a cache, or researching other possible solutions, like the HN favorite bloom filter, or other algorithm.
  - jovial_cavalier 7y ago
    >why would you write a program to use threads if you don't need concurrency? ... exactly. There is no good reason. That's what I'm saying the point of the article is. However, this doesn't mean that people don't do it. He is saying that the tasks that people typically use threads to solve can actually be solved with an event loop and handlers, thus eliminating all of the messy issues with shared state, race conditions, etc. that true concurrency introduces.
redisman 7y ago
It's good but not quite as good. 16 core is the high end of consumer CPUs, mid-range is probably more like 6 or 8 cores.
didibus 7y ago
That said, threads don't give you quite the boost you might be hoping for. Even with things that can parallelize well, it seems at around 8 or 12 threads you start to hit a wall.
- dirtydroog 7y ago
  How so? How many cores on the machine? Maybe you have some false-sharing, maybe thermal throttling is kicking in.
  - didibus 7y ago
    Some of what I heard is memory access bottlenecks and cache coherency bottlenecks.
marcosdumay 7y ago
It being hard to share memory is a feature, not a bug. Threads make any single thing on your program mutable without your direct control. Processes keep the mutability scoped into a few hard to extend areas.
- dirtydroog 7y ago
  'const' all the things.
- FartyMcFarter 7y ago
  > Threads make any single thing on your program mutable without your direct control. No they don't. Threads don't mutate random variables by themselves, you need actual code that does the mutation (whether it's running on a separate thread or not). I mean, how is that statement different from "calling other functions makes any single thing on your program mutable"?
  - marcosdumay 7y ago
    > how is that statement different from "calling other functions makes any single thing on your program mutable"? On those languages where functions mutate things, that's basically true. But it's much more common that functions can only mutate global variables, and people keep those in low numbers, exactly for that reason. Actually, replace "functions" with "methods" and you will get into one of the largest flaws of OOP. But anyway, mutability is much less of a problem outside of concurrent code.
ychen306 7y ago
I think he's referring to threads as a programming model, not the physical implementation.

jovial_cavalier 7y ago

He says at the end that if you want true concurrency, use threads. But the point is that many people use threads where concurrency is not a requirement, or even desirable.

deleted 7y ago
[deleted]
chrisseaton 7y ago
> But the point is that many people use threads where concurrency is not a requirement, or even desirable. reply Why would you write a program using threads if you don't require concurrency? The only purpose of threads is to achieve concurrency. Can you give some examples?
- plapetomain 7y ago
  Think of an object oriented system. You can have a thread per object at the extreme where each object has its own thread/queue to handle messages. For most cases with synchronous calls you’re not really getting any concurrency. Maybe it’s hard to imagine now, but in the 80s and 90s there were people that pushed this sort of architecture with a straight face. Even if not this extreme the idea of using threads for componentization rather than a focus on concurrency..which was possibly a side benefit was very much a thing (think COM/CORBA)) Hence why many articles like this and Ousterhout from the 90s, etc saying it was idiotic.
  - aidenn0 7y ago
    I worked on an embedded system with 1 thread per object and it was a very good ratio of code-to-expressivity (both when being used, and the implementation of the system). Each logical hardware port had its own thread, and was interacted with solely through message passing.
    - brandmeyer 7y ago
      This is pretty much exactly the kind of robust system architecture that Erlang advocates employ. In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty. I'm not convinced that the penalty in Linux is all that high, either. Its only when you're going after the C10K (or C1M?) problem that you start to notice.
      - aidenn0 7y ago
        > In embedded systems, our kernels and threads are lightweight enough that we can go very fine-grained without paying a steep context-switching penalty. Right, this system would run through the entire runlist at several kHz when idle and 0.5-1kHz under load on a PowerPC 405 that ran at about 200MIPS. Our shortest deadline was 10ms so it was plenty fast enough. Context switch was swapping out 12 machine words.
- jandrese 7y ago
  I think that is referring to the case of "select() is too confusing, I'll use threads instead so I won't have to think about it."
  - chrisseaton 7y ago
    I think I'd still call that concurrency - you want multiple continuations to preserve state between IO calls.
- sgerenser 7y ago
  Not the person you were asking the question to, but I can give you tons of examples. This is particularly true in the embedded space or people who write C or C++ that doesn’t have any standard event library. Basically, threads are a lowest-common denominator way to do blocking operations without stalling everything. I’ve seen a lot of code where there’s various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff, another thread that does nothing but blink an LED, etc.) But in reality, in most non-cpu bound workloads, using an event loop would make writing this kind of code much easier and you woulnd’t ever have to worry about mutexes, semaphores, deadlocks, etc. As a C++ programmer, using Qt (even for non-UI stuff) with its event loop is just so much easier than spinning up threads just to call a network endpoint. That being said, threads definitely have their place and are the only real way to take advantage of all the power offered by modern multi-core CPUs (well that and multi-process but that’s not really any easier to get right). But for the basic stuff I think running 80 threads when your app is only using 5% cpu is insane (something I see a lot in the C++ code I’m exposed to).
  - chrisseaton 7y ago
    Aren't all your examples still examples of concurrency? > way to do blocking operations without stalling everything Switching between multiple tasks doing IO - that's concurrency isn't it? > various threads running at different intervals (low priority background thread that sleeps for 1 second then wakes up to do stuff Different tasks ready to run and switching between them as needed - that's concurrency again isn't it? Not really sure what everyone else in this thread is seeing that I'm not.
    - justincredible 7y ago
      The confusion might be due to everyone using concurrency to mean concurrency and/or parallelism.
    - sgerenser 7y ago
      OK, sure those are actually examples of concurrency. I was thinking of concurrency more along the lines of multiple threads of execution doing useful work at the same time, which threads are actually good at doing but these examples are not that.
- mjpuser 7y ago
  I think that programmers are quick to jump to concurrency when they want to make something performant as opposed to using other structures, like a cache, or researching other possible solutions, like the HN favorite bloom filter, or other algorithm.
- jovial_cavalier 7y ago
  >why would you write a program to use threads if you don't need concurrency? ... exactly. There is no good reason. That's what I'm saying the point of the article is. However, this doesn't mean that people don't do it. He is saying that the tasks that people typically use threads to solve can actually be solved with an event loop and handlers, thus eliminating all of the messy issues with shared state, race conditions, etc. that true concurrency introduces.

redisman 7y ago

It's good but not quite as good. 16 core is the high end of consumer CPUs, mid-range is probably more like 6 or 8 cores.

didibus 7y ago

That said, threads don't give you quite the boost you might be hoping for. Even with things that can parallelize well, it seems at around 8 or 12 threads you start to hit a wall.

dirtydroog 7y ago
How so? How many cores on the machine? Maybe you have some false-sharing, maybe thermal throttling is kicking in.
- didibus 7y ago
  Some of what I heard is memory access bottlenecks and cache coherency bottlenecks.

marcosdumay 7y ago

It being hard to share memory is a feature, not a bug. Threads make any single thing on your program mutable without your direct control. Processes keep the mutability scoped into a few hard to extend areas.

dirtydroog 7y ago
'const' all the things.
FartyMcFarter 7y ago
> Threads make any single thing on your program mutable without your direct control. No they don't. Threads don't mutate random variables by themselves, you need actual code that does the mutation (whether it's running on a separate thread or not). I mean, how is that statement different from "calling other functions makes any single thing on your program mutable"?
- marcosdumay 7y ago
  > how is that statement different from "calling other functions makes any single thing on your program mutable"? On those languages where functions mutate things, that's basically true. But it's much more common that functions can only mutate global variables, and people keep those in low numbers, exactly for that reason. Actually, replace "functions" with "methods" and you will get into one of the largest flaws of OOP. But anyway, mutability is much less of a problem outside of concurrent code.

ychen306 7y ago

I think he's referring to threads as a programming model, not the physical implementation.