Hacker News Reader

Comment by mhh__ | Hacker News Reader

Intel's revenue is big enough that they must have some kind of warchest to fall back on. Obviously money isn't everything but it doesn't hurt.

They can probably still hammer AMD on both their software and documentation, i.e. roughly a quarter of their sales are to data centres.

It will be interesting to see what happens to X86 post-M1 (i.e. ARM coming of age), I suspect not much but I think the world has changed enough to have another stab at VLIW (for example) even if the cost/benefit is pretty marginal.

View on HN

The current CPU's already are VLIW in a fashion. Its just that they have a hardware jitter for it. That's what superscalar OoO CPU basically is, a piece of HW that generates VLIW instructions based on the normal instructions that come in. A superscalar execution port is basically just one subinstruction in VLIW. Explicit VLIW only helps you to save that piece of silicon from the chip. And it's not that much in the grand scheme of things. It used to be, but not anymore.

Static compile time VLIW means one cannot really make it wider anymore, or narrower. Dynamically doing it on runtime means a cheaper and smaller core can just be narrower. Remove an instruction slot for one integer ALU? Fine, no issues. Everything still works, albeit slower by that much. Make a beefier chip? Perfect, it got faster by the amount of instruction level parallelism that was available.

In addition a compiler cannot really see across function boundaries (except if it's statically determinable). A jitter can. Modern chips have reordering window of hundreds of instructions, M1 apparently goes up to over 600. That's quite a lot of stuff there that it can dynamically reorder across. A compiler might not have noticed that due to some weird dynamic call that was not visible during compilation time there is now an FPU instruction that could be inserted here, an OoO processor can.

Due to that explicit VLIW is basically dead outside of some highly specific applications, like DPS and whatnot.

In a similar fashion ridculously wide vector units were obsoleted by the approach pioneered by GPU's. Just add few things to allow masking based on branches and you get SIMT approach. Write as if it was scalar code and it'll run on HW that has vector lengths going from none at all up to whatever, NVidia has 32 wide vector units as an example.

Even more importantly, and I'm surprised you didn't mention it, static compile time VLIW doesn't know what to do for memory access. A load might take any number of cycles depending on whether the line is in L1, L2 or L3 cache, with static compile time VLIW then the compiler has to guess, if it's optimistic the whole CPU stalls, if it's pessimistic then you're much slower than you would otherwise be.

I believe this is the real thing that make superscalar OoO (ie. JIT to VLIW in silicon) win.

That's a great point to emphasize. Because memory access times are inherently more or less nondeterministic.

I consider it to be roughly as important as being able to reorder instructions across non statically determined branches and function calls. And both of these expose the fundamental weakness in explicit VLIW, if it's essentially nondeterministic it cannot be taken advantage of.

Then we naturally have some other benefits, like hyperthreading. Which basically is just compiling two instruction streams together on the fly.

The performance on particularly memory-bound workloads is why I chose it as an example rather than a prediction.

For it to work statically (although it really could be halfway in between), it would probably require a complete paradigm shift away from the current way we think about cpu caches

Regardless of whether it'll work or not, I'll be very happy if the mill ever makes it onto a chip.

And by jitter you mean JIT-er (Just-In-Time Compiler), not jitter as in https://en.wikipedia.org/wiki/Jitter

Got really confused at first.

You're using terms to mean things that they usually do not mean. Calling superscalar OoO scheduling a jit-ed VLIW is misleading at best. The whole point of VLIW is that you don't need the control logic and, more importantly these days, the power cost of scheduling each instruction by itself.

From a single thread performance standpoint, the important part is that OoO scheduling is able to dynamically schedule around cache misses to effectively keep more memory accesses in flight, extract more memory level parallelism. In principle you could make an OoO VLIW CPU, but that would negate most of the power benefit while hamstringing the scheduler with unnecessary dependencies. Where in-order VLIW shines is when memory accesses are predictable, like DSP code. There you get an order of magnitude power efficiency gain.

GPUs are effectively still in-order CPUs with large SIMD instructions, some useful instructions to make masked execution simpler and a specialized language and compiler to hide this model from the developers. GPU manufacturers calling these separate data lanes threads is just misleading marketing BS. There is no independent instruction pointer for each lane.

That's why I tried to use it more as a methaphor. Because the whole point of explicit VLIW (EPIC was what Itanium folks called it) was to save that scheduling HW. But nowadays that piece of HW is relatively minor part. So it's no longer worth to save it in a general purpose CPU. As this thread is about general purpose CPU's for direct consumer use (not a controller in hard drive or whatnot, but a full fledged CPU you run arbitrary programs in) we're talking about chips like Itanium when it comes to VLIW.

I do not disagree that VLIW is a great for things like DSP where the power consumption is of the essence. One can get ridiculously high perf/watt by going explicit VLIW. I just don't see any way we'd see that approach in general purpose CPU's again.

GPU's do not need to reorder instructions to hide memory latency. It just happens on a different level. While a single threadgroup (as in that single instruction pointer that controls the SIMD unit) will not get reordered at all, one has multiple threadgroups in flight. So if one group stalls at a memory load the unit will just schedule a different threadgroup. Because one generally has tons of them in flight. It's all about throughput. One could think of this as an in order CPU (from viewpoint of a single thread) but with ridiculous amounts of hyperthreading (one thread stalls, we can pick an instruction from another thread but never one from the stalled thread).

I’ll second this. My M1 Air is a freak of nature. I’m so excited for this next wave of computing. Lots of things that need setup Dev tooling wise and much work underway to get it supported but my god man... and it’s passively cooled.

I have a beast i7 gaming rig too and my M1 beats it at everything but graphics performance.

What I think Intel will continue to work their enterprise business until this “arm wave” starts to pull up. Engineers at Intel probably have some ideas.

I genuinely don't think M1 is a new wave of computing (yet), both in the sense that it's apple so it's not up to you what you do with it but also because ARM and X86 aren't all that different these days. Ultimately M1 is "Company with enough money to buy the US Navy, follows existing path to logical conclusion, succeeds".

If a company other than apple makes a fast arm chip that'd be very interesting, though. Nvidia have probably thought about it.

Time will tell if you're right. I do think that what's happening under the hood of the Apple chip is real and is causing more than a few executives in the silicon world to lose sleep.

This reminds me of when RIM got their hands on an iPhone for the first time.

One of many articles: https://appleinsider.com/articles/10/12/27/rim_thought_apple...

I think it the hints were there if you were in the industry. CPU scaling is TPU scaling and apple's chips were showing leading single core performance compared to android / qualcomm chips for many years now with very low power usage. After that you could see how they could scale that up relatively easily.

Also apple built in some special instructions that makes macOS software better, like core operations of objective-c, so some of this might be very apple runtime specific optimizations.

The first iPhones used generic Samsung processors and the power is quite similar to the hardware in BlackBerrys contemporary products.

They probably just didn’t realize that one day of battery life is enough for most use cases and is less important than a real browser and the other features brought by the iPhone.

I feel like you're glossing over a bunch of things here.

1) the display on the iphone was gigantic compared to any other device on the market. The fact the iPhone had the battery life it did was amazing.

2) the software on the iphone destroyed anything RIM had ever put forward.

3) the iPhone was a much better piece of hardware aesthetically and performance-wise than anything RIM had ever put out. Their closest competitor was the Pearl and it was garbage compared to the iPhone.

4) Lastly, RIM had 10 year development cycles. Pivoting to attack the iPhone meant ripping apart 10 years of planned development much of which was already executed. Pivoting that hard is just not something companies at the scale or RIM are designed to do.

RIM should've seen the writing on the wall, shred their hardware business, and gone all in on supporting BES on iPhone. I digress...

I don’t know if there was a future for them anyway. What could they have done that Apple could not?

Did they even have a way for third parties to make apps? Even though the iPhone originally didn’t have that the jailbreak community pretty quickly showed that was the way forward.

Just to be clear, RIM was on top of the world when the iPhone came out, and, if they had been fast pivoting they might still be relevant in the world.

Reply on news.ycombinator.com