6 ms·

Argh, why do author's write stuff like this -- "It is, not to put too fine a point on it, a creaking old bit of wheezing ironmongery that, had the gods of micro

Argh, why do author's write stuff like this -- "It is, not to put too fine a point on it, a creaking old bit of wheezing ironmongery that, had the gods of microprocessor architecture been more generous, would have been smote into oblivion long ago." 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. That said, the kink in x86 architecture was put their by "IBM PC Compatibility" and a Windows/Intel monopoly that went on way too long. But even knowing why the thing has these weird artifacts that just means the engineers are working under constraints you don't understand, doesn't give you license to dismiss what they've done as needing to be "wiped away." We are in a period where enthusiasts can design, build, and operate a completely bespoke ISA and micro-architecture with dense low cost FPGAs. Maybe they don't run at multi-GHz speeds but if you want to contribute positively to the question of computer architecture, there has never been a better time. You don't even have to build the whole thing! You can just add it into an existing architecture and compare how you do against it. Want to do flow control colored register allocation for speculative instruction retirement? You can build the entire execution unit in an FPGA and throw instructions at it to your hearts content and provide analysis of the results. Okay, enough ranting. I want AARCH64 to win so we can reset the problem set back to a smaller number of workarounds, but I think the creativity of people trying to advance the x86 architecture given the constraints is not something to belittled, it is to be admired.

lazide 5y ago
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.
- Tuna-Fish 5y ago
  > 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.
- Sebb767 5y ago
  > 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.
  - lazide 5y ago
    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?
gumby 5y ago
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.
- Scene_Cast2 5y ago
  It might be there to put a playful twist on things. Kind of like "shook" (slang) or "woke" (when it first appeared).
  - failwhaleshark 5y ago
    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-word-history-b1790787.html 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 https://youtu.be/Lo2qQmj0_h4 (Rock n' roll stole the best vernacular.)
    - gumby 5y ago
      Those are both correct (“conventional” to descriptivists like me) uses of the respective terms.
- thanatos519 5y ago
  Ah, "not a native English speaker", usual written as "American". </troll>
- Dylan16807 5y ago
  I propose that they are quite familiar with English and want to avoid the love-related connotations of "smitten".
- Stratoscope 5y ago
  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!
nwmcsween 5y ago
> 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
- edoceo 5y ago
  > slow half broken postgres Don't bring Postgres into this. Its fast and closer to zero-broken than to half-broken. ;)
  - dkersten 5y ago
    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 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.
failwhaleshark 5y ago
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.
- lazide 5y ago
  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!
herpderperator 5y ago
> 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?
- yyyk 5y ago
  >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.
  - leucineleprec0n 5y ago
    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-b5f6-91010f2234d2.jpg 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.
  - Someone 5y ago
    > and optimize the entire Mac software stack for their processors. And vice versa.
cycomanic 5y ago
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.
- sharikous 5y ago
  ... 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
justicezyx 5y ago
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...
coldtea 5y ago
>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.
dreamcompiler 5y ago
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."
- jcranmer 5y ago
  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.
  - dreamcompiler 5y ago
    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.
    - GregarianChild 5y ago
      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.

lazide 5y ago

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.

Tuna-Fish 5y ago
> 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.
Sebb767 5y ago
> 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.
- lazide 5y ago
  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?

gumby 5y ago

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.

Scene_Cast2 5y ago
It might be there to put a playful twist on things. Kind of like "shook" (slang) or "woke" (when it first appeared).
- failwhaleshark 5y ago
  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-word-history-b1790787.html 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 https://youtu.be/Lo2qQmj0_h4 (Rock n' roll stole the best vernacular.)
  - gumby 5y ago
    Those are both correct (“conventional” to descriptivists like me) uses of the respective terms.
thanatos519 5y ago
Ah, "not a native English speaker", usual written as "American". </troll>
Dylan16807 5y ago
I propose that they are quite familiar with English and want to avoid the love-related connotations of "smitten".
Stratoscope 5y ago
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!

nwmcsween 5y ago

> 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

edoceo 5y ago
> slow half broken postgres Don't bring Postgres into this. Its fast and closer to zero-broken than to half-broken. ;)
- dkersten 5y ago
  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 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.

failwhaleshark 5y ago

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.

lazide 5y ago
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!

herpderperator 5y ago

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

yyyk 5y ago
>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.
- leucineleprec0n 5y ago
  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-b5f6-91010f2234d2.jpg 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.
- Someone 5y ago
  > and optimize the entire Mac software stack for their processors. And vice versa.

cycomanic 5y ago

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.

sharikous 5y ago
... 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

justicezyx 5y ago

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

coldtea 5y ago

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

dreamcompiler 5y ago

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

jcranmer 5y ago
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.
- dreamcompiler 5y ago
  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.
  - GregarianChild 5y ago
    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.