Forum Federato

@regehr @steve To wit: virtual memory is a lie, by design. Uniform memory is a lie. Shared instruction/data memory is a lie. Coherent caches are a lie, caches would rather be _anything_ else. Buses are a lie. Memory-mapped IO is IO lying about being memory. Oh and the data bits and wires are small and shitty enough now that they started lying too and everything is slowly creeping towards ECCing all the things

@regehr @steve Basically almost everything that _all_ major ISAs pretend is true about memory at the ISA level is an expensive lie, but one that ~ALL the SW depends on.

@regehr @steve For example, it's a goddamn NIGHTMARE doing a high-performance memory subsystem for absolutely anything.

This whole "shared memory" fiction we're committed to maintaining is a significant drag on all HW, but HW impls of it are just in another league perf-wise than "just" building message-passing and trying to work around it in SW (lots have tried, but there's little code for it and it's a PITA), so we're kind of stuck with it.

@regehr @steve Anecdotally, there's at least 3 (Intel, AMD, Centaur) companies that do this on the regular, and one of them (Centaur) is quite small as such things go.

I wouldn't want to do it either, but the other thing you gotta keep in mind is that the CPU core, while important, is only part of a SoC and ISA has very little impact on the "everything else".

@steve @regehr Anyway, take that with whatever amount of salt you want, but Intel and AMD both are strongly incentivized to seriously look at this.

They for sure would prefer to sell you x86s because they have decades of experience with that, but they're looking at what it costs them to do it both in capex and in how much it hurts the resulting designs.

And for the latter, the consistent answer has been "a bit, but not much".

@regehr Eventually, there's nowhere left to hide. For applications where you'd use say an ARM Cortex-M0 or a bare-bones minimal RV32I CPU, I'm not aware of anything x86 past or present that would really make sense.

Intel did "Quark" a while back which I believe was either a 486 or P5 derivative, so still something like a 5-stage pipelined integer core. If you want to go even lower than that, I don't think anyone has (or wants to do) anything.

@regehr Some more details:
- the D/V and toolchain costs are amortized. Broadly speaking, the bigger your ecosystem/market share, the bigger your ability to absorb that cost.
- This holds for what ARM would call "application" cores; oversimplifying a bit, it's essentially a constant overhead on the design that adds some extra area and pipe stages. It's more onerous for smaller cores, but you need to be really small.

@regehr Every serious study (both from independent researchers and from vendors themselves) that I've ever seen (and I'm up to 5 or so at this point), broadly, supports this, with some caveats.

It's not "no difference", but for server/application cores, what differences there are typically somewhere in the single-digit %. You can always find pathological examples, but typically it's not that much.

There is a real cost to x86s many warts but it's mostly in design/validation cost and toolchains.

@aeva As a counterpoint to the endless monomyth variations, I like Le Guin's "Carirer Bag Theory of Fiction" https://theanarchistlibrary.org/mirror/u/uk/ursula-k-le-guin-the-carrier-bag-theory-of-fiction.pdf

anyway,

15. gather things to help you gather more things

16. keep the ball going

17. just move, but that's hard

18. move things around to make path which breaks other path

19. pretend real life

20. na nananananana nana katamari damacy

@aeva it's not personal, kiddo, but if the cops catch me serving a NaN to a minor I could lose my optimization license, and I need that to be full to aggressively exploit UB in ways you certainly intended

@aeva you can get a full regular expression library free of charge, but square roots are extra, and if you want transcendentals, well, I have it on good authority that several of them are outright sinful, so I'll need to see some ID if you don't mind

@aeva sure these funcs too are in the standard library, but they're in the icky part of the standard library that actually deals with numbers and stuff. We don't like and don't trust numbers when they're not integers

@aeva I find it so funny that on Unices, C++ compiles will link libc and libstdc++/libcxx and happily depend on hundreds of kilobytes of very dubious C/C++ locale junk etc., but draw the line at including several kilobytes worth of transcendental math functions