> it also gives us better density overall by having smaller instructions. x86 can put more work into each instruction byte, so we can have denser binaries and increase performance that way.<p>Is that really true? I was under the impression that ARM core density was better than x86.<p>The first Google result I found agrees: <a href="https://www.bitsnbites.eu/cisc-vs-risc-code-density/" rel="nofollow">https://www.bitsnbites.eu/cisc-vs-risc-code-density/</a><p>> It may take a little bit more microarchitectural work for us to account for stronger memory order on the x86 side, but of course the software has to account for the weaker memory ordering on the ARM side. So there are tradeoffs.<p>I don't think this makes sense either since software has to have synchronisation anyway. I don't think much software <i>relies</i> on x86 TSO (intentionally anyway; I'm sure many bugs are covered up by it).<p>Anyway fantastic interview! Very refreshing when they're actually technical with interesting questions and answers.
It's an interesting interview but also horribly frustrating.<p>There's talk about vectors, longer basic blocks and cache utilization and how they wish programmers used more of it, it misses the real world.<p>Regardless of how "hardcore" programmers feel about it, so much real world executed code is built in JS,etc. The JIT:ed code is super-branchy (to cater for deopt fallbacks) and won't use vectors at all.<p>This is something Apple has gotten correct with their vertical integration as they seem to have put more focus on making real-world code go fast. Even most games will have huge swaths of non-vectorized code that would benefit from a more scalar focused way of optimizing.<p>Considering transistor counts in use today, instead of bigger vector units,etc it could be spent on bigger UOP buffers, BTB buffers, bigger caches to eat up branchy-but-linear code flows that are reality for less "optimal" languages).
Great interview, more please.
Is there a way to submit question? I'd like to know 1) what affects branch predictors? From my understanding return statements do and cmov does not 2) Why isn't there a conditional exception? to replace if (!cond) { __builtin_trap(); }