There's nothing _in_ test1 or test2, so you're measuring nothing useful about whether -fomit-frame-pointer is a good idea in practice or not. There's so little going on that this is likely to be a test of the Core 2 architecture's ability to forward stores and schedule long mispredict-free chains useless instructions rather than what you think it is. For example, while 'test2' is obviously bigger than 'test1', most functions that do meaningful work typically have to do the sub/add adjustment of the stack pointer already.

Neither the caller nor the callee do ANY meaningful work, so you're just executing a long chain of pointless instructions. It is well known that some chains of pointless instructions run faster than others.

This is the big problem with the benchmark; all of the items you list in your colorful 'why my benchmark is bullshit' are third-order at best. It is deceptive to puff up a meaningless benchmark with 'rigor' like running on the bare metal and disabling IRQs; these heroics are completely unnecessary for evaluating user-space performance changes. It would have made a whole lot more sense to grab a bunch of CPU intensive programs and to measure them with and without the flag, for example.

i cant use isolcpus (nor could i pin init to cpu 0, and have everything then be pinned to cpu 0) because i can't reboot that box. i am 'borrowing' a system that has other shit running on it and none of those things can be turned off or stopped for me to do a reboot.

as i said above, the testing environment was non-ideal but its all i got. i tried to compensate for this by taking a lot of samples.