That wasn’t the point nor even an offhand comment in their post.
C++ is fine and has a lot of libraries built up — especially around image processing. It will be quite some time before Rust replaces C++. But if I had time to learn only one sugary C, it’d be Rust.
That’s what debate’s about. I do recognize that caring about single threaded workloads and performance do contribute to snappier UI (and backwards compatibility).
I’m not advocating making software multithreaded only, since obviously that doesn’t make sense.
But, in many modern languages (including c++) multi threading
1. Doesn’t significantly detract from the performance of single core systems
2. Can massively improve the performance of multi core systems, even with 2 cores or more.
For appropriate applications, the memory overhead and the cost of the bootstrapping code for instantiating a worker thread should be dwarfed by the time of actually computing the task (we’re talking about actions 100ms or longer). Not using multiple threads when you could reasonably half or quarter that time (without needing to drop support for single-core systems) is just foolish. If you’re that worried about single core performance then maintain two code paths, but at least recognize that the majority of commodity systems sold today, including the ones you listed, have multiple threads available to them to do the work that have the most painful wait times.
If we were arguing about designing vehicle safety testing suites for the worst performers (a very real problem that we have right now) we wouldn’t even be having this conversation.
Writing multithreaded applications increases the performance ceiling. If an application can’t take use of multiple threads, but is written in a multi-threaded way, there’s no harm done. It simply runs the multi threaded code in a single threaded way (think of ParArray) with a bit of overhead incurred for “becoming multithreaded”.
Reasoning out of adding multithreaded support for long running actions because “most systems can’t take use of the extra threads” is just irrational, especially since most modern commodity systems could have a linear improvement with the additional threads.
The single core systems are barely hurt by the memory overhead involved with provisioning CORE_NUM of worker threads. But the multi core systems can take massive advantages from it.
This reads as something obvious. Of course between choosing a simple solution and a complex over-architected solution, you would choose the simple one.
The key word here is “over-architected”. The author is nitpicking academic and bureaucratic architecture design that happens at large (arguably inefficient) companies. But they evolved that way to protect themselves, probably before testing was widely understood or implemented.
Regardless, it tries to make a sensationalist topic when in fact it’s trying to say “architecture is common sense” + don’t prematurely optimize.
Overall not the worst article but its incendiary nature rubs me the wrong way.
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.
C++ is fine and has a lot of libraries built up — especially around image processing. It will be quite some time before Rust replaces C++. But if I had time to learn only one sugary C, it’d be Rust.