There are just 512 cache lines in both L1 code and L1 data cache.<p>512 * 64 = 32 kB. 512 is 8 * 8 * 8, I&#x27;d guess if they add more (up to 4096) L1 cache lines that access would take 1 clock longer. Which is very likely a net performance loss.<p>Maybe it&#x27;s time to increase cache line size to 128 bytes. That could of course break a lot of old code performance wise. It&#x27;d cause more false sharing [1] and double memory bandwidth requirements for random access. Maybe we should start to organize shared data to have 128 byte alignment.<p>It&#x27;d also break some read bandwidth-saving code that assumes 64 byte streaming (non-temporal) stores eliminate need for RFO [2] access.<p>Writing a <i>single byte</i> to RAM would require CPU core to first read a 128 byte cache line (RFO [2]) and then eventually write that cache line back. Currently &quot;only&quot; 64 bytes need to be read and written in the same scenario.<p>128 byte cache lines would mean L1C and L1D caches are both 64 kB, up from current 32 kB. That&#x27;d definitely help with monstrous codebases.<p>CPU design is full of compromises...<p>[1]: Atomic ops unintentionally touching same cache line cause performance loss through false sharing. The effect can be very significant, up to 2 orders of magnitude. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;False_sharing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;False_sharing</a><p>[2]: Read for Ownership. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MESI_protocol#Read_For_Ownership" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MESI_protocol#Read_For_Ownersh...</a>