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.
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.
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)
The MacBook Pro prices are inflated, so the comparison between IPAD and MacBook is not that interesting.
But an ARM CPU on par with the (relatively) high end Intel Core i7!?!?!
This is big news!!!
I am betting that the benchmarks chosen were very selective and probably software bound. Not a lot of detail here.
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?
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
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.
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?
Depends on who can supply them. Apple isn't going to sell its ARM chips to competitors; and until someone makes an ARM chip that is as powerful as an x86 and can run x86 emulation well so existing programs can run out of the box, there will be little reason to dump Intel.
I'm a consultant - I convert gibberish into cash-flow.
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.
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
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).
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.).