User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.
I watch live streams of music producers working with DAWs and they actually end up needing to offload synthesis and filtering to multiple separate machines as they can't do it on one.
Also if you think things aren't CPU-bound then why do you think people spend hundreds or thousands of dollars on CPUs?
The vast majority of what the vast majority of users do on computers remains non-CPU-bound. I chose not enumerate all the exceptions, because as usual, they are exceptions.
Most people aren't doing CPU-bound work and there's no point parallelising your application... but people are buying 32-core processors? Why do you think they're doing that?
I'm just a normal developer and I am very frequently CPU-bound in my work, and I see many other people in other fields also CPU-bound. I'd absolutely love to have a massive Xeon in my laptop. I think it'd have a genuine impact on my productivity.
And sure, as someone who regularly spends 4 minutes waiting for my 16 core threadripper to build my application, I appreciate the sentiment.
But ... this is very very far from the majority of computer users do and quite far from what "supercomputers" are used for (frequent, repeated, long lived CPU-bound workloads).
Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common
And, having done plenty of video dev work recently, beyond the codecs and GPUs, it's also memory bandwidth/lock contention/data path that's really key for getting good video performance. We're almost never decoding or encoding video by CPU anymore. If we can avoid it.
Arguably with JS heavy web browsing you're also looking at memory bandwidth or lock contention as a key limitation -- garbage collection in the JS interpreter, fetching and dispatching opcodes, etc. CPU is only part of the story.
Life just became so so very complicated in the 90s when CPU performance started to compltely outstrip main memory and bus performance.
2) video conferencing is not CPU-bound unless you're doing 1-to-many/many-to-1 feeds locally.
3) JS heavy web browsing ... 'nuff said.
4) Very few people do video editing that is CPU bound. Certainly for video editors, it is an issue.
Clearly, I should have said:
"The majority of applications used by the majority of users are rarely CPU-bound"
Have you ever played around with BeOS or its community-driven successor Haiku? They are what's called "pervasively multithreaded" such that every single widget in the standard UI toolkit has its own thread. It's literally possible in BeOS/Haiku to lower the priority of a single radio button.
This is an OS designed around early '90s era dual CPU hardware. Considering that they made this choice at that time and still ended up with an OS that's remembered primarily for its performance and responsiveness when multitasking it seems hard to believe that threading overhead itself is too big of a deal even at extreme levels.
> IIRC super computers often need special interconnects and software to minimize the distribution costs of so many cores.
This is for entirely different reasons. The specialized supercomputer interconnects exist to minimize the cost of sharing data across nodes. Basically they provide DMA over a network fabric. It only really matters once your workload is large enough that you can't just throw a larger single machine at it but also impossible to split up in to smaller chunks that would fit within individual nodes.
If you're familiar with NUMA in multi-socket systems (or first-gen Epyc/Threadripper) you can think of the supercomputer interconnects as basically extending that principle up another tier to encompass multiple independent servers.
This is not true, individual widgets most definitely do not have their own threads. Windows each have their own threads, which is indeed different from virtually every other OS which does not have this (or even allow off-the-main-thread UI operations.)
The only reasonable option for UI rendering these days (high-DPI monitors) is to delegate rasterization to GPU. CPU is for running application logic. If you would do UI on CPU then this will be the only task your CPU will do. E.g. animations require stable frame rate (60 FPS or more) so UI must run on highest possible priority on your OS.
My comment is rather about "multi-core UI". Many UI tasks have almost real-time requirements (animations, synchronized rendering, video) so they behave as "make -j 4" meaning that the device is just busy rasterizing pixels but not doing anything meaningful.
And all that while we have dedicated powerful (YMMV) GPU that supposed to do those for us.
Obviously actual pixel rendering is is done on a GPU - why would you do it it anywhere else, but that's not what we're talking about here.
It could be that you need to “renice -5” X11 or something (I think some distributions used to tweak the UI runtime priorities. Not sure if they still do.)
I don't understand what you mean - individual applications within a multi-application system can absolutely utilise multiple cores. It isn't true that it won't work. The kernel schedules all the tasks of all applications across the available cores.
And even if you have many applications running, most of them don't need multiple cores all the time, so it makes sense for each application to be able to use as many cores as possible, when the user is looking at it and doing something.
For example if I'm using my text editor and browsing docs. My text editor only needs tiny a fraction of a core every now and again, but each time I navigate it'd be great if the browser temporarily used all sixteen cores to do that as quickly as possible.