Myths Programmers Believe about CPU Caches (2018)
software.rajivprab.com
Myths Programmers Believe about CPU Caches (2018)
1–10 of 143 posts
Re: Myths Programmers Believe about CPU Caches (2018)
#22018
Re: Myths Programmers Believe about CPU Caches (2018)
#3Hmm, I think the discussion is missing a few things needed for a complete picture of the situation.
First, ARM and x86 coherency models differ, so a big disclaimer is needed regarding the protocol. Most ARM processors use the MOESI protocol instead of the MESI protocol.
Second, synchronization isn't just because of register volatility and such. Synchronization is needed in general because without the appropriate lock/barrier instructions, compilers make assumptions about how loads and stores may be reordered with respect to one another.
Re: Myths Programmers Believe about CPU Caches (2018)
#4SQLite database locks can be more quickly obtained and released if CPU affinity is set for the database processes, allowing all I/O activity to share the same cache(es).
I have read (but cannot remember where) that this can increase performance by thousands of DML operations per second.
Re: Myths Programmers Believe about CPU Caches (2018)
#5My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host.
I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every function and procedure call, stack operations, actual size of objects/structs under alignment, optimisations in the assembler to align or select code which runs faster in the given ALU, none of which I know (if I ever did, certainly not any more)
But still: I believe this myth. I believe I know somebody who has achieved it, to test some ideas about CPU's ability to saturate a NIC at wire-rate, with pre-formed packets. He was able to show by binding affinity to specific cores and running this code, he could basically flood any link his CPU was capable of being exposed to, for a given PCI generation of NIC speeds available to him. (as I understand it) -But that assumes that walking off L2 cache would somehow make it run SLOW enough, to not be able to do this.
So I think it remains a myth, to me.
Re: Myths Programmers Believe about CPU Caches (2018)
#6My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host. I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every…
Modern CPUs are pushing 1MB L1 and 8MB L2 or more. You can fit a dozen FreeRTOS instances in that space. It would be pretty cool to see someone build a system that used a high end CPU but didn't have any installed ram, though I'm not sure if the CPU microcode would be ok with that.
Re: Myths Programmers Believe about CPU Caches (2018)
#7My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host. I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every…
I mean, your computer likely does this during boot when it’s in cache-as-RAM mode
Re: Myths Programmers Believe about CPU Caches (2018)
#8My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host. I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every…
If you only boot one EFI process, or a small linux kernel + single binary small enough, you can get there.
Re: Myths Programmers Believe about CPU Caches (2018)
#9My favourite myth is that I still believe it's possible to write code which operates totally out of L1 and L2 cache. Not just tight ASM on bare metal: C code or similar, compiled down, to run under a modern UNIX/POSIX os on a multi-core host. I have never explored HOW this would work, or WHAT I would do to achieve it, but I believe it, implicitly. For it to be true I would have to understand the implications of every…
Modern CPUs are pushing 1MB L1 and 8MB L2 or more. You can fit a dozen FreeRTOS instances in that space. It would be pretty cool to see someone build a system that used a high end CPU but didn't have any installed ram, though I'm not sure if the CPU microcode would be ok with that.
Those numbers are for all cores. No modern CPU has anywhere near that of L1 and L2 per core.
Re: Myths Programmers Believe about CPU Caches (2018)
#10This article gives the impression that everything is the compiler's fault when you end up with conflicting reads in different cores, but that's not right.
From the point of view of someone outside the CPU, yes you can say that simultaneous reads might never give different answers. But everything happening at that level barely resembles the original software. Dozens of instructions are happening at any moment, overlapping each other, starting and finishing in very different orders from how they're stored in memory. This happens even if you directly write machine code byte by byte.
From the point of view of the software, running a bunch of instructions in sequence, you do get stale values. You can have two threads wait for a signal, then both read a value, and both get different results. You can have a thread set a flag after it's done editing some values, have another thread wait for the flag, and then after waiting it sees the edits as still incomplete.
The exact types of nonsense depend on the memory model, but things as simple as two MOV instructions in a row can violate strict ordering. It's not just that the compiler might stash something in a register, but that the CPU itself will make swaths of very observable changes within the rules set by the memory model.
You can't trust the hardware coherency protocol to do much for you until you follow the platform-specific rules to tell the CPU to make something act coherent.