Slashdot Mirror


New iPad Pro Has Comparable Performance To 2018 15" MacBook Pro in Benchmarks (macrumors.com)

A series of benchmark results have shown up on Geekbench for the new iPad Pro, and its new eight-core A12X Bionic chip is truly a powerhouse. From a report: The new iPad Pro achieved single-core and multi-core scores of 5,025 and 18,106 respectively based on an average of two benchmark results, making it by far the fastest iPad ever and comparable even to the performance of the latest 15-inch MacBook Pro models with Intel's six-core Core i7 chips. We've put together a chart that compares Geekbench scores of the new iPad Pro and various other iPad, Mac, and iPhone models.

That the new iPad Pro rivals the performance of the latest 15-inch MacBook Pro with a 2.6GHz six-core Core i7 processor is impressive, but even more so when you consider that the tablet starts at $799. The aforementioned MacBook Pro configuration is priced at $2,799, although with 512GB of storage. Even the new 11-inch iPad Pro with 512GB of storage is only $1,149, less than half that of the Core i7-equipped MacBook Pro.

8 of 171 comments (clear)

  1. Convergence is Coming by bill_mcgonigle · · Score: 4, Interesting

    Apple already did PPC to Intel on the current architecture and a good number of people believe the Mac will go Apple ARM soon.

    Then it's simply a matter of having a Mac Mode on the iDevices that offers a KVM experience.

    Looks like that day is getting closer.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re: Convergence is Coming by jonnyj · · Score: 5, Interesting

      Mac on ARM makes a lot of sense for Apple.

      From a business perspective, they have always believed in vertical integration. Using their own CPUs will also leverage their existing investments in A-series CPUs. If ARM Macbooks can sell for the same price as Intel Macbooks, Apple's profits will increase sharply and they will better control their own destiny.

      From a user perspective, ARM Macbooks will likely be quieter, lighter and need to be recharged less often. Old software will need to be recompiled, but all major software packages (Office, Adobe stuff, etc) will become available immediately and smaller software houses will have no option but to offer ARM versions of their code. Besides, most things are done in the browser these days.

      The only losers will be people who want to dual boot Windows. Maybe Microsoft will rescue them with ARM Windows, but I doubt Apple cares very much.

  2. Re:Forget MacBook Pro.. ARM A12X as fast as Corei7 by timholman · · Score: 4, Interesting

    But an ARM CPU on par with the (relatively) high end Intel Core i7!?!?!
    This is big news!!!

    Big news for Apple, and very bad news for Intel. The last thing they need is yet another indicator of how stagnant the Intel processor line has become.

    Lots of people have speculated that the next generation of Apple laptops will drop Intel entirely. If Apple can fab a 7nm A12X variant at TSMC that runs Mac OS, the switch could happen as early as next year. TSMC already has at least a one-year lead over Intel. Intel's 10nm fab (comparable to TSMC's 7nm fab) won't ramp up until late 2019.

    And if Apple abandons Intel for ARM / TSMC, how long will it take for other companies to do the same?

  3. Re:Selective by goombah99 · · Score: 4, Informative

    Apple has a long history of exactly that.

    Remember when the PPC supposedly outperformed x86? They never said it was only on integer math.

    They ran on-stage demos of doing complete photoshop editing workflows and there are minutes of difference between the Intel and PPC outcomes. Those were real world examples of the PPC creaming the intel at that time. Of course eventually intel won back the crown as the ppc development went off-track.

    The same sort of thing goes on with the AMD ryzen vs intel right now too.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  4. Geekbench is Shit by Jeremy+Erwin · · Score: 4, Interesting

    Wilco, geekbench has apparently replaced dhrystone as your favourite useless benchmark.

    Geekbench is SH*T.

    It actually seems to have gotten worse with version 3, which you should be aware of. On ARM64, that SHA1 performance is hardware-assisted. I don't know if SHA2 is too, but Aarch64 does apparently do SHA256 in the crypto unit, so it might be fully or partially so.

    And on both ARM and x86, the AES numbers are similarly just about the crypto unit.

    So basically a quarter to a third of the "integer" workloads are just utter BS. They are not comparable across architectures due to the crypto units, and even within one architecture the numbers just don't mean much of anything.

    And quite frankly, it's not even just the crypto ones. Looking at the other GB3 "benchmarks", they are mainly small kernels: not really much different from dhrystone. I suspect most of them have a code footprint that basically fits in a L1I cache.

    Linus Torvalds, Transmeta Engineer

  5. Re:This is really news! by amp001 · · Score: 4, Interesting

    ARM licenses the instruction set and their implementations of it independently. Apple licenses the instruction set, but their A-series chips are custom implementations of that architecture as far as I know. One of the differences is that the recent A-series chips no longer include support for the 32-bit instruction set –only 64-bit (iOS can't run any 32-bit code any more). This is important because the older 32-bit instruction set had some unpleasant aspects when it came to performance (barrel shifter in the data path, conditional execution bits taking up instruction encoding space, 16 architected registers, etc.; that's just from memory). The 64-bit ARM instruction set is pretty clean (I remember thinking it looked more like MIPS or Alpha when I looked at it briefly), and that helps when you're trying to go fast. Meanwhile, Qualcomm has to continue to support the older 32-bit instruction set (and maybe even the ancient "thumb" stuff) on the same die as the newer 64-bit mode. Intel is in the same boat (only with even more –and even older –baggage). There's another difference between Apple's processors and the ones on Android phones that goes unnoticed by most. Apple's APIs are all non-blocking / event-driven. Want to run an HTTP server on the same thread as your UI? You can, and it's easy, and it even works pretty well. Android APIs are almost entirely blocking, because of the Java legacy. So, on iOS, you see lots of apps with only a few threads doing most of the work, while on Android, you see dozens of threads, and the work is spread across them. This is why Apple focused early on optimizing single-core performance while Qualcomm was busy adding lots of slower cores to their chips. Both companies were doing the right thing for the platforms they were targeting. But, now that Apple has those highly optimized single cores, and a machine like the big iPad Pro that can dissipate more heat, then can put 4 of those fast cores in there and get some impressive numbers.

  6. Yeah, cause geekbench numbers are good by viperidaenz · · Score: 5, Insightful

    I looked on http://browser.geekbench.com/p... and it says "Geekbench 4 scores are calibrated against a baseline score of 4000 (which is the score of an Intel Core i7-6600U). Higher scores are better, with double the score indicating double the performance."

    I scrolled down to 4000 and couldn't find the 6600U.
    If you scroll down further you can see Intel Core i7-6600U 2.6 GHz (2 cores) 3438

    They're also saying, for example, a 16 core Threadripper 1950X is slower at multi-core than a 10 core Intel 6950X. Everyone else puts the 1950X at ~50% faster - it has more cache, more cores, more mhz, consumes more power and is a year newer.
    If that's how they compare two x86's I'd hate to see how bad ARM vs x86 is in their tests.
    They'd have you believe an iPhone XS is about a fast at single core tasks as a Mac Pro boosting to 4.something GHz

  7. Re:This is really news! by amp001 · · Score: 4, Informative
    Sure. Blocking APIs are things like "reading this file and wait until the bytes are actually read before moving on to the next line of code". But, even though reading a file doesn't take long, the kernel still has to do something with your thread while it's waiting on the IO. So, it has to put that thread to sleep and find another thread to run. Now, imagine this was a network IO over a cellular network instead of just reading from a file. Those network IO calls are often blocking-style, too. You definitely don't want to stop the UI thread from responding to inputs or updating the screen while you go do that kind of thing. So, you need to put all your IO on a non-UI thread. That means you have to communicate across threads, which means thread-safe data structures with locks, etc. The code ends up a bit more complicated.

    Non-blocking APIs look more like "start reading this file and call this other function when you're done, but return immediately". Your code ends up being structured differently, since everything is an event. Once you're used to it, it's pretty nice. Closures and lambdas make everything really simple, so your code even starts to look more like the linear/blocking style. So, if you do need an HTTP server in your app, it just looks like a few IO event handlers that you set up along with all your UI event handlers. Putting it on your UI thread is a judgment call at that point. You can make sure the HTTP event handlers never take enough time to impact usability, and in return you get to avoid having to deal with inter-thread communication, etc. Or, you can go ahead and create a thread and give it its own event loop to run the exact same non-blocking style code. I've done it both ways, and couldn't tell the difference in the UI (this was on an old iPhone 3GS back in the day).