Hacker News Reader

Comment by infogulch | Hacker News Reader

I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths.

I like the way the mill approaches these architectural problems.

View on HN

I'm very unconvinced by these arguments. Providing enough information to the processor to claw back all the performance that predictors give you, that requires some way of knowing all those things in advance. Statically.

And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").

Static analysis is just not a tractable way to replace hardware predictors. Even profile-guided information is a questionable answer. Could it be we're missing some key idea that'll take us far beyond all of this? Maybe, but it's probably not the same WLIV designs that require impossible feats of software comparable to asking for the weather 2 years in advance so you can save yourself the hardware cost of an umbrella.

Now, perhaps it would be unfair to criticize the Mill for not taping out an actual chip, after all having new ideas is valuable and fabs are very expensive. But we know this is a tricky subject. Performance optimization ideas only have value after you benchmark them, and they don't have an RTL implementation. Nothing that can run on an FPGA, not even "abstract" Verilog running in a testbench on a software simulator.

If what you want is a DSP that runs super simple hot loops very fast, then build a DSP and make it VLIW all you like. But that's not the workloads people run on a general purpose computer.

> And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers.

How will we ever know that a Sufficiently Smart Compiler is impossible, if we never have processors where compiler intelligence is useful?

> And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").

And how can one get their hands on an Itanium machine? It's a dead architecture in less than two weeks, and for the last decade the things have been almost exclusively enterprise machines; not something the hobbyist (or even the academic!) is likely to get access to.

Do you have an HP zx6000 lying around, perchance?

Itanium failed early; it had many more problems than compilers. And if we don't have a replacement, we'll never get those compilers from anyone but the most obsessed.

This has been tried (not on vaporhardware Mill, I'm more thinking about e.g. Intel Itanium) and it failed.

The reason is extremely simple: a speculative OOO processor optimizes dynamically. If you switch that with static compile time optimizations, you are bound to only be as fast as before in some quite limited parameter ranges (like: number of entries in a hash table, size of an image, etc.)

Also don't forget the really interesting Transmeta processors, also ultimately a failure. VLIW is very difficult in practice.

Transmeta were VLIW, yes, but weren't EPIC - which is the main difference involved. VLIW just means there's a long instruction word, usually targeting multiple units, but it doesn't necessarily mean there's no dynamic reshuffle in the CPU architecture or anything like that.

EPIC stood for Explicitly Parallel Instruction Computing, and took the "let's push it all to compiler" to the extreme. Itanium was never supposed to have any form of branch prediction or OOB, because it was supposed to be handled by the compiler.

This led to someone quipping that Itanium was a very fast DSP, but ridiculously expensive.

I agree with what you're saying around the Mill and dataflow in a sense, but feel like we disagree in the details. The issue with Spectre, etc. is that data of different trust levels are comingled in a single address space. We want the processor to speculate on some data, but not others and we don't tell it how to tell the difference. What's going to save us isn't dependency information or static scheduling, but more fine grained permissions around the data accessible at a single time.

IMO we need to bring back segmentation hardware. Not the x86 version of segmentation (there's not a feature that x86 wasn't able to make twice as complicated as it needed to be while only giving you half the use cases), but the cleaner object capability on top of paging hardware versions of segmentation. That solves the really rough Spectre cases like even NetSpectre where you can slurp out kernel state remotely from untrusted network packets. Just stick them in a "this memory is untrusted" segment. From there the CPU's dynamic dataflow optimizations can include speculation where memory is marked as trusted.

Is the Mill dead? I've not seen the regular flow of HN posts about it recently. Everyone got excited about RISC-V instead.

Not dead, just impacted by the pandemic.

https://millcomputing.com/topic/on-the-lack-of-progress-repo...

They're still going - Ivan said on their forum that they were planning on going full steam ahead last summer, but scuppered by lockdown. I don't totally buy that, but that's the story.

The interesting part about the Mill is that it's not even all that complex. It's just taking the existing VLIW architectural approach and adding a number of custom "tweaks" to improve the programming model over what VLIW provides.

This is sort of what GPUs do, since a GPU driver is essentially a big JIT compiler. Branching is very expensive compared to CPUs. Remember that 95%+ of branches of predicted successfully, and CPUs work on more stable ISAs.

Reply on news.ycombinator.com