3 ms·

> which is an easy >20% IPC improvement on Coremark. Of course, a lot more reworking would be needed to achieve x86-64 clock frequencies. Maybe these should be

> which is an easy >20% IPC improvement on Coremark. Of course, a lot more reworking would be needed to achieve x86-64 clock frequencies. Maybe these should be expressed as Instructions Per Second (at peak and at the point of diminishing returns?) or something like that, rather than two independent numbers. Higher clock frequency actually seems like a bad thing, all else being equal. It seems to me that throughput ought to trend toward infinity, clock frequency toward zero. ;- )

_chris_ 9y ago
Of course it's important to always keep the "Iron Law" in mind, but it's far easier to compare ideas and talk about things in terms of IPC. For example, if a switch out one branch predictor for another, we're talking about an algorithmic change (implemented in hw) that will have an effect on IPC, and no effect on clock period (assuming we didn't screw something up). This is particularly useful when talking about a processor design, and not a specific processor in particular. As you said, there's a lot of good about slower clock frequencies, so you'll see the same ARM design being deployed at a variety of frequencies. Far easier to talk separately about a design's IPC from its achievable clock frequency (although both are important!).