Make a fortune from benchmarking

Discussion in 'iOS Programming' started by firewood, Dec 23, 2017.

  1. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #1
    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 ... :)
     
  2. Altis macrumors 68030

    Joined:
    Sep 10, 2013
    #2
    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.
     
  3. xStep macrumors 68000

    Joined:
    Jan 28, 2003
    Location:
    Less lost in L.A.
    #3
    I think writing ARM Assembly and knowing the cycle counts of instructions should yield an accurate number based on timing the code.
    --- Post Merged, Dec 25, 2017 ---
    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. :mad: 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.
     
  4. firewood, Dec 26, 2017
    Last edited: Dec 26, 2017

    firewood thread starter macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #4
    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.
     

Share This Page