Common misconception. Most supercomputer tasks are communication-bound or memory-throughput-bound, and devs just try to fill the resulting slack with more work.

> User applications with GUIs are almost never CPU-bound

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?

I'm the author of a crossplatform DAW. I know what they are capable of. Also, that story of multiple systems is becoming a thing of the past in these days of 32 core ryzen threadrippers.

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.

I'd assume the author of ardour knows what they are talking about! I remember running most things just fine on a dual athlon mp, cubase and ardour. Granted this is quite awhile ago.

This seems contradictory to me.

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.

"Just a normal developer" ... you're already in a tiny minority of computer users.

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).

> User applications with GUIs are almost never CPU-bound, so the comparison is not really appropriate.

Video conferencing, JS heavy web browsing, video editing, and gaming are all examples of CPU-intense applications that are becoming increasingly common

Of the things you listed only JS would count as "CPU intense" in the strict definition of CPU as microprocessor unit; the others are typically bound on specialized hardware -- hardware video encoders/decoders, and GPUs.

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.

1) I don't tend to think of games as applications with GUIs, but you're right, they really are, and yes, they can be CPU-bound sometimes. However, a game that was actually CPU-bound would be very unpleasant to play. That's not true for the applications that run on super-computers: they just take longer to run that someone would like.

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"

But more importantly: even the exceptions are really nothing like "supercomputer workloads".