Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The x86 architecture is the weirdo, part 2

devblogs.microsoft.com

Post reply on HN
Print view View original

61–70 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#61

Post by gumby »

twoodfin wrote: post #36
gumby wrote: post #34

MS was stuck with a poor exception implementation but what I never see explain is how they got there in the first place. It seems crazy to incur a runtime overhead to support something that is hardly ever used. The happy path is where you need the performance most, and exceptions are by definition the "unhappy path". Michael and I talked about exception design a lot in g++ (I certainly had experience of what to do an…

There’s a comment on Raymond’s post that explains it in a plausible-sounding way: https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=10... Table-based exception-handling metadata requires function prologue/epilogue sequences to have constrained forms that can be described by that metadata. When NT was first designed for x86-32, there was a lot of existing asm code that people wanted to easily port over to NT,…

Thanks. A legacy of lots of assembly code, though surprising that stuff like that survived in libraries (in applications it probably wouldn't have mattered)

Re: The x86 architecture is the weirdo, part 2

#62

Post by gumby »

someguydave wrote: post #57
gumby wrote: post #38

Earlier quoted context omitted.

> CPU architectures implicitly have something I call the "architectural weirdness budget" The point of designing a new architecture is you have a point to make (generally, "doing X will lead to faster execution"). So by definition you are adding unfamiliar architectural weirdness, else why get involved. The big problem is that the pervasiveness of the C model has fossilized design decisions of the PDP-11 that still h…

> C's memory aliasing model does this mean that because you can’t be sure if two vectors don’t overlap in C you therefore can’t auto-vectorize loops?

That's an example. It also constrains some optimizations like reordering.

Re: The x86 architecture is the weirdo, part 2

#63

Post by monocasa »

cesarb wrote: post #27
pjc50 wrote: post #15

Earlier quoted context omitted.

MIPS delay slots were another example of this. Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense, leading to the default PC 64-bit architecture being AMD's "x86 with longer registers" instead. What happened to the Mill "unlimited weirdness budget" CPU guys anyway?

> Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense Being VLIW was probably the least weird part of Itanium. The NaT ("not a thing") bit on every register was the weirdest part and probably the one which tripped people the most. And like SPARC, it had register windows. It also had a pair of stacks instead of a single one, a set of predicate registers (which also had their own reg…

The advanced loads (sort of software controlled speculative loads) were real goofy too (but neat!)

Re: The x86 architecture is the weirdo, part 2

#64

Post by gumby »

notacoward wrote: post #50
gumby wrote: post #38

Earlier quoted context omitted.

> CPU architectures implicitly have something I call the "architectural weirdness budget" The point of designing a new architecture is you have a point to make (generally, "doing X will lead to faster execution"). So by definition you are adding unfamiliar architectural weirdness, else why get involved. The big problem is that the pervasiveness of the C model has fossilized design decisions of the PDP-11 that still h…

So which language has handled ILP, OOO, delay slots, cache hints, etc. particularly well? Anything that's ergonomic and actually used (i.e. not awkward and academic)?

But that's my point: the dominance of a C monoculture has relegated alternatives to being "awkward and academic".

When you're in a C straightjacket it's hard to take advantages of other architectures like transputer, connection machine, or cell. Ever run bsd unix on a Cray? It was dog slow because the CPU assumed very deep pipelining and always had to continually resynchronize because of the frequent branches in the C code.

GPGPU is the sole recent exception, and even then it's still at the margins. And we have CUDA which is an attempt to, yes, get back to the C model.

These modern CPUs benchmark pretty well, but in practice little code can really take advantage. For example the M1 is a multicore screamer, yet most apps are still restricted to a single one.

Re: The x86 architecture is the weirdo, part 2

#65

Post by gumby »

gpderetta wrote: post #52
gumby wrote: post #34

MS was stuck with a poor exception implementation but what I never see explain is how they got there in the first place. It seems crazy to incur a runtime overhead to support something that is hardly ever used. The happy path is where you need the performance most, and exceptions are by definition the "unhappy path". Michael and I talked about exception design a lot in g++ (I certainly had experience of what to do an…

Re the zero cost claim, he specifically clarifies that zero cost exceptions have a cost even if you do not use them, which is paid by inhibiting some optimizations. IANACW, but I think that in principle is almost always possible to implement truly zero cost exception path in the non-taken path, by moving all necessary compensation code to undo optimizations into the exceptional path, but in practice it might be too h…

If you spend a lot of time scrutinizing g++ output (which thankfully I haven't had to do in over 20 years) you'll see that the impact is negligible and that was true when Raymond made that statement. As you point out there's a lot the compiler can do to make the common path really fast.

But OK, it could potentially be nonzero. Let's say epsilon cost instead.

Re: The x86 architecture is the weirdo, part 2

#66

Post by mschaef »

AlexandrB wrote: post #35

I'm bummed that The Old New Thing is now on Microsoft's domain. Old blogs seems to be dying out or being moved behind the walls of Medium/Substack/etc.

It's always been on one Microsoft domain or another, for almost as long as there've been blogs at all. It's almost 20 years ago now, but when Blogs started their initial ascendency as a useful format, Microsoft had a a number of developers start writing publicly facing personal blogs. Raymond Chen was one of that group, also including Michael Kaplan, Eric Lippert and Larry Osterman, among others.

As far as I know, The Old New Thing is the only blog from that wave that's still being written - and it's been written every weekday for essentially that entire time. To give an idea of the scope of the work, he did a compilation of posts in book form sixteen years ago, and it was over 500 pages long.

https://www.amazon.com/gp/product/B004YWCL5W/ref=dbs_a_def_r...

I don't read it daily anymore (hasn't been relevant to my work or professional interests for ten years or more), but I do read it occasionally and continue to be both impressed and grateful for the effort he's put into the blog.

Re: The x86 architecture is the weirdo, part 2

#67

Post by Someone »

gpderetta wrote: post #8
foota wrote: post #4

Earlier quoted context omitted.

I believe this is because the intermediate state can't be safely observed by another thread, since there's no locking, so the C++ memory model allows removing them.

In the article example itself, f1() and f2() can observe the state. Nothing to do with threads.

I don’t think so. It is global state, but it lives outside the abstract C machine, in its implementation.

The compiler knows f1 and f2 live in the abstract C machine and cannot access it.

I think its like the difference between errno, a global inside the abstract C machine, and __foo, which a compiler might create, and, if it did so, could assume to be completely under its control.

Re: The x86 architecture is the weirdo, part 2

#68

Post by titzer »

This is one of the many reasons that having exceptional control flow explicit in the compiler IR is a Good Thing(tm). The HotSpot client compiler lacked this information (in the beginning) because it was deemed "too expensive to keep" and the result was that many optimizations had ugly special cases (or were disabled altogether). For the most part, if the compiler has some notion of hot/cold code, then these exceptional edges can just be marked as cold and the same heuristics that apply to, e.g. unlikely branches, will do a good job.

Re: The x86 architecture is the weirdo, part 2

#69

Post by titzer »

pm215 wrote: post #3

I have a theory that CPU architectures implicitly have something I call the "architectural weirdness budget", which is the extent to which you can get away with design decisions in the architecture or ABI that differ from the existing established consensus. Any time you do something a bit odd that means that existing software has to do awkward things or might not be no-changes portable to your new architecture, you'r…

+ MSP430 holes in the addressing mode encoding space

I don't know of any new architecture that is choosing big-endian. Almost all of the ones that I can think of that are/were big-endian have added a little-endian mode.

Thank god for that! In Wasm we just decreed little-endian, and I think this was one of our better calls.

Re: The x86 architecture is the weirdo, part 2

#70

Post by ajross »

titzer wrote: post #68

This is one of the many reasons that having exceptional control flow explicit in the compiler IR is a Good Thing(tm). The HotSpot client compiler lacked this information (in the beginning) because it was deemed "too expensive to keep" and the result was that many optimizations had ugly special cases (or were disabled altogether). For the most part, if the compiler has some notion of hot/cold code, then these exceptio…

Pretty much exactly. They had a situation with external visibility into information in the stack frame and don't seem to have made an effort to tell the compiler. I mean... it's their compiler! It's their ABI, even! They have all the levers and dials, and somehow the fact that their exception counter is being optimized out means that the "architecture" is the weirdo?

Yeah. At its root this is a Conway's Law bug. The people responsible for "exceptions" had a senseless wall between them and the people responsible for "stack frames".

Post reply on HN