Where This Shows Up
Cache-aware algorithms and tiling, what the compiler did before the CPU saw your code, side channels as a consequence of speculation, and the hardware under virtual machines and containers.
Two algorithms with identical asymptotic complexity can differ by an order of magnitude in wall clock, because complexity analysis counts operations and hardware charges for data movement. Blocking, compact layouts and node sizes matched to the transfer granularity are all the same idea: arrange the work so that data pays its travel cost once.
The tiled matrix multiply performs exactly the same multiply-accumulate operations as the naive triple loop, in a different order. It wins because a block of each matrix is brought into cache once and used many times, instead of a row or column being re-fetched on every pass.
Between the line you wrote and the work the machine performs sit two independent reordering layers: a compiler that transforms code under the language's rules, and a processor that executes the result out of order under the architecture's rules. Each preserves its own notion of observable behaviour, and neither preserves the order you wrote.
Two adjacent lines of source imply neither two instructions nor two steps in time. Source code specifies *what result is required*, and it is an excellent tool for reasoning about correctness — but it deliberately says nothing about instruction count, ordering or cost, which is exactly why measurement exists.
Every mechanism that makes a CPU fast by remembering something — caches, branch predictors, translation buffers — creates state that outlives the operation and can be observed indirectly through timing. Information leaks not through what a program outputs, but through how long other things take afterwards.
In 2018 a class of vulnerabilities showed that speculative execution — a two-decade-old performance technique — could be steered into performing accesses that architecturally never happened, while leaving microarchitectural traces that a timing side channel could read. The durable lesson is not the specific bug but its shape: a performance optimisation created a security boundary violation, and the mitigations cost real performance.
Running a guest operating system that believes it owns the machine used to require interpreting or rewriting its privileged instructions. Hardware virtualization support added a mode below the kernel's, so a guest can run its own privileged code at native speed while the hypervisor stays in control — and a second layer of address translation so guest memory works without the hypervisor intervening on every access.
A vCPU is not a core. It is a schedulable thread of execution that the hypervisor multiplexes onto physical hardware, sharing that hardware with other guests. This is why cloud instance performance varies, why steal time exists, and why the count in the instance description does not translate into a guaranteed amount of compute.
An allocation call returns a pointer, but between that call and a cache line being filled sit an allocator, a virtual address space, a page fault, a physical frame chosen by the kernel and finally the hardware that transfers the line. Each layer shapes where your data lands, which is why allocation pattern becomes cache behaviour.