LIFO stacks using an array are equally cache-friendly for either growth direction, unless you have a specific pattern of sizes that happens to favour an odd-sized allocation and growing down. APIs for efficient reallocation (without copying the data) like Linux mremap or C realloc are designed around adding new space at the end of an allocation, not the start, so that s a point in favour of the normal way if your stack can grow beyond the initial allocation. At least if you re using an allocation API that supports those, not like C++ s crippled new/delete which essentially forces std::vector to suck. Other than that, they re equal unless your high water mark is commonly 1 or 2 elements more than a multiple of 64 bytes, like you ve shown here to make your other version look good. In that version, the first element pushed is in a cache line by itself, but the top-of-stack hasn t yet crossed into a new cache line. If you push one more element in your second diagram, it will be the only in-use element in its cache line. It only looks good because you picked a number of elements for the current stack state that happens to work well with the misalignment (relative to cache-line boundaries) you chose for the first element (the "bottom" of the stack, at the highest address for your grows-down stack). With your grows-down gap-at-the-front design, potentially the first element pushed (highest address) is in the same cache line as some other useful data, so that cache-line staying hot can be helpful (if your stack frequently becomes empty so you actually access that element). Memory allocators often round up allocations to multiples of some larger size like 16 bytes, but there could still be other allocations in one cache line. Still, unless you know something special about your expected stack sizes and/or what comes next, normally you d want to allocate a chunk of memory that s a multiple of the cache-line size. Fun fact: the asm callstack grows down on mainstream ISAs (and calling conventions for ISAs like MIPS which don t favour one stack-growth direction). e.g. x86 push and call decrement the stack pointer register (RSP). The reasons for this aren t cache efficiency, more historical, dating back to before CPUs had caches. It doesn t present any particular problems for CPU caches, though. CPU/asm stacks are allocated such that the highest-address cache line is fully used, unlike yours where the end of the allocation isn t the end of a cache line. (Typically "the stack" is a multiple of the page size, so there won t be other stuff next to it in the same line anyway.)