To use your wheel analogy. It's sort of like starting with the wheel of horse cart and adding bits and pieces to that same wheel to make it somehow work as the landing gear wheel for a jumbo jet. At some point it might be a good idea to simply design a new wheel.

On the engineering side, similar more often than not. You get promoted by solving the ‘big problem’. The really enterprising (and ones you need to watch) often figure out how to make the big problem the one they are trying/well situated to solve - even if it isn’t really a problem.

But in this specific case, everything is absolutely not actually fine? x86 interrupt handling is terrible. It's slow, it's extremely fragile, and everything about it is just byzantine and overcomplicated.

Well, that's actually not true. There are quite a few live coaches and the likes making their living on positive writing. And there a quite a few writers, like Scott Alexander, which, while not being all positive, definitely don't need to or want to paint an overly dark or dramatic picture.

In the more conventional news sector, on the other hand, this is probably true.

For every life coach able to make a living, I’m guessing there are 10-20 business consultants, therapists, psychologists, etc. called in to fix a problem no?

I suppose the author is not a native English speaker. Like the person who titled a film “honey I shrunk the kids”. Makes me wince to even type it.

I assume you are saying it should have been "Honey, I Shrank the Kids". Please correct me if I misunderstood you.

Yes, I know the technically correct usage of "shrank" and "shrunk". But let's take off our grammarian hats for a moment and say each one out loud a few times.

"Honey, I Shrunk the Kids" rolls off the tongue, while "Honey, I Shrank the Kids" just seems... odd to me. You may disagree.

If you actually shrank your kids, and you were in a panic and rushed to tell your honey about it, would you be concerned about correct grammar, or just getting the message across?

One might even argue that the incorrect use of "shrunk" helps convey this sense of panic.

Movie titles are not required to follow "correct" English grammar, any more than newspaper headlines. They should be memorable and fun to say when you tell your friends about a movie you enjoyed.

p.s. I've never been sure who Pete is, but I hear he has a very fine bottle of sake. If we ask him real nice, maybe he will let us try a sip!

The film case likely altered your perception.

So I caught up my pal Jack Daniel's

And his partner Jimmy Beam

https://www.independent.co.uk/news/uk/home-news/woke-meaning...

AC/DC - You Shook Me All Night Long (Official Video)

https://youtu.be/Lo2qQmj0_h4

(Rock n' roll stole the best vernacular.)

</troll>

How is it doing fine? Apple is doing laps over Intel because -- it seems -- of their choice to use ARM. Would they have been able to design an x86/amd64 CPU just as good?

AMD processors are essentially equivalent to M1 in performance while still keeping x86, so probably yes (there are an ARM advantage in instruction decoding, but judging by performance differences, it's probably small).

Apple's advantage is mostly that Apple (via TSMC) can use a smaller processor node than Intel and optimize the entire Mac software stack for their processors.

AMD's listed "15W TDP" is irrelevant to the observed wattage and frequency (or performance) curves.

And we've seen Apple's A12, A13 on a similar TSMC 7NM node - older if I may add so AMD garners what little improvements are made on that process since then.

Here's a fairly telling chart on the performance: watt curves. https://hexus.net/media/uploaded/2020/8/f5957fa8-630f-44be-b...

BTW: it doesn't improve too much on Zen 3. Slope is just not ARM, much less Apple-tier.

Inevitably someone will chime in and point out AMD's power efficiency is subpar due to boosting far beyond optimal points on the curve; while true this is inefficient we can truncate their frequency to Apple's 3.2GHZ or merely observe the slope of the p:w curves above - at almost any point on the y axis, an A12 or A13 will be taking AMD to the woodshed on performance per watt. And I'm not exactly amicable to handicapping the comparisons by giving AMD & X86 a half decade to work out the architecture before things are "fair". As it stands, Apple's architecture is simply more performant.

Perf/Watt?

DRAM, storage, networking, gpus, accelerators, etc are all eating huge chunks of power. CPU's tiny in comparison. Maybe you save 5% across a datacenter using those fancy unicorn wafers.

And vice versa.

Can't get promotions if you don't NIH a slow half broken postgres

Don't bring Postgres into this. Its fast and closer to zero-broken than to half-broken. ;)

Sure. But if on top of old it is "a creaking wheezing ironmonger" that "had the gods of microprocessor architecture been more generous, would have been smote into oblivion long ago", then it does need to be replaced.

And both the article mentions reasons why (they don't stop at mere old) and Intel/AMD share them.

Yeah, turning a Yugo into a moon rocket is impressive. But I'd have been a lot more impressed if Intel had said "No more x86 for you. It's gonna be Itanium now. It's better in every way. Deal with it."

At the end the problem was timing: We didn't know how to write compilers that could figure out micro-scheduling in advance so software couldn't take advantage of the Itanium, and when AMD64 came out and added a bunch of registers and did all that nasty instruction reordering and speculative execution in realtime on-chip everybody said "just use that." Nowadays compiler writers have a much keener understanding of static analysis and almost certainly could take advantage of the chip. And vulnerabilities like Spectre and Meltdown would never have happened because all that optimization would have been done in the compiler where it belongs.

One of the things about Itanium that I do know is that it's basically VLIW. And VLIW is a technology that sounds really good on paper, but it turns out that you just can't get that good results for realistic workloads--they've basically been abandoned everywhere they've been tried except for DSPs, where they live on apparently because DSPs have so few kernels they care about.

And speaking as a compiler writer, no compiler will ever do a good a job as the hardware can at maximizing instruction-level parallelism. The compiler is forced to make a static choice while hardware can choose based on dynamic effects that the compiler will never be able to predict.

At the limit of complete generality the Halting Problem guarantees your statement is correct. But it also appears to be extremely difficult to do this at runtime without side-effects that change global state such that information leaks. The real cost for speculative execution may be that it can't be done in a purely-functional manner.

So what?

Most workloads / customers are much more about performance than security. We can trivially remove such attacks by switching off all speculation (branch prediction, caches, OOO, prefetching). Indeed you can buy CPUs like that, and they are used in environments where safety is of extreme importance. The cost of this is an orders-of-magnitude loss of performance Most workloads (e.g. Netflix streaming, Snapchat filters, online advertising, protein folding, computer games, Instagram, chat apps) are simply not security sensitive enough to care.

Building a competitive general purposes CPU costs a lot (probably > $1Billion end-to-end), and who would buy a CPU that is safe against Spectre but 3 orders of magnitude slower than the competition? (Not to mention that there are many more dangerous vulnerabulities, from Rowhammer to Intel' Management Engine, to rubber hose ...)

It is not possible, in June 2021, to build a compiler that can schedule general workloads as well as an out-of-order scheduler can at run-time in a modern CPU. Note that the scheduling we are talking about is mostly to do with data location in order to hide the latencies of data-movement: In order to hide data movement latencies, you need to know if needed data is in L1, L2, L3, or main memory. In general workloads this is very much data dependent. How is a static, or even JIT, compiler supposed to know with enough precision where data is located at run-time? An additional problem is that compiler scheduling needs bits for encoding scheduling information, which does not come for free: those bits cannot be used for other purposes (e.g. larger immediate arguments). For more specific workloads where data movement is more predictable, i.e. not itself data-dependent, the situation is different, whence the rise of GPUs, TPUs, signal processing cores etc.

Spectre and Meltdown are orthogonal. They come from speculation, e.g. branch prediction. Compile-time branch prediction is similarly infeasible for general workloads.

Besides that, if you think x86 is bad you should try using some supposedly clean architectures like MIPS or Alpha. They may be RISC but they are definitely too RISC.

If Itanium was just ahead of its time, Intel could always try again. ARM and RISC-V are getting a lot of attention these days. Mill seems to be missing the window of opportunity. 2-nm fab seems like a fantasy. Announcing the new Gadolinium processor family wouldn't be a complete cringe.

Or... maybe it really isn't the way forward.

Not saying the tech journalist is better in any sense. But let's be honest, there is no reason they should be doing better...

I don't understand why people, engineers of all people, fall for the Dunning-Kruger/NIH/ageism-in-all-teh-things consumerism fallacy that everything else that came before is dumb, unusable, or can always be done better.

Code magically rusts after being exposed to air for 9 months, donja know? If it's not trivially-edited every 2 months, it's a "dead" project.

So why not do the fun and easy thing? Especially if they aren't the one writing the checks!