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.

Comments

Re:Selective

[goombah99]

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.

Re:This is really news!

[amp001]

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).