If I may channel the spirit of the Reg's FOSS desk correspondent for a moment, this is a sure sign that CPU design has got massively too complex, as a result of poor software design favouring brute force performance over parallelism.

Back in the 1980s, the Transputer demonstrated what could be achieved by a very simple processor design in a big array, coupled to good software designed to take advantage of the parallelism this allowed. Then we ignored that lesson, and went for brute force instead.

I'm not hopeful that this is being fixed, as I see few examples of mainstream software really, truly utilising parallelism. Oh, well...

GJC

"the Transputer demonstrated what could be achieved by a very simple processor design in a big array, coupled to good software designed to take advantage of the parallelism this allowed."

That is essentially what the compute based GPU design that the industry switched to in the 2010s is. The problem is that some things just don't scale well in parallel.

> The problem is that some things just don't scale well in parallel.

As we have seen machines moving to more and more cores in the CPU (with or without hyperthreading), it is only too obvious how few programs can even take advantage of using "more of what we are used to", let alone reworking to take advantage of GPUs. Bring up Task Manager - and fire up lots of separate apps just to make it look as though that CPU was a sensible buy.

(Then again, given what I've seen coders do with mutexes it is probably a good thing that we don't have everybody trying to parallelize...)

There's a reason that microkernels and parallel computing aren't ruling the world.

It doesn't always work as well in theory as you think because most things just aren't parallisable and the overhead involved in managing the logistics of both loses all the (theoretical) performance gains that you can get.

In the case of the former, it's supposed to provide better isolation and security, not performance. In the case of the average home machine your GPU is basically an isolated machine for a reason - it's inherently insecure in itself and the parallel code it executes can play with all kinds of stuff on the chip that it's not supposed to. The performance vs security tradeoff means that they made it very fast, very insecure, and then they only secure the stuff you can send to the card.

It's been that way with OSs and CPUs for far longer - Windows was performant and simple, and sacrificing security for that caused almost the problems that older and even modern Windows suffers with. Even basic memory security requires so many more checks, balances, isolation, middle-men handling data, etc. that it slows things down. Remember Spectre/Meltdown? Basically caused by a security tradeoff for performance in speculative execution (literally a performance-first feature).

And all the "first technologies" are insecure for years buy that helps them work faster and get to market first, and that almost always wins. 3DFX cards allowed arbitrary DMA to any part of memory for decades before anyone noticed that's how they worked.

Despite everyone's wrangling, few people actually care about security - they just want stuff to work and work fast and will pay for a faster chip over a more secure one. People's primary gripe about the Spectre/Meltdown fixes was "Oh, but it slows my computer down".

Parallelism, though, is a very different beast - we can go to 128-core chips and we all have GPUs with highly-parallel workloads on them. What do we use them for? Games. Or things like farmed off the antivirus and other stuff that we don't want to "get in our way" for performance. Do we actually do anything that takes significant advantage of 128-cores and their parallelism? No. we just run 128 single-threads at the clock-speed we already had. No one program sees the benefit of such parallelism, we just run more programs (that are each unsuited to parallelism) simultaneously, and are still bound by the clock-speed. And if you have 128-cores at a slower clock rate than a 64-core chip, people aren't going to queue up to buy the 128-core chip.

Even our most popular programming languages struggle to express any significant use of parallelism. Architectures simply aren't built for it. And hardware is designed for speed first.

It's not any one component... it's that nobody is prepared to sacrifice raw single-thread performance for anything else, even security in many cases. It's a market problem, a software problem, a hardware problem, a sales problem, a programming language expression problem, and ultimately nothing is set up to go that way and nothing that goes that way really takes off how you would expect, and hasn't in all the decades we've had it. Most cloud computing is just bog-standard PC architectures lumped into highly-available groups, with workloads distributed by third-party software, no real parallelism even though it forms a perfect use case for such. Instead we deploy individual VMs on specific hosts, and software load balancers, rather than farming the work out across dozens of connected PCs able to parallelise the work required across them all.

Because, when you get down to it, parallel computing is hard to achieve in hardware, much more difficult to program, understand and debug, slower than other methods, and requires far-greater interconnects, memory speeds, etc. to get close to matching the performance of just lobbing it at a dedicated processor, or even chopping it up logistically and lobbing it at ten processors via software.

Hmmm...all of this reminds me of a small probably (best) forgotten project at ICL in the 1990s called ...Goldrush Megaserver..?

The h/w side was massively parallel "first of a kind."

One reason it didn't go far was the need to re-write your code, coupled with an absence of deep, advanced tools to facilitate such a developements.

QUOTE:

"Because, when you get down to it, parallel computing is hard to achieve in hardware, much more difficult to program, understand and debug, slower than other methods, and requires far-greater interconnects, memory speeds, etc. to get close to matching the performance of just lobbing it at a dedicated processor, or even chopping it up logistically and lobbing it at ten processors via software."

For releasing an OS that requires some third-party compinent this complicated to work properly in the first place.

What? Ah. Sorry. This isn't about machines crashing due to CrowdStrike, is it? There were so many articles about that I just got into a rut.

Ahem. Obviously, the correct response here should have been:

"Ha ha, I run AMD, nyaah".

"The chip shop."

Well they certainly fried something !