Hacker News Reader

I would argue the author is not really saying "old" is "bad", but instead that we have been piling more and more craft onto the old so it has now become a significant engineering exercise to work around the idiosyncrasies of the old system every time you want to do something else.

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.

... while at the same time ensuring that the wheel can still function as the wheel of a horse cart, of a car and of a small plane, in the same exact way it functioned when it was designed, including past idiosyncrasies

Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right?

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.

> Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right?

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.

If you look at revenue, they are the exception that proves the rule though right? 90-95% of the revenue is in the other camp, depending on how you define it.

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?

> Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right?

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.

Also “smitten” is the passive past participle of “smite”, not “smote”, which is the active. This bothered me through the whole article.

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.

It might be there to put a playful twist on things. Kind of like "shook" (slang) or "woke" (when it first appeared).

And I woke from a terrible dream

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

Those are both correct (“conventional” to descriptivists like me) uses of the respective terms.

Ah, "not a native English speaker", usual written as "American".

</troll>

I propose that they are quite familiar with English and want to avoid the love-related connotations of "smitten".

I'm a native English speaker, and I see nothing wrong with "Honey, I Shrunk the Kids". It's a movie title, for Pete's sake.

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!

You’d tell Pete that you drank the beer, not that you’d drunk it. Shrink, shrank, shrunk is the same as drink, drank, drunk.

The film case likely altered your perception.

> we've had this particular wheel for 50 years and its doing fine but hey let's reimagine it anyway

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?

>Apple is doing laps over Intel because -- it seems -- of their choice to use ARM.

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.

> and optimize the entire Mac software stack for their processors.

And vice versa.

The Apple M1 and A14 SoCs were built on TSMC's 5nm process while AMD has been using TSMC 7nm for Zen. With the next generation of Zen on TSMC 5nm, we will see whether Apple's ARM or AMD's x86-64 implementations are more performant when starting with the same silicon.

> AMD processors are essentially equivalent to M1 in performance while still keeping x86

Perf/Watt?

That is only one of many important metrics. Technically speaking, a low power low frequency processor almost always beats out other processors in perf/watt, even if it is vastly inferior in processing capability.

Yeah, and die area isn't exactly going to be given away on a capacity constrained 5nm wafer line. If you can get the wafer starts at all. Performance per dollar is the only metric that matters, and maybe 7nm or even 14nm performs better at the moment.

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.

Where does this memetic lie come from?

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.

> Just because a technology is "old" doesn't mean it is useless, or needs to be replaced. I'm all in favor of fixing problems, and refactoring to improve flow and remove inefficiencies. I am not a fan of re-inventing the wheel because gee, we've had this particular wheel for 50 years and its doing fine but hey let's reimagine it anyway.

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

> slow half broken postgres

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

I think you misunderstood the comment. It wasn't calling Postgres slow and half broken, it was making a stab at other home-brewed (NIH, Not Invented Here https://en.wikipedia.org/wiki/Not_invented_here) databases, calling them slow, half baked copies of postgres, implying that they should have just used postgres, but that doing so wouldn't get them promotions.

>Just because a technology is "old" doesn't mean it is useless, or needs to be replaced.

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.

I thought the author's phrasing was brilliant. The x86 architecture was terrible on purely objective grounds in 1980 and it's still quite terrible today. It stinks and it has always stunk. Intel knows this as well as anybody; they've tried many times to replace this botched Yugo of an architecture but those efforts always die because of the omnipresent PC compatibility issue that you pointed out.

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

Funnily enough, everyone I know who works at Intel who's expressed a thought about Itanium would not agree with the statement that Itanium is superior to x86.

I have no idea if those Intel employees had direct experience with Itanium or they merely drank the "Itanium is bad" kool-aid. The hardware was pretty bad in the early years but Intel fixed those problems (speed, power, feature size, etc.)

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.

In fact, several of them did have direct experience with the Itanium. One of the comments one had about it was the hardware team had a bad habit of creating problems and hoping that the compiler would fix it.

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.

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

It is true that we currently cannot hide the microarchitectural effects of unsuccessful speculation, as exposed by transient execution attacks like Spectre and cousins.

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

The superficial VLIW-like encoding is abit of a red herring. The instruction bundles that resemble VLIW aren't really semantically too significant after instruction decoding. The grouping by stop bits is the Itanium specific feature that affects scheduling and depenendcies more.

I'm no CPU designer, but I seem to remember that Intel took the crown back from AMD with the Core 2 Duo. IIRC, that involved going back to an older design and going down a different path.

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.

It is impossible to schedule any reasonable program in advance because you don't know what the latencies of any memory loads are. (Also, you'd need a lot of register names in the ISA - modern OoO CPUs have hundreds of physical registers backing ~16 register names.)

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.

I agree with jcranmer and astrange!

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.

Itanium of course was a huge win for Intel. By convincing all the RISC Unix guys to jump on the sinking Itanium they captured the high end server market for x86.

I am doubting that if you walk over the aisle to the engineers in the other team, and state an obscure legacy issue to him/her. That person would, with decent chance, say something like "how could it be?" "was the original engineer dumb/imcompetent"? "was the original team got reorged"? etc....

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

Sssh! "Old = bad" means job security for millions of engineers. We need yet another security attack surface, I mean "improved interrupt handling."

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.

Part of it I think is that for many people, it's more fun to build something than to maintain something. It's also easier to write code than it is to read it (most of the time).

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