iOS Make a fortune from benchmarking

[firewood]

So DasherX and Geekbench are making a mint today from their rising positions in the Paid App rankings for reporting CPU frequency.

The thing is, there is no legal public API to get the real CPU frequency in any current release of iOS.

hw.cpufrequency returns 0

So people are throwing cash at them to see a made-up number displayed on their iPhone.

(Wish I had though of that ...

 

[Altis]

It isn't just for the frequency but for the overall performance scores, so they can compared with the benchmarks of the device when new.

But yeah, now lots of people want to know if Apple has throttled their device and that's why it feels slow, since they hadn't bothered to mention it a possibility.

 

[xStep]

So DasherX and Geekbench are making a mint today from their rising positions in the Paid App rankings for reporting CPU frequency.

The thing is, there is no legal public API to get the real CPU frequency in any current release of iOS.

hw.cpufrequency returns 0

So people are throwing cash at them to see a made-up number displayed on their iPhone.

(Wish I had though of that ...

I think writing ARM Assembly and knowing the cycle counts of instructions should yield an accurate number based on timing the code.
[doublepost=1514196753][/doublepost]

But yeah, now lots of people want to know if Apple has throttled their device and that's why it feels slow, since they hadn't bothered to mention it a possibility.

I saw something that said Apple had mentioned this process about a year ago. Apparently the yech writers knew about. Perhaps that info is at imore or daringfirball.

All I know is that my iPhone 6 slowed down the day I was forced to update it iOS 11 to use my new Apple Watch. The battery health certainly didn’t change in the time it took to upgrade.

I think Apple will end up putting this info in the Settings Battery on General panels.

 

[firewood]

I think writing ARM Assembly and knowing the cycle counts of instructions should yield an accurate number based on timing the code...

That might have been true back in the days before implementations using multi-issue pipelines, multi-level caches, branch prediction and register renaming (etc.) became common. But now it's no longer interesting how may cycles each instruction takes, but how many instructions are running at the same time during each clock cycle; plus stuff like cache miss rates and penalties, branch prediction accuracy and penalties, register renaming and retirement buffer bottlenecks, forwarding paths, instruction reordering, and etc.

For instance a processor such as the A10 in the iPhone 7, with a reported pipeline depth of 16 and an issue width of 6 could potentially have up to 90 instructions in flight during a single clock cycle. But miss the I & D caches and the miss penalties could be many dozens of clock cycles while the pipelines are stalled. So it's very hard to determine how many instructions are actually in flight during any one cycle without Apple's access to a special internal hardware debug logic, or their hardware simulators

What this means is that a clock speed estimate by merely adding per instructions cycle counts could be off by a large multiple in either direction.

e.g. bogus.