i wasn&#x27;t really referring to linus&#x27;s comments although he is pretty much spot on, i hate to say (i have no great love for him XD).<p>you are right that numbers are numbers, but that says nothing about what they mean or measure. i can write a program that has benchmark in its name and just pulls any old number out, like how many millseconds since the last hour ticked over and give that back as a number. you will get meaningless results.<p>the argument the author of the geek bench software makes sounds kind of valid but there is something i learned many years ago about optimisation and performance. measurement trumps everything. given that the futuremark physics demo uses bullet physics, complete with its own tight inner loops is a great example of a measurement showing that this benchmark does not correlate with real world uses. the large number of other benchmarks that agree are even more data to support that argument.<p>that being said his argument is technically baseless afaik too. no app, not even a simple renderer of a blank screen will spend all of its time inside of a short tight innermost loop - it will spend its time bouncing between multiple of them, doing a lot of waiting and having its time stolen at any given point by the OS. i&#x27;d be curious to know how he thinks these behaviours will go away in the future? the i-cache setup and L1 cache sizes are not enough for even some quite simple loops even if they are 8-way associative and bristling with all the latest features - its often quite trivial to construct pathologically bad cases using common programming practices - e.g. writing your code using objective-c or swift there is a lot of scope for cache missing and pollution. i can go into excruciating detail about this if you are interested and provide repeatable experiments to back my claims, i&#x27;ve done plenty of work on these things writing and optimising code... but this is long already. :)