11 ms·

I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads?

by cmeacham98 4y ago

nickysielicki 4y ago
If not today, definitely tomorrow.
woodruffw 4y ago
Why not? I just opened htop on my desktop, and I have 789 threads running over 117 processes, with 12 logical cores.
piperswe 4y ago
My Ryzen 5 3600X (a years-old mid-range CPU) has 6 cores and 12 threads, I wouldn't say that's atypical.
aldanor 4y ago
Given that many phones these days have half a dozen cores...
mardifoufs 4y ago
> I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads? I think you are mixing hyperthreading, or SMT with regular "software" threading
- astrange 4y ago
  They're mixing parallelism and concurrency. (nb: I might be abusing these terms too) Parallelism aka CPU-bound tasks are limited by the number of cores you have. Concurrency aka IO-bound tasks are not, because they're usually not all runnable at once. It can be faster to go concurrent even on a single core because you can overlap IOs, but it'll use more memory and other resources. Also, "going faster" isn't always a good thing. If you're a low priority system task, you don't want to consume all the system resources because the user's apps might need them. Or the the user doesn't want the fans to turn on, or it's a passive cooled system that shouldn't get too hot, etc. And for both of them, it not only makes it easier to write bugs in unsafe languages, but in safe languages you can easily accidentally make things slower instead of faster just because it's complicated.
  - Jtsummers 4y ago
    Rob Pike tried to create a distinction here: https://go.dev/talks/2012/waza.slide#1 https://go.dev/talks/2012/waza.slide#1 Using his distinction, concurrency isn't about IO-boundedness (though that's a common use-case for it), but instead is about composing multiple processes (generic sense). They may or may not be running in parallel (truly running at the same time). On a unix shell this would be an example of concurrency, which may or may not be parallel: $ cat a-file | sort | uniq | wc Each process may run at the literal same time (parallelism), but they don't have to, and on a single core machine would not be executing simultaneously. This hasn't fully caught on, though.
    - naniwaduni 4y ago
      Yes, not catching on is a common problem when you invent distinctions not borne out by existing practice.
  - yvdriess 4y ago
    A succinct way to distinguish both is to focus on what problem they solve: > Concurrency is concerned about correctness, parallelism concerned about performance. Concurrency is concerned about keeping things correct[1] when multiple things are happening at once and sharing resources. The reason why those problems arise might be for performance reasons, e.g. multiplexing IO over different threads. As such, performance is still a concern. But, your solution space still involves the thread and IO resources, and how they interleave. Parallelism is in a different solution space: you are looking at the work space (e.g. iteration space) of the problem domain and designing your algorithm to be logically sub-dividable to get the maximum parallel speedup (T_1 / T_inf). Now, a runtime or scheduler will have to do the dirty work of mapping the logical subdivisions to hardware execution units, and that scheduler program is of course full of concurrency concerns. [1] For the sake of pedantry: yes, parallelism is sometimes also used to deal with correctness concerns: e.g. do the calculation on three systems and see if the results agree.
aerxes 4y ago
Gonna beat a dead horse here, but >50% of PCs that are surveyed by Steam have 12 threads or more. That’s PCs that have steam installed at all. Intel’s bare minimum current-gen i3 processor has 12 threads. That’s the absolute cheapest desktop-level processor you can get. Your phone probably has 6 cores (though not 12 threads). So yes, if you’re writing code for desktop hardware, it’s safe to assume you have at least 8 threads. Maybe you don’t want to consume all of them, but it’s better to let the OS handle scheduling. https://www.techspot.com/article/2363-multi-core-cpu/ https://www.techspot.com/article/2363-multi-core-cpu/
- cmeacham98 4y ago
  This article doesn't say that, what it actually says is "Over 70% of Steam users have a CPU with 4 or more cores." Steam doesn't even measure publicize information about threads on the survey, which makes it near impossible to check because not that long ago Intel locked out hyperthreading/SMT on their low/mid-grade CPUs. Additionally, and more importantly: the Steam hardware survey _obviously_ doesn't represent the average consumer PC.
  - aerxes 4y ago
    The data that it presents shows that >50% of PCs surveyed have 6 cores or more.
    - rob74 4y ago
      >50% of PCs which have Steam installed, i.e. are used for gaming. So the statistic is not really representative of all PCs out there...
      - loup-vaillant 4y ago
        The fact remains that virtually all systems except perhaps old low-end phones now have more than one thread. Not going multi-thread for anything that makes the user wait leaves significant performance on the table. Low end systems (4 threads or less) have less potential, but they also have the most need for speed, making multi-threading quite important. And high-end systems have more threads, so going multi-thread makes a bigger difference.
Asraelite 4y ago
Today, it's debatable, but if we're talking about programming languages for the future then the future is what's relevant. I don't think it will be long before 50+ thread CPUs are common. Multithreading won't be a nice-to-have feature, it will be a necessity.
jiggawatts 4y ago
My laptop has 8 cores and 16 threads. I'm about to buy a PC with 16 cores and 32 threads for "normal" money. The AMD EPYC server CPUs scale to dual sockets with 64-cores each, for a whopping 256 hardware threads in a single box. That's not some sort of esoteric hyper-scale configuration, but completely ordinary off-the-shelf stuff you can get in large quantities from mainstream vendors. A single-threaded application on a server like that will use between 0.5% to about 50% of the total available performance, depending on where its bottleneck is. It will never reach 100%! This matters to things like CLI tools, batch jobs, and the like, many of which are written in C, especially in the Linux world. A case-in-point that demonstrates how much performance has been left on the table is ripgrep, which is a multi-threaded Rust replacement for grep.

I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads?

nickysielicki 4y ago

If not today, definitely tomorrow.

woodruffw 4y ago

Why not? I just opened htop on my desktop, and I have 789 threads running over 117 processes, with 12 logical cores.

piperswe 4y ago

My Ryzen 5 3600X (a years-old mid-range CPU) has 6 cores and 12 threads, I wouldn't say that's atypical.

aldanor 4y ago

Given that many phones these days have half a dozen cores...

mardifoufs 4y ago

> I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads? I think you are mixing hyperthreading, or SMT with regular "software" threading

astrange 4y ago
They're mixing parallelism and concurrency. (nb: I might be abusing these terms too) Parallelism aka CPU-bound tasks are limited by the number of cores you have. Concurrency aka IO-bound tasks are not, because they're usually not all runnable at once. It can be faster to go concurrent even on a single core because you can overlap IOs, but it'll use more memory and other resources. Also, "going faster" isn't always a good thing. If you're a low priority system task, you don't want to consume all the system resources because the user's apps might need them. Or the the user doesn't want the fans to turn on, or it's a passive cooled system that shouldn't get too hot, etc. And for both of them, it not only makes it easier to write bugs in unsafe languages, but in safe languages you can easily accidentally make things slower instead of faster just because it's complicated.
- Jtsummers 4y ago
  Rob Pike tried to create a distinction here: https://go.dev/talks/2012/waza.slide#1 https://go.dev/talks/2012/waza.slide#1 Using his distinction, concurrency isn't about IO-boundedness (though that's a common use-case for it), but instead is about composing multiple processes (generic sense). They may or may not be running in parallel (truly running at the same time). On a unix shell this would be an example of concurrency, which may or may not be parallel: $ cat a-file | sort | uniq | wc Each process may run at the literal same time (parallelism), but they don't have to, and on a single core machine would not be executing simultaneously. This hasn't fully caught on, though.
  - naniwaduni 4y ago
    Yes, not catching on is a common problem when you invent distinctions not borne out by existing practice.
- yvdriess 4y ago
  A succinct way to distinguish both is to focus on what problem they solve: > Concurrency is concerned about correctness, parallelism concerned about performance. Concurrency is concerned about keeping things correct[1] when multiple things are happening at once and sharing resources. The reason why those problems arise might be for performance reasons, e.g. multiplexing IO over different threads. As such, performance is still a concern. But, your solution space still involves the thread and IO resources, and how they interleave. Parallelism is in a different solution space: you are looking at the work space (e.g. iteration space) of the problem domain and designing your algorithm to be logically sub-dividable to get the maximum parallel speedup (T_1 / T_inf). Now, a runtime or scheduler will have to do the dirty work of mapping the logical subdivisions to hardware execution units, and that scheduler program is of course full of concurrency concerns. [1] For the sake of pedantry: yes, parallelism is sometimes also used to deal with correctness concerns: e.g. do the calculation on three systems and see if the results agree.

aerxes 4y ago

Gonna beat a dead horse here, but >50% of PCs that are surveyed by Steam have 12 threads or more. That’s PCs that have steam installed at all. Intel’s bare minimum current-gen i3 processor has 12 threads. That’s the absolute cheapest desktop-level processor you can get. Your phone probably has 6 cores (though not 12 threads). So yes, if you’re writing code for desktop hardware, it’s safe to assume you have at least 8 threads. Maybe you don’t want to consume all of them, but it’s better to let the OS handle scheduling. https://www.techspot.com/article/2363-multi-core-cpu/ https://www.techspot.com/article/2363-multi-core-cpu/

cmeacham98 4y ago
This article doesn't say that, what it actually says is "Over 70% of Steam users have a CPU with 4 or more cores." Steam doesn't even measure publicize information about threads on the survey, which makes it near impossible to check because not that long ago Intel locked out hyperthreading/SMT on their low/mid-grade CPUs. Additionally, and more importantly: the Steam hardware survey _obviously_ doesn't represent the average consumer PC.
- aerxes 4y ago
  The data that it presents shows that >50% of PCs surveyed have 6 cores or more.
  - rob74 4y ago
    >50% of PCs which have Steam installed, i.e. are used for gaming. So the statistic is not really representative of all PCs out there...
    - loup-vaillant 4y ago
      The fact remains that virtually all systems except perhaps old low-end phones now have more than one thread. Not going multi-thread for anything that makes the user wait leaves significant performance on the table. Low end systems (4 threads or less) have less potential, but they also have the most need for speed, making multi-threading quite important. And high-end systems have more threads, so going multi-thread makes a bigger difference.

Asraelite 4y ago

Today, it's debatable, but if we're talking about programming languages for the future then the future is what's relevant. I don't think it will be long before 50+ thread CPUs are common. Multithreading won't be a nice-to-have feature, it will be a necessity.

jiggawatts 4y ago

My laptop has 8 cores and 16 threads. I'm about to buy a PC with 16 cores and 32 threads for "normal" money. The AMD EPYC server CPUs scale to dual sockets with 64-cores each, for a whopping 256 hardware threads in a single box. That's not some sort of esoteric hyper-scale configuration, but completely ordinary off-the-shelf stuff you can get in large quantities from mainstream vendors. A single-threaded application on a server like that will use between 0.5% to about 50% of the total available performance, depending on where its bottleneck is. It will never reach 100%! This matters to things like CLI tools, batch jobs, and the like, many of which are written in C, especially in the Linux world. A case-in-point that demonstrates how much performance has been left on the table is ripgrep, which is a multi-threaded Rust replacement for grep.