5 ms·

Indeed, usually optimizing for size is optimizing for speed (less cache pressure, deeper pipelines, etc.)

• rbanffy 8y ago
  OTOH, if you can move a couple billion transistors from instruction decode and reordering to the L1 cache and execution pipelines, you'll get less cache pressure and deeper pipelines. There is no magic - down at the back-end, x86's and ARMs are doing the same thing and getting the same performance will cost about the same chip area and power. Where they differ, however, is on the front-end, the pieces that decode instructions, issue micro operations and schedule them through to the execution units. In that space ARM64 seems more promising. Unless, of course, Intel decides to throw away a lot of the backwards compatibility and goes very low-transistor-budget for legacy instructions (maybe software traps), freeing a ton of chip area to implement the ones they care about in a fast and power efficient way. That x86 would be unable to run DOS, but I don't think many of us would care.
  • StrangeDoctor 8y ago
    OTOOH, you can't just add a couple of MB of L1 cache without increasing delays and even trying to add to other layers would result in much more complicated lookups.
    • rbanffy 8y ago
      You may be unable to significantly enlarge the caches, but you could assign a larger cache to each core or privilege level, a larger, less shared, L2 or L3 or even go like the IBM z and implement an L4 cache.