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

101–110 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#101

Post by zozbot234 »

titzer wrote: post #94
SuchAnonMuchWow wrote: post #83

Earlier quoted context omitted.

OOO is definitely observable when dealing with multithreading. That's why you have things like memory order constraints on atomic operations in C, and why you need to be extremely careful with how you place things like memory fences when doing anything fine-grained between several threads.

Fair point, but I'd qualify that OOO is only observable for racy programs. In languages with shared memory concurrency, but safety, races are either statically disallowed (Rust), or their results are constrained by a (weak) memory model. Java, e.g. only makes rough guarantees that you don't see out-of-thin air values and that you can't violate the type system. Java also is a little stricter around volatile memory acc…

Rust has atomic types that can observe races. Such "racy" code is useful because some concurrent code doesn't need the strictest guarantees (sequential consistency). Though, compared to C, Rust does not use the "Consume" memory ordering because so far it has turned out to be ill-defined.

Re: The x86 architecture is the weirdo, part 2

#102

Post by voldacar »

DSingularity wrote: post #31
voldacar wrote: post #20

Earlier quoted context omitted.

The mill guys post one or two updates per year on their forum site. Apparently covid messed up their timeline a lot, but they aren't bankrupt or anything.

What is up with those guys?

I think they just have a small team. Most recent work has been on their software stack (emulator, compiler etc), which I think is fairly close to release, but I could be wrong about that.

Re: The x86 architecture is the weirdo, part 2

#103

Post by titzer »

pornel wrote: post #95
titzer wrote: post #71

Earlier quoted context omitted.

> It also constrains some optimizations like reordering. Ha! As if C compilers really cared about correctness. This is why type-punning and aliasing memory through different typed pointers is fraught with peril, often UB. It's so C compilers can cheat and use type-based alias analysis, breaking programs that have "UB" but would work absolutely fine if the compiler wasn't so aggressive. In general, almost all argument…

This is roughly what happens, but you shouldn't attribute this to rudeness. Compiler users also demand performance. They compare implementations (and languages) and point out when such-and-such is X% slower. They file bugs about "missed" optimizations and "unnecessary" instructions. C is especially awkward here, because compilers are expected to precisely conform the C specification, but at the same time C users don'…

You make some good points. C was often used in the situation where "Hey, we just built this enormous supercomputer for LLNL, let's make this C program run as fast as possible on this one machine. Compiler team, please do everything possible to get the maximum performane out of this machine." I feel like a lot has followed from this repeating dozens of times over the past few decades. Performance has been the #1 priority, above all else, and it shows.

Re: The x86 architecture is the weirdo, part 2

#104

Post by titzer »

zozbot234 wrote: post #101
titzer wrote: post #94

Earlier quoted context omitted.

Fair point, but I'd qualify that OOO is only observable for racy programs. In languages with shared memory concurrency, but safety, races are either statically disallowed (Rust), or their results are constrained by a (weak) memory model. Java, e.g. only makes rough guarantees that you don't see out-of-thin air values and that you can't violate the type system. Java also is a little stricter around volatile memory acc…

Rust has atomic types that can observe races. Such "racy" code is useful because some concurrent code doesn't need the strictest guarantees (sequential consistency). Though, compared to C, Rust does not use the "Consume" memory ordering because so far it has turned out to be ill-defined.

AFAICT those can't observe OOO of CPUs, just nondeterminism from interleavings different threads. I.e. they will give you sequential consistency unless you have other, worse races.

Re: The x86 architecture is the weirdo, part 2

#105

Post by marcosdumay »

pjc50 wrote: post #15
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…

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?

The Mill weirdeness is weird in the sense that it's almost perfectly compatible with C-like code. It's not this that is impacting the project.

Instead, launching a new architecture is an herculean task. Trying that inside anything that isn't a huge company or consensus on the academic world has a history of nearly 100% failure since huge companies started building computers. (And even the consensus on the academic world is iffy.)

Re: The x86 architecture is the weirdo, part 2

#106

Post by paulmd »

my123 wrote: post #72
gumby wrote: post #64

Earlier quoted context omitted.

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…

> And we have CUDA which is an attempt to, yes, get back to the C model CUDA allows different programming models, it's the point of having the PTX virtual machine as the exposed programming model. CUDA C++ is popular, but is far from the only option people have. (and it can go very deep, https://www.ibm.com/docs/en/sdk-java-technology/8?topic=egpu... for example)

It's far less popular than the C/C++ bindings (at least at an end-user level), but NVIDIA actually has official support for FORTRAN on CUDA as well. iirc you can mix and match at the linker level, and there's a fair amount of library code that uses FORTRAN for performance reasons.

FORTRAN has tighter restrictions around what you can do in terms of aliasing/etc, which allows compilers to be more aggressive about optimizations without as much undefined-behavior "this looks correct and will run fine until we add another optimization and it doesn't" shenanigans. So in practice it can be faster than C, and it's actually quite popular among the HPC community and other performance-sensitive segments.

It's not like C has to be this way, with all the "undefined behavior" nonsense, it just is an artifact of a programming language written in the early 70s. C makes a lot of sense when a compiler looks a lot more like an assembler with a bit of optimization sprinkled in, and isn't performing super deep introspection and deciding that this entire function can be optimized away because of some arcane "undefined behavior" rule.

Re: The x86 architecture is the weirdo, part 2

#107

Post by zozbot234 »

titzer wrote: post #104
zozbot234 wrote: post #101

Earlier quoted context omitted.

Rust has atomic types that can observe races. Such "racy" code is useful because some concurrent code doesn't need the strictest guarantees (sequential consistency). Though, compared to C, Rust does not use the "Consume" memory ordering because so far it has turned out to be ill-defined.

AFAICT those can't observe OOO of CPUs, just nondeterminism from interleavings different threads. I.e. they will give you sequential consistency unless you have other, worse races.

Sequential consistency is absolutely optional, there are several other possible memory orderings that are far weaker. When programs involve multiple atomic locations concurrently, atomicity is only preserved at each separate location.

Re: The x86 architecture is the weirdo, part 2

#108

Post by omoikane »

Isn't it possible to annotate a variable as not being eligible for dead store elimination with something like "volatile"? I wonder why that particular state was causing trouble for Visual C++, assuming that it's able to handle code that deal with other kinds of asynchronous events (e.g. signal handlers).

Re: The x86 architecture is the weirdo, part 2

#109

Post by toast0 »

titzer wrote: post #94
SuchAnonMuchWow wrote: post #83

Earlier quoted context omitted.

OOO is definitely observable when dealing with multithreading. That's why you have things like memory order constraints on atomic operations in C, and why you need to be extremely careful with how you place things like memory fences when doing anything fine-grained between several threads.

Fair point, but I'd qualify that OOO is only observable for racy programs. In languages with shared memory concurrency, but safety, races are either statically disallowed (Rust), or their results are constrained by a (weak) memory model. Java, e.g. only makes rough guarantees that you don't see out-of-thin air values and that you can't violate the type system. Java also is a little stricter around volatile memory acc…

> Fair point, but I'd qualify that OOO is only observable for racy programs.

I mean, you're basically saying that it's only observable if you care to observe it.

Re: The x86 architecture is the weirdo, part 2

#110

Post by CalChris »

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…

+ SPARC tagged integers

+ MIPS branch delay slot

+ Everything about VLIW

+ Everything about Mill

+ iAPX 432 bit variable length instructions

Post reply on HN