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!!!
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
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 remember those on-stage demos and seeing them repeated on one of the local tech TV shows. The big gains were on a few filters (one was lens flare) which were optimized for the PPC architecture. The difference on the optimized filters was stark, but the rest of the comparisons were pretty...comparable.
But tech is a horse race...without a finish line. Intel's MMX came out, and that was that.
No, wrong. Android uses more threads than I-os because the Linux scheduler is a lot more efficient than the Mach scheduler. On Linux there usually is no benefit to writing complex, fragile non-blocking code just to avoid the scheduler, only drawbacks. So with threads you get to have nice clean code and high performance too. On Linux.
I use Grand Central Dispatch, and you can stick your Linux threads wherever you prefer them.