Hacker News Reader

Comment by adrianratnapala | Hacker News Reader

> Is there a reason speculative execution had to be added to the processor and not compilers?

Wasn't this supposed to be the lesson of Itanium and VLIW?

I have read (without understanding for myself) that VLIW it had two problems: (a) no one can actually write an appropriate compiler, and (b) that's not surprising because the non-literalness of assembly is a useful hinge point allowing CPU designers to evolve their implementations while retaining a stable interface.

But this thread is talking about going even further and exposing new CPU features to programmers, and not just compilers. Does anyone have thoughts about what abstractions they would like to see?

View on HN

> But this thread is talking about going even further and exposing new CPU features to programmers, and not just compilers.

You could argue they already do, __builtin_prefetch and it's associated assembly instructions offer a way to manipulate the cache, but at the same time they seem to hedge their bets and pretend the cache isn't there. On the other end we've got programmers that know it's there and jump through hoops to try and keep things in contiguous memory, tricking the CPU into doing the correct thing.

That is truly an elephant in the room situation, everyone knows there is a magic black box there but do their best to ignore it because there is no other option.

> Wasn't this supposed to be the lesson of Itanium and VLIW?

It was the lesson, but that doesn't mean it was the correct one. In an alternate universe where there was no x86_64 we might have learned the opposite lesson.

I think I'm with you about caches.

I sometimes wish we wrote modern software for swarms of little 16-bit CPUs with 64kB of RAM and dealt with larger data structures by passing messages to other CPUs and to a DRAM-backed database.

And yes, a lot of software architecture is actually about emulating the above picture on a machine that pretends to have a flat address space, even though it actually only has 64kB of truly random-access memory.

the non-literalness of assembly is a useful hinge point allowing CPU designers to evolve their implementations while retaining a stable interface

Case in point, we have already seen a few times how unanticipated NUMA or thread scheduling weirdness can totally tank performance- and these are finer details!

Reply on news.ycombinator.com