EDIT: I'm not even considering pipelining, latency or transferring data among execution units, just assume every instruction completes in one cycle and makes its result available instantly.
EDIT: I'm not even considering pipelining, latency or transferring data among execution units, just assume every instruction completes in one cycle and makes its result available instantly.
Luckily there is a noticeable performance improvement between an i3 and an i7 precisely because normal app code doesn't go hopping long chains across main memory. This is the code we speed up.
An order of magnitude improvement is saying that - hand waving - you can have a hot monster at 10x OoO SS performance or a cool little chip equiv to the OoO SS but low power.
However, the faster you crunch the bits between main memory stalls, the more dominating those stalls become. Its diminishing returns. And hot is not good.
So we talk more about sweet spots like 3x performance and 3x less power, and temper them appropriately.
The numbers are based on sim and experienced estimates. Mill is faster because we can time x86 code and we can sim Mill code and we can compare them.
Am typing on a phone, apologises if brief.
The traditional rule-of-thumb is that programs have an ILP of two. The Execution talk (millcomputing.com/docs/execution) explains how the Mill turns that into an ILP of six. Then for the 80% or so of code that is in loops, pipelining has unbounded ILP - there will be a talk on pipelines upcoming.
What I want to know is just how silent the pipelines of this design would be under multi-threaded general purpose code.