You are correct, I am just making an assertion, but I don't have to prove it, I will be satisfied to wait and watch things play out. There is a lot of money and

You are correct, I am just making an assertion, but I don't have to prove it, I will be satisfied to wait and watch things play out. There is a lot of money and a many industry players working on RISC-V, so eventually the market should provide evidence to prove or invalidate my thesis. I don't think the ARM architects did everything correctly and the RISC-V did everything wrong. I just chose an example I felt was an issue. On the other hand, I think that RISC-V supporting variable length instructions that are encoded with such that they can be easily decoded in parallel was very good use of encoding space. What frustrates me about RISC-V is that it feels like it ignored the last 20 years of industry experience and made a lot of unforced errors. I think you are correct that I misestimated the branch density in normal linux binaries (the system I work on is a bit different), so I will take back my claim about code size increase, but I also think large binaries like Chrome are more significant than you seem to imply, especially once you start looking at desktop and mobile platforms. We can argue about people writing bloated code, but the fact is that apps like Twitter and Facebook ship mobile apps that are over a 100MB of executable code. And these things are not getting smaller over time. As code sizes increase that 2MB jump window is going to look very small. It is going to be interesting to see how this plays out over the next few years.