One case that doesn't mention explicitly: sometimes your problem is lucky enough that you have the choice between: 1. for each function, for each datum, call f

One case that doesn't mention explicitly: sometimes your problem is lucky enough that you have the choice between: 1. for each function, for each datum, call function with datum 2. for each datum, for each function, call function with datum For 1, if your main data is fetched predictably but does not saturate bandwidth, it can be beneficial to use even a fairly large LUT. Note also that while actual L1i is semi-ignorable, e.g. branch prediction benefits much more from remaining "in cache". For 2, assuming other functions also have their own miscellaneous data, the non-LUT approach is likely to win. But you should probably benchmark against #1. But sometimes you can get the best of both worlds: 3. for each arbitrary chunk of data (smaller than L3, or maybe even L2 depending on when your throughput saturates), for each function, for each datum in the chunk, call function with datum Yes, you should of course do whole-system benchmarks, but being able to guess helps you write a useful implementation to benchmark in the first place.