C was never intended to be a model of what the CPU is actually doing.

This is purely an optimization issue and the article compares apples to oranges for clicks.

I want to be optimistic and agree that ‘we’ll have a better way to harness the computing power available to us’, but at this point it’s been years or maybe decades of propping up the x86 ISA while actual operation of the computing device drifts further away. I certainly understand the desires of processor manufacturers to want to be able to maintain an ISA and then be able to implement a machine that can change underneath it to realize performance gains. However, this has left the status quo utterly entrenched and I can not see what would make them change this behavior.

I really would get onboard with an alternative ISA that was more in line with actual architectural features of modern processors and I often wonder why we could not have an extra compilation (jit or aot) step from x86 to some other format. But the trend seems to be going the opposite direction for all the large scale processor manufacturer/designers toward a more abstracted interface at the lowest level.

I’ve seen various comments that basically boil down to “you can’t change the ISA because then C/C++/Rust programs would loose performance in benchmarks in the short term”, and this resistance only reinforces maintaining current trends. So… what are you assuming happens that prompts the shift toward a better way to harness computing power?

What architectural features would you like to surface that are currently papered over in x86?

My particular interests would see me appreciating access to cache structure, cache behavior, prefetching, cache coherency, memory management unit control, instruction pipelining, and maybe register renaming control.

I am not particularly qualified to try and design a better ISA, I just know there are some things I would like the option to control at some times (or at least I imagine I would). A lot of the list above is about exposing more of the architecture to user control as a general principle. However, I’d rather see some areas of hardware design change to facilitate something other than coding paradigms and practices that stretch back nearly 40 years. Chisnall’s ‘C is not a Low Level Language’ article discusses several architectural directions I would like to see happen, but also talks about how as long as the ISA remains the same moving to new programming styles/philosophies continues to be a difficult proposition.

I see. These things sound swell, though for stuff like controlling register renaming it sounds hard for the instruction decode overhead to be worth it. Currently you can use prefetch intrinsics for prefetching and the level of cache management available is mostly non-temporal stores and explicit allocation of L3 space to specific cores (which ends up meaning specific processes if you are careful).

The world has mostly not adopted existing tools for writing 10-100x faster software (simd, huge pages, computing both branches then using a blend or cmov when this is sufficiently cheap, software prefetching, collection APIs that support bulk updates so that they can use all of these things instead of adding totally unnecessary dependency chains to the resulting program, etc.) so i'm not optimistic about things getting better if CPUs grow a thousand times more memory bandwidth and cores and begin to support very wide scatter/gather like GPUs.

ARM seems like it's destined to only grow in importance.

I don’t know for certain, or in any great specificity, but in this context (i.e. ISA representing a more accurate or concrete mapping to hardware functionality/capabilities) I don’t know that ARM is particularly different to x86. The both present a relatively single core, flat memory architecture to programmers; while the actual processor is absolutely not that.

The memory model is a bit different on arm64, but it is not Alpha.

Other than that they are very similar

You may be right about that, though I had the impression that less wasteful parallelism was possible because of fixed-size instructions.

immintrin.h seems tough to beat.

C is a pretty good model in part because all ISAs were designed with C in mind.