Hacker News Reader

In one of the talks Godard said the Itanium concept wasn't brought to conclusion mostly because the chief architect died. Don't remember the name. Of course that should be taken with a grain of salt.

One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls (for which there is a dedicated instruction). That would be HUGE for microkernel architectures.

> One of the most interesting things to me is the security model with the promise (unproven, maybe very over-optimistic) of the equaivalent of context switches costing no more than regular function calls...

In theory, we should be able to do something like that now on ordinary CPUs if we write our user-mode software in a memory-safe language such as Rust.

Current CPUs go to great lengths to isolate process address spaces so that one bad behaving application can't crash the computer. However, if the compiler also guarantees that the application can't access memory it doesn't own (because the language provides no mechanism by which to do that), then the hardware memory isolation is redundant.

The OS could maintain metadata about each binary and what it was compiled with. If it wasn't compiled with a trusted compiler, then it runs inside an isolated process and pays the cost of context switches or it runs inside a CPU emulator at something like 1% performance.

This assumes there are no unsafe code blocks in "trusted" user-space code; in practice, this would mean that everything that can be made more efficient by doing it in an unsafe way moves into a standard library that's trusted. So, an unsafe code block would be like an suid-root binary or a kernel module.

Having user space process and the kernel run in the same address space means that system calls are just function calls (which could be inlined by the compiler) and we could support things like Infiniband network interfaces (that map their hardware registers directly into user-space memory to avoid system call overhead) through an OS API, just like a regular network adapter instead of them being a weird special case.

I don't see compiler writers being thrilled by having to harden the entire compiler toolchain against actively malicious input. And there would be no way to verify the binary by itself, you'd have to have every binary built on and signed by a trusted build server. Oh, and now any binary built with a compiler that has bugs can now compromise the entire OS.

No, if you want to keep security you need some kind of external memory protection system. Memory isolation gives that and takes away performance. Mill gives both.

You're right, compiler writers wouldn't want to be responsible for system security in the same way that OS kernel authors are now, and commercial closed-source software doesn't fit well with the scheme I describe.

If Mill can drop the cost of context switches down to the point where they're indistinguishable from function calls, then that's pretty awesome and it would presumably work well with the software we have now, which is a strong point in its favor. (I haven't seen any Mill talks about security/memory protection, so I don't know what the implementation details are.)

I'm just trying to make the point that reducing the cost of context switches isn't the only solution, and that we could eliminate context switches altogether by making different tradeoffs. I think both approaches are promising and will appeal to different audiences.

> And there would be no way to verify the binary by itself.

Doesn't Java do exactly that?

No, the JVM provides security in this scenario by being the trusted compiler and inserting memory safety checks itself.

this is not a new idea - Burroughs old CPUs B6700/etc did this - system integrity depended on the tool chain always making safe code - I remember linker (aka binder) bugs bringing down weekly poayroll on our multitasking system.

It also meant that compiler development essentially required your own multi-million dollar mainframe - there weren't a lot of languages available.

You couldn't safely import code from another machine since anyone could write any bitstream to a tape.

The 6700 was a great old machine .... but this bit sucked.

Isn't this basically the idea of Google's NaCl (native client)?

https://en.wikipedia.org/wiki/Google_Native_Client

From the wikipedia description, I think NaCl is doing something a little different. It looks like they rely on the MMU to prevent a misbehaving application from reading/writing outside its address space. That makes sense, since it's being used to run C and C++ programs that presumably would be difficult or impossible to statically verify that they're using pointers in a way that's definitely safe.

Itanium's major sticking point was relying on compiler technology that never materialized. The Mill architecture seems to respect the current level of compiler tech a lot more.

Not sure what you mean here.

Itanium was a VLIW and the Yale Bulldog compiler solved the VLIW code generation problem with trace scheduling back in the 80s. At this point, that's standard Dragon Book stuff.

Itanium failed to be sure but it wasn't the compiler. However I'll grant that the workload didn't match the EPIC architecture and the compiler. EPIC succeeded at scientific workloads.

As to whether Mill respects the current level of compiler tech a lot more I'd like to know more about that. They need to get their LLVM backend up and running.

Agreed: 'compiler technology' was a marketing promise/excuse over the fact that for any real-world problem, even the best possible code could not come near to the theoretical hardware performance. Intel had previously made the same mistake with the i860 but didn't learn from it.

So the hardware didn't match the workload and they blamed the compiler? That sounds plausible. I think they oversold the use cases for the Itanium though, they made it sound more like a general-purpose server CPU. The Mill might not be general-purpose either but they seem to be more honest about its niche (it's basically a DSP that happens to support general computation). Maybe that will be enough for it not to be a disappointment.

I don't see how the Mill has any less reliance on modified compilers than Itanium. Instead, it seems to require more.

The Mill's history may be different because compilers actually advanced a lot since Itanium's launch, because it brings some arguably improvement over Itanium, or because the Mill's team is trying to write those compiler improvements, instead of making a partnership with Microsoft.

> I don't see how the Mill has any less reliance on modified compilers than Itanium. Instead, it seems to require more.

I don't know, some of the novelties in the Mill arch would seem to simplify compilers. For instance, no need for complex register allocation.

Other optimizations applicable to traditional CPUs either may not apply to the Mill CPU, or may need significant tweaking to work properly.

I got the opinion it would be much more complex, like deciding if saving a value is faster than reordering, and deciding the best place to request a load. It is also a large instruction word architecture, what means it's mostly similar from the compiler point of view.

The one thing that I think makes the Mill simpler is the no-value values mixed with lazy error conditions. I have no idea if those are powerful enough to compensate the rest.

Those issues are pretty easy.

For spilling: if a desired argument is less than one belt-length away then we directly reference it; between one and two away we reorder; and more than two we spill.

We place a load as soon as the address arguments are statically available. The compiler doesn't have to deal with aliasing, which is a large and bug-ridden part of compiling for other targets.

Lazy-error (aka NaR) means that there are no error dependencies in arithmetic expressions. Current compilers for other targets simply ignore such dependencies, relying on the "undefined behavior" rule. Mill is designed to not produce nasal demons :-)

Hm. I'd say Mill requires an even more ambitious compiler than Itanium. Itanium's large number of registers, for example, was friendly for existing compilers, while I don't know how compilers will handle the whole belt thing.

Incidentally, I don't think the Itanium compiler tech never materialized, it just materialized late. Itanium had a lot of other problems, but the later Itanium models really flew for certain workloads (SQL Server, in particular). After the first one (which was quite a dud and killed Itanium's reputation), Itanium was definitely not slow. The x86 emulator was slow, and AMD64 absolutely stole Itanium's lunch.

I bet if AMD didn't had come with their 64bit extensions, this laptop would be running on an Itanium processor.

> simple ISA designs, such as ARM or RISC-V, preferably in a many-core design

There are several of these already (e.g. Tilera) which haven't really taken off outside of those marketed as "graphics cards". The main problem is that memory bandwidth is now the real bottleneck for real workloads.

That reminds me, any news from Rex Neo[1] ? There is no activity on its mailing list.

[1] http://rexcomputing.com/#neoarch Basically simpler and more Ghz/Watt than Parallela.

We're still alive, received our first silicon back in October, and will have news coming out soon.

The problem with the Mill is its not clear to me what advantage it can hope to seize over the behemoth which is Intel. If the market opens up enough to justify new architectures, then it's also opening up enough to let Intel pivot into that space and unlike everyone else they own the fabs to do it.

You would have thought the same about the SoC space, but they let it slip away. Intel does have the ability the squash competition, but it's not strategically perfect.

That's why the Mill team has been stockpiling patents for a while.

This is drastically over-simplified, but in short, the Mill is a sort of middle-ground between superscalar implementations (x86, ARM) and VLIW (Itanium, DSPs).

Superscalars leave a lot of the optimization process to complexity in the hardware. This is seen in stuff like the out-of-order scheduling and large cache hierarchies. In one of the Mill talks, it's guesstimated that almost 90% of the circuitry is dedicated to simply moving data around, as opposed to actually doing any work on that data.

VLIWs take the opposite extreme, leaving the complexity of optimization to the compiler. History has shown so far though, that many computing problems are (again oversimplified) too conditionals-heavy to really benefit from VLIW, and end up running much more slowly.

So the Mill is a bet that they can get more benefits from each approach without the major draw-backs of each. This isn't really ground Intel could simply "move into" without half a decade plus of work, and even then, they'd be cannibalizing their x86 ecosystem, which is not a risk most entrenched corporations are fond of.

My thought process of this has been that Superscalar is like a JIT, in that it attempts to optimise these instruction scheduling as it happens, always executing when viable. Bit obviously although this is good for optimising execution does come at a fairly high implementation complexity cost.

Whereas VLIW is where you optimise ahead of time with no fore knowledge, if the compiler is good enough, you get the same performance with simpler, cheaper, more efficient hardware (or potentially more performance) but often this doesn't pan out fully.

But that's the point: if I want to buy non-Intel at my company, I've got contracts, lawyers fees, upper-level management etc. to convince to do it. Intel is probably sending me support personnel and sample hardware.

And I'm still looking at recompiling, debugging and deploying a ton of software to see advantages from the Mill.

So whatever advantages it brings, they need to be very substantial (i.e. if the next-gen of Intel x86 chips still out-perform it, I'll buy them) and quite quick - because I can go 5 years not buying the Mill while Intel promises to support me for their awesome new architecture. I mean, probably we buy some Mill machines, but how likely is it that it's game changing on my codebase?

That's where I see the problem. There's this whole huge assumption that the Mill will yield a bunch of benefits. If they're clear cut (a huge if) then they still have to beat their competitors being able to brute-force performance improvements until they come up with a new architecture themselves, which can take advantage of the very compensation they're asking from their customers ("switch architectures, it'll be great we promise").

Very good points. I agree that many established companies are going to be very wary of making the jump. My hunch is that if they have a real shot, and this is assuming that most of their promises turn out, it's not going to be going after general purpose computing head-on.

For instance are there big problems out there that are compute intensive, but branch-heavy enough that GPUs aren't a great fit, in applications that need low power but that don't make sense as "cloud services"? I don't know.

The optimist in me sees potential opportunity in opening up new domains. The practicalist agrees with you; it's going to be an uphill battle and a lot of stars need to align just right. But if they really can deliver 10x on general purpose computing workloads, it's hard for me to see that not being game changing.

There are a few places I could see Mill making inroads.

The security features could be very useful for the big internet companies, Amazon, Google, Facebook, etc and they can afford to spend a few tens of millions of dollars on something speculative like this. And they do, with things like Arm or OpenPower servers.

There's also the high end embedded land where you don't need to run a traditional operating system. Network switches, cell towers, that sort of thing.

More accurate to say, I think, that the Mill is a VLIW with certain hardware facilities to overcome the traditional weaknesses of those - code density and variable memory latency. The solution to conditional branches is exactly the same for VLIW as for Superscalar machines: use a branch predictor. And VLIWs can tolerate a slightly worse branch predictor since they tend to have shorter pipelines.

EDIT: To explain a bit more, VLIW has historically worked great in cases like DSP workloads where the memory access patterns are very predictable and you aren't unexpectedly loading things from lower level caches very often. There's anther thread on HR right now about doing deep learning with a Hexagon, which is a sort of VLIW, and it works very well. But as soon as you miss L1 in a VLIW the whole thing comes to a stop, whereas in an OoO (Out of Order) processor you can keep executing subsequent instructions that don't depend on that load and so you don't have to stall. Basically every instruction that isn't a load has deterministic or at least hard bounded latency that the compiler can easily plan for.

The other big disadvantage of VLIW is that sometimes you have stretches of code where you can only have one useful instruction at a time. VLIWs often use very RISCy encoding formats that still take up lots of space per bundle in these stretches, leading to potentially very low code density. The Mill gets around with a very CISCy encoding that only takes a small amount of I-cache size for single instructions.

The biggest issue with WLIW is the impredictability of the latency of memory loads which make any sort of static scheduling very hard for general purpose workloads. Itanium it seems had similar issues even with specialised hardware to help the compiler.

Not sure what's the memory latency hiding story for the Mill.

Edit: Symmetry said it better.

On the Mill, you tell it the address that you want to read and when you want to read it. So you could issue a load for XYZ as soon as you know what XYZ is and if there's a subsequent store to XYZ that will update the result so when the load returns you have the data that was there when the load returns and not from when the load was issued.

If you issue a load that completes in 5 cycles and it needs to go to RAM for that data then it's going to stall waiting for that data but because you can issue loads sooner than on other architectures you can sort of alleviate some of the problems with stalling on some load.

But as far as I understand and hear, Itanium had sort-of similar capabilities (ALAT and speculative loads) and it didn't work great outside of FP workloads as it is still hard to programmatically schedule load early even if you can ignore RAW hazards. What's unique in the Mill?

Basically they've used their exposed pipeline design and register metadata to fix the things that didn't work well about ALAT. Or at least that's the theory.

EDIT: I think the main problem was that on Itanium issuing a speculative load could potentially trigger a page fault making it potentially dangerous. On the Mill the page fault won't trigger until the load leads to a side effect outside the belt, sort of like it's been wrapped in a Haskell Maybe monad. So if you' have something like

  for (int i = 0; i < foo; i++) {
    a[i] = a[i]+1;
  }

you can speculatively load the a[i+n] while you're working on a[i] even if allocated memory stops at the border of the array allocation.

A couple things:

1) Intel is very heavily invested in x86, and they're likely to be very reluctant to change.

2) The Mill folks have patents, which might be hard to work around.

3) If the Mill becomes successful, they're likely to either be bought out by one of Intel's behomoth competitors, like Samsung or Qualcomm, or perhaps even by Intel itself.

4) If Intel really likes their technology, they could license it from Mill Computing. It would be surprising for Mill to say no to a reasonable offer, considering that they don't have their own fabs and it's their business model is to license their designs to those that do.

All but #4. Our business model is to sell chips, not licenses. Why? Intel's quarterly dividend is bigger than ARM's annual revenue.

Licensing is a backup plan.

Ah, thanks for the clarification.

You forgot:

5) Intel really likes their technology, but they do not want to license it so they decide to implement tweaks around the Mill patents.

A more likely strategy for a major (not Intel specifically) is to just use whatever they want without a license, and beat us to death with lawyers.

> The problem with the Mill is its not clear to me what advantage it can hope to seize over the behemoth which is Intel.

If the Mill actually achieves the stated 10x improvement in performance per watt, you'd be quite stupid not to use it in highly competitive markets like smartphones, because others will. It would provide a significant competitive advantage.

Fred Chow, who's great at compilers, expressed the opinion that the Itanium added instructions for many things that were already easy for compilers to deal with. That's not exactly a ringing endorsement. Mill appears to do a lot of stuff that's actually helpful to compilers.

Sounds like another Transmeta waiting to happen.