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.

Too expensive for average person.

[Anonymous Coward]

The performance might be fine, but the price isn't. The iPad Pro costs as much or more than a gaming laptop. The new Mac Mini is twice as expensive as basic i3s from PC OEMs.

On top of it all, they are almost impossible for the average person to repair. You're paying top dollar just to get screwed when it breaks.

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

Re:Now if only an iPad had a real OS

[EMB Numbers]

I'm confused. iOS is OS X. I can compile the same code base for both systems with the press of a button.

There is lots of Open Source software already running on iOS:
https://github.com/dkhamsing/o...

If a full blown Unix like programming environment with full support for C and C++ isn't enough, xamarin is there and provides "Single shared codebase for Android, iOS, and Windows" available under the MIT license.
https://visualstudio.microsoft...

There is also no requirement to use Apple's App Store as long as you have physical access to a device and a free developer account. I expect most people who want to build and develop open source will probably have physical access to an iOS device if they want one.

Re:This is really news!

[amp001]

Why is that?

Java has had non-blocking IO since 1.4, which was released in 2002.

Java has had NIO for a long time. But, the Java world was pretty mature already by the time those APIs were introduced, and a ton of libraries had already been written that used threads and blocking calls, including some that were included in Android. That momentum just made it easier for Android to adopt the blocking call model for a lot of the new stuff they added. There's a bit more to it than that, if you're interested, going back to the creation of OpenBinder at Be, Inc. (& then at Palm), followed by Google hiring one it's key developers (Dianne Hackborn). Binder is how Android makes blocking calls work across processes without incurring a bunch of overhead (gross oversimplification of Binder; read up on it if you're interested in it, though – distributed objects, RPC with thread migration, etc.).