New iPad Pro IS fast

Discussion in 'iPad' started by ahostmadsen, Jan 3, 2019.

  1. ahostmadsen macrumors 6502a

    Joined:
    Dec 28, 2009
    #1
    Just for fun, I tried to run some simple timing loops in Pythonista. They take about the same time as on my 2017 15" MBP . For comparison, they take about 4 times as long on my old 9.7" pro.

    Unfortunately, Apple does not allow Pythonista to use multiple cores. With 6 cores it should run circles around my 4 core MBP.

    What I don't understand in the context of this is why so many of my apps run slower on the iPad than on the MBP.
     
  2. ahostmadsen thread starter macrumors 6502a

    Joined:
    Dec 28, 2009
    #2
    I was a little off: the iPad pro has 8 CPU cores, 4 high performance and 4 efficiency cores. Not sure if you could run all 8 at the same time. Anyway, Pythonista cannot use them.

    I wonder if the reason apps are slow is memory restrictions?
     
  3. gnomeisland macrumors 6502a

    Joined:
    Jul 30, 2008
    Location:
    New York, NY
    #3
    I've noticed that 3rd party apps don't seem to be as multi-threaded (or able to push the processor) as well as Apple's native app. My evidence is mostly anecdotal.
     
  4. Whoakapi macrumors 6502

    Joined:
    May 26, 2010
    #4
    Apple had to limit the new iPad Pros so it only would bend itself slightly.

    Try to imagine how bent the chassis would be if they let you use the full potential of the A12X.

    /s
     
  5. Samuelsan2001 macrumors 604

    Joined:
    Oct 24, 2013
    #5
    They can use all 8 cores.
     
  6. spudWorks, Jan 11, 2019
    Last edited: Jan 11, 2019

    spudWorks macrumors newbie

    Joined:
    Aug 27, 2018
    Location:
    Hamburg, Germany
    #6
    The new pros can use all eight cores but whether the developer can is a bit limited.

    The developer can spin off as many background threads as they want to handle things that don't touch the user interface. This is usually stuff like networking, CoreImage, heavy calculations, whatever. They can set a priority when they're dispatched. But once they're dispatched, it's up to iOS' kernel to determine where to run them. And this is determined by a number of factors including the length of the current workload, the size of the queue, etc.

    If the kernel gets two requests for two background tasks and they're relatively light, it is just as likely that it might run them sequentually on the same core as on two seperate cores depending upon the above factors. The developer has no say as to where.

    The only really important thing is that the developer spins these tasks off of the main thread that handles all of the UI updates and user touch responses. That thread always has priority and running a large blocking task on it (like network requests) will mean that the whole app feels "slow" as it works through its current task before responding again to the user.

    So it's tough to tell if Apple has given themselves a hidden fast lane that only they have access to or whether the developers of some of the apps being using aren't properly dispatching their workloads onto child threads.
     
  7. A.R.E.A.M. macrumors regular

    Joined:
    Nov 12, 2015
    Location:
    Los Angeles, California
    #7
    Thanks for your explanation. Its really interesting to a novice like myself.
     

Share This Page