SoC Analysis: CPU Performance

Now that we’ve had a chance to take a look at A9X’s design and a bit on the difference between the x86 and ARM ISAs, let’s take a look at A9X’s performance at a lower level.

From a CPU perspective A9X is just a higher clocked implementation of the dual-core Twister CPU design we first saw on A9 last year. As a result the fundamentals of the CPU architecture have not changed relative to A9. However A9X relative to A8X drops down from three CPU cores to two, so among the factors we’ll want to look at is how Apple has been impacted by dropping down to two faster cores.

We’ll start things off with Geekbench, 3, which gives us a fairly low-level look at CPU performance.

Geekbench 3 - Integer Performance
  A9X A8X % Advantage
AES ST
1.17 GB/s
0.98 GB/s
19%
AES MT
2.85 GB/s
3.16 GB/s
-10%
Twofish ST
120.7 MB/s
64.0 MB/s
89%
Twofish MT
228.3 MB/s
182.7 MB/s
25%
SHA1 ST
1.03 GB/s
0.53 GB/s
94%
SHA1 MT
1.95 GB/s
1.48 GB/s
32%
SHA2 ST
205.8 MB/s
119.1 MB/s
73%
SHA2 MT
395.5 MB/s
330.6 MB/s
20%
BZip2Comp ST
8.95 MB/s
5.71 MB/s
57%
BZip2Comp MT
17.0 MB/s
16.6 MB/s
2%
Bzip2Decomp ST
14.7 MB/s
8.98 MB/s
64%
Bzip2Decomp MT
28.1 MB/s
25.2 MB/s
12%
JPG Comp ST
33.7 MP/s
20.6 MP/s
64%
JPG Comp MT
64.4 MP/s
60.8 MP/s
6%
JPG Decomp ST
89.2 MP/s
53.0 MP/s
68%
JPG Decomp MT
166.5 MP/s
153.9 MP/s
8%
PNG Comp ST
2.11 MP/s
1.35 MP/s
56%
PNG Comp MT
4.04 MP/s
3.82 MP/s
6%
PNG Decomp ST
31.5 MP/s
18.7 MP/s
68%
PNG Decomp MT
56.9 MP/s
56.3 MP/s
1%
Sobel ST
138.3 MP/s
82.5 MP/s
68%
Sobel MT
258.7 MP/s
225.6 MP/s
15%
Lua ST
3.25 MB/s
1.68 MB/s
93%
Lua MT
6.02 MB/s
4.60 MB/s
31%
Dijkstra ST
10.1 Mpairs/s
6.70 Mpairs/s
51%
Dijkstra MT
17.6 Mpairs/s
16.0 Mpairs/s
10%

The interesting thing about Geekbench is that as a result of being a lower-level test the bulk of its tests scale up well with CPU core counts, as the benchmark can just spawn more threads. Consequently I wasn’t entirely sure what to expect here, as this presents the tri-core A8X with a much better than average scaling opportunity, making it especially harsh on the A9X.

But what the results show us is that even by dropping back down to two CPU cores, A9X does very well overall. The single-threaded results are greatly improved, with A9X offering better than a 50% single-threaded perf gain in the majority of the sub-tests. Meanwhile even with the multi-threaded tests, A9X only loses once, on AES. Otherwise two higher clocked Twister cores are beating three lower clocked Typhoon cores by anywhere between a few percent up to 32%. In this sense Geekbench is something of a worst-case scenario, as real-world software rarely benefits from additional cores this well (this being part of the reason why A8 and A9 did so well relative to quad Cortex-A57 designs), so it’s promising to see that even in this worst-case scenario A9X can deliver meaningful performance gains over A8X.

Geekbench 3 - Floating Point Performance
  A9X A8X % Advantage
BlackScholes ST
14.9 Mnodes/s
8.52 Mnodes/s
75%
BlackScholes MT
28.2 Mnodes/s
24.9 Mnodes/s
13%
Mandelbrot ST
2.23 GFLOPS
1.27 GFLOPS
76%
Mandelbrot MT
4.27 GFLOPS
3.66 GFLOPS
17%
Sharpen Filter ST
2.10 GFLOPS
1.08 GFLOPS
94%
Sharpen Filter MT
4.01 GFLOPS
3.12 GFLOPS
29%
Blur Filter ST
2.68 GFLOPS
1.53 GFLOPS
75%
Blur Filter MT
5.08 GFLOPS
4.47 GFLOPS
14%
SGEMM ST
6.77 GFLOPS
4.12 GFLOPS
64%
SGEMM MT
12.7 GFLOPS
11.6 GFLOPS
9%
DGEMM ST
3.32 GFLOPS
2.02 GFLOPS
64%
DGEMM MT
6.21 GFLOPS
5.61 GFLOPS
11%
SFFT ST
3.52 GFLOPS
1.92 GFLOPS
83%
SFFT MT
6.67 GFLOPS
5.40 GFLOPS
24%
DFFT ST
3.21 GFLOPS
1.80 GFLOPS
78%
DFFT MT
6.02 GFLOPS
5.11 GFLOPS
18%
N-Body ST
1.41 Mpairs/s
0.78 Mpairs/s
81%
N-Body MT
2.69 Mpairs/s
2.34 Mpairs/s
15%
Ray Trace ST
4.99 MP/s
2.96 MP/s
69%
Ray Trace MT
9.56 MP/s
8.64 MP/s
11%

The story with Geekbench 3 floating point performance is much the same. Performance never regresses, even in multi-threaded workloads. In lightly threaded floating point workloads A9X is going to walk all over A8X, and in multi-threaded workloads we’re still looking at anywhere between a 9% and a 29% performance gain. This goes to show just how powerful Twister is relative to Typhoon, especially with A9X’s much higher clockspeeds factored in. And it lends a lot of support to Apple’s ongoing design philosophy of favoring a smaller number of high performance (and now higher-clocked) cores.

SPEC CPU 2006

Moving on, our other lower-level benchmark for this review is SPECint2006. Developed by the Standard Performance Evaluation Corporation, SPECint2006 is the integer component of their larger SPEC CPU 2006 benchmark. As was the case with SPEC CPU 2000 before it, SPEC CPU 2006 is designed by a committee of technology firms to offer a consistent and meaningful cross-platform benchmark that can compare systems of different performance levels and architectures. Among cross-platform benchmarks SPEC CPU is generally held in high regard, and while it is but one collection of benchmarks and like all benchmarks should not be taken as the be-all end-all of benchmarks on its own, it provides us with a very important look at CPU performance that we otherwise cannot get.

SPECint2006 is the successor to the SPECint2000 test we’ve been using periodically for the last couple of years now. Initially released in 2006, SPECint2006 is still SPEC’s current-generation CPU integer benchmark. We’ve wanted to switch to SPECint2006 for some time now, but have been held back by the overall low performance of tablet SoCs, which lacked the speed and memory to run SPECint2006 and to do so in a reasonable amount of time. However now thanks to the greater performance and greater memory of A9X, we’re finally able to run SPEC’s current-generation CPU benchmark on a tablet.

SPECint2006 is composed of 12 sub-benchmarks, testing a wide variety of scenarios from video compression to PERL execution to AI. This is a non-graphical benchmark and I believe it’s reasonable to argue that the benchmark set itself leans towards server high performance computing/workstation use cases, but with that said even if it’s not a perfect fit for tablet use cases it offers a lot of real-world tests that give us a good variety of different workloads to benchmark CPUs with. SPECint2006 scores are in turn reported as a ratio, measuring how many times faster a tested system is against the SPEC reference system, a 1997 Sun Ultrasparc Ultra Enterprise 2 server, which is based around a 296 MHz UltraSPARC II CPU.

CINT2006 (Integer Component of SPEC CPU2006):
Benchmark Language Application Area Description
400.perlbench
Programming Language  Derived from Perl V5.8.7. The workload includes SpamAssassin, MHonArc (an email indexer), and specdiff (SPEC's tool that checks benchmark outputs).
401.bzip2
Compression  Julian Seward's bzip2 version 1.0.3, modified to do most work in memory, rather than doing I/O.
403.gcc
C Compiler  Based on gcc Version 3.2, generates code for Opteron.
429.mcf
Combinatorial Optimization  Vehicle scheduling. Uses a network simplex algorithm (which is also used in commercial products) to schedule public transport.
445.gobmk
Artificial Intelligence: Go  Plays the game of Go, a simply described but deeply complex game.
456.hmmer
Search Gene Sequence  Protein sequence analysis using profile hidden Markov models (profile HMMs)
458.sjeng
Artificial Intelligence: chess  A highly-ranked chess program that also plays several chess variants.
462.libquantum
C
Physics / Quantum Computing Simulates a quantum computer, running Shor's polynomial-time factorization algorithm.
464.h264ref
Video Compression  A reference implementation of H.264/AVC, encodes a videostream using 2 parameter sets. The H.264/AVC standard is expected to replace MPEG2
471.omnetpp
C++ 
Discrete Event Simulation  Uses the OMNet++ discrete event simulator to model a large Ethernet campus network.
473.astar
C++ 
Path-finding Algorithms  Pathfinding library for 2D maps, including the well known A* algorithm.
483.xalancbmk
C++ 
XML Processing  A modified version of Xalan-C++, which transforms XML documents to other document types.

Although designed as a CPU-intensive benchmark, it’s important to note that SPECint2006 is officially labeled as “stressing a system's processor, memory subsystem and compiler.” The memory subsystem aspect is fairly self-explanatory – it’s difficult to test a CPU without testing the memory as well except in the cases of trivial workloads that can fit in a CPU’s caches – however the compiler aspect calls for special attention. As SPECint2006 is a cross-platform benchmark in the truest sense of the word, it’s impossible to offer a single binary for all platforms – especially platforms that had yet to be designed in 2006 such as ARMv8 – and, simply put, the moment you begin compiling benchmarks for different systems using different compilers, the performance of the compiler becomes a factor of benchmark performance as well.

As a result, and unlike many of the other benchmarks we run here, it’s important to note that compilers play a big part in SPECint2006 performance, and this is by design. Compiler authors can and do optimize for SPEC CPU, with the ultimate goal of giving the tested CPU the best chance to achieve the best possible performance in this benchmark; the compiler should not hold back the CPU. However in turn, all results must be validated, so overly aggressive compilers that generate bad code will be caught and failed. The end result is that in a cross-platform scenario with different binaries, SPECint2006 isn’t quite as apples-to-apples as our more traditional benchmarks, but it offers us a unique look at cross-platform CPU performance.

For our testing we’re using optimized binaries generated for Apple’s A8X/A9X SoCs and Intel’s Broadwell/Skylake processors respectively. The following compiler flags were used.

Apple ARMv8: XCode 7 (LLVM), -Ofast

Intel x86: Intel C++ Compiler 16, -xCORE-AVX2 -ipo -mdynamic-no-pic -O3 -no-prec-div -fp-model fast=2 -m32 -opt-prefetch -ansi-alias -stdlib=libstdc++

Finally, of SPECint2006’s 12 sub-benchmarks, our current harness is only able to run 10 of them on the iPad Pro at this time, as 473.astar and 483.xalancbmk are failing on the iPad. So the following is not a complete run of SPECint2006, and for the purposes of SPEC CPU are officially classified as performance estimates.

To start things off, let’s look at the Apple-to-Apple comparison, pitting A9X against A8X.

SPECint_base2006 - Estimated Scores - A9X vs. A8X
  A9X A8X A9X vs. A8X %
400.perlbench
25.0
14.1
78%
401.bzip2
17.6
11.5
54%
403.gcc
20.5
12.4
65%
429.mcf
18.7
N/A
N/A
445.gobmk
23.4
13.0
80%
456.hmmer
25.1
14.1
79%
458.sjeng
23.6
13.6
73%
462.libquantum
74.6
49.2
52%
464.h264ref
41.3
24.0
72%
471.omnetpp
10.3
8.0
29%

Unsurprisingly, A9X is leaps and bounds ahead here. The smallest gain is with 471.omnetpp, a discrete event simulator, where A9X holds a 29% lead. Otherwise A9X takes a significant lead, beating A8X by upwards of 80% in 445.gobmk, a Go (board game) AI benchmark.

Calling back to our iPhone 6s review for a moment, A9X has a much larger advantage vs. A8X with SPECint2006 as compared to A9 vs. A8 on SPECint2000. A good deal of this has to do with A9X’s significant clockspeed bump versus A8X, but at the same time this also illustrates how the newer SPECint2006 rates A9X and Twister even more highly than A8X/Typhoon. As we’ve seen time and time again, Twister is a much faster CPU core than the already fast Typhoon, and this is a big part of why Apple continues to top our ARM benchmarks.

Last but certainly not least however is our main event, A9X versus Intel’s Core M CPUs. As we’re finally able to run SPECint2006 on an Apple SoC, this is the first chance we’ve had to compare Apple and Intel CPUs using SPEC, so it’s exciting to finally be able to make this comparison.

At the same time this comparison not just for academic curiosity; as Apple has significantly improved their CPU design with every generation and has quickly moved to newer manufacturing processes, they have been closing the architecture and manufacturing gap with Intel. Twister and Skylake are fairly similar designs, both implementing a wide execution pipeline with a focus on achieving a high IPC, and in this latest generation of devices, coupling that with a fairly high 2GHz+ clockspeed. Over the years Apple and Intel have approached this problem from different angles – Apple built up from phones to tablets while Intel built down from desktops to tablets – but the end result is that the two have ended up in a similar place in terms of basic architecture design goals. Meanwhile from a manufacturing standpoint Intel is arguably still roughly a generation ahead with their 14nm FinFET process – naming aside, their transistors are smaller than TSMC’s 16nm FinFET – so Apple is the underdog from this point of view.

The burning question is of course is whether Apple’s CPU designs are catching up to the performance of Intel’s Core lineup, thanks to the continual iteration of architecture and manufacturing on the Apple side, versus the slower rate of growth we’ve seen over the last few generations with Intel’s Core lineup. The iPad Pro in turn finally gives us the opportunity to try to answer that question, as the faster SoC coupled with a form factor and TDP closer to regular Core M devices gives us the most apples-to-apples comparison yet.

To that end we have assembled a smorgasbord of Core M devices to compare to the iPad Pro and A9X SoC. Perhaps the most apple-to-apple comparison is the iPad Pro versus the 2015 MacBook; though approaching a year old, this is still Apple’s current generation MacBook, with our base model incorporating an older Broadwell-based Core M-5Y31. Also from the Broadwell generation we have an ASUS Transformer Book T300 Chi, which uses a high-end Core M-5Y71, to showcase the performance of Intel’s highest clocked Core M processors. Finally, from the latest Skylake generation we have the ASUS ZenBook UX305CA, which incorporates Intel’s base-tier Core m3-6Y30 CPU.

Finally, it should be noted that to keep testing as close as possible, all of these devices are passively cooled, and that as a result all of these devices are also TDP/heat throttling though much of the SPECint2006 benchmark. Ultimately what we’re measuring here is not the peak performance of each system, but rather its sustained performance under the TDP limitations of their respective designs. If unrestricted, undoubtedly all of these devices would score higher.

SPECint_base2006 - Estimated Scores - A9X vs. Intel Broadwell/Skylake
  A9X Core M-5Y31
(2015 MacBook)
Core M-5Y71
(Asus T300 Chi)
Core m3-6Y30
(Asus UX305CA)
A9X vs MacBook %
Base/Turbo Freq 2.26GHz 0.9/2.4GHz 1.2/2.9GHz 0.9/2.2GHz  
400.perlbench
25.0
21.7
28.5
24.4
15%
401.bzip2
17.6
14.6
19.6
15.3
21%
403.gcc
20.5
22.8
31.1
28.2
-10%
429.mcf
18.7
35.9
46.7
38
-48%
445.gobmk
23.4
16.9
23.7
18
38%
456.hmmer
25.1
43.9
61.9
48.1
-43%
458.sjeng
23.6
19.2
26.1
19.3
23%
462.libquantum
74.6
292
476
409
-74%
464.h264ref
41.3
38.4
49.7
37.3
8%
471.omnetpp
10.3
16.3
23.7
20.6
-37%

As this is a fairly dense lineup I’m not going to call out every figure, but let’s focus on a few key areas. First, on A9X versus the Core M-5Y31 (MacBook), the advantage flips between each device as each test hits upon different strengths and weaknesses of each CPU’s architecture. Overall each device wins half of the benchmarks, however the Core M powered MacBook wins by a larger average margin. In other words, the iPad Pro is competitive with the MacBook depending on the test, however on average it ends up trailing in performance.

Relative to the MacBook, the iPad Pro does best in 445.gobmk, the Go benchmark, while its largest deficit is with 462.libquantum. The latter is a particularly interesting case as the benchmark is very easy to vectorize, giving us perhaps our best look at the vector performance of Twister versus Broadwell, and how well their respective compilers can actually vectorize it. The end result has the Intel platforms solidly in the lead here, hinting that Intel still has better vector performance at this time.

Shifting gears to the Asus ZenBook UX305CA and its newer Skylake based Core m3-6Y30, to little surprise Skylake closes the gap with A9X in the benchmarks where Core M was losing, and pulls further ahead in the benchmarks where it was winning. Despite this the two systems split the number of wins at 5 each, but in the cases where the ZenBook is winning it’s very clearly winning. Overall Skylake sees some decent performance improvements relative to the Broadwell CPU in our MacBook – with the exact gains depending on the test – allowing it to widen the gap compared to the A9X. Overall A9X is still competitive in specific scenarios, but on average it definitely trails the Skylake Core m3.

Finally, going back to Broadwell we have the ASUS Transformer Book T300 Chi, which incorporates a high-end Core M-5Y71 processor. This is still officially a 4.5W TDP processor, and as a result this essentially measures Broadwell Core M’s best case performance. With a maximum CPU clockspeed of 2.9GHz as compared to the slower low-end Skylake and Broadwell CPUs, the T300 Chi unsurprisingly beats the iPad Pro in every single benchmark. At best the two are neck-and-neck with Apple’s best benchmark, 445.gobmk, but otherwise it’s a clear and very significant lead for Intel’s fastest Broadwell Core M processor.

In the end, what to take away from this depends on how you want to read the results and what you believe the most important CPU comparison is. As Apple doesn’t use multiple bins/clockspeeds of A9X processors, this muddles the comparison some since there’s a significant difference in performance between Intel’s fastest and slowest Core M processors, and at the same time Intel’s official list prices put every CPU except the top-bin Core m7-6Y75 at the same price of $281.

Ultimately I think it’s reasonable to say that Intel’s Core M processors hold a CPU performance edge over iPad Pro and the A9X SoC. Against Intel’s slowest chips A9X is competitive, but as it stands A9X can’t keep up with the faster chips. However by the same metric there’s no question that Apple is closing the gap; A9X can compete with both Broadwell and Skylake Core M processors, and that’s something Apple couldn’t claim even a generation ago. That it’s only against the likes of Core m3 means that Apple still has a way to go, particularly as A9X still loses by more than it wins, but it’s significant progress in a short period of time. And I’ll wager that it’s closer than Intel would like to be, especially if Apple puts A9X into a cheaper iPad Air in the future.

SoC Analysis: On x86 vs ARMv8 System Performance
Comments Locked

408 Comments

View All Comments

  • ddriver - Saturday, January 23, 2016 - link

    So in your expert opinion, all programs do is syscalls? No application logic, no application data? LOL

    Also, API calls are NOT syscalls. Syscalls are requests to OS kernel, API calls are just regular calls to a library. Fundamentally different things.
  • FunBunny2 - Saturday, January 23, 2016 - link

    -- Fundamentally different things.

    exactly the same: your not writing active code, but calling out to somebody else's code to do the work. in neither case does it matter what you're source language is, from a performance point of view. there's a reason that java mostly beats C++ these days.
  • Constructor - Saturday, January 23, 2016 - link

    The main reason for that is the "well, it's fast enough, and if not we'll compensate with CPU upgrades" mentality in many projects.
  • gistya - Sunday, January 24, 2016 - link

    Why are we talking about Java and C++ here? Just curious.

    I recently worked on Google's j2objc project and it's pretty freaking slick. You can translate Java code into Objective C that compiles and runs pretty flawlesly on an iOS device, and it's fast. It's not emulated, it's actually a port of Android's core libs right into Objective C. Amazing work.

    I started working with Swift recently and it's pretty cool itself. Apple's answer to C# and Java, basically. I like that they released it free and open source for Linux. It's weird to program in until you get used to the weird memory management stuff but, hey, code runs so much faster without garbage collection.
  • ddriver - Sunday, January 24, 2016 - link

    Objective C is an atrocity. Moving away from it in favor of swift is one of the few moves apple can be commended for.

    Apple have taken advantage of native code, which has resulted in better user experience than android, even when their hardware was mediocre. Because native code is way better than java.
  • Relic74 - Saturday, February 27, 2016 - link

    Developing apps that take advantage of the iPad Pro's hardware is just the tip of the iceberg. iOS needs a complete overhaul as in it's current state it's lacking just to many features to be considered anything approaching a Pro OS.

    The iPad Pro is my first iOS device, I've played with them over them years but I never really liked iOS, it just always felt extremely restrictive to me. When the Pro came out with iOS 9.2 I was intrigued and started to read up on it, the reviews were solid and everyone I talked to who owned one, really liked them. So I made the plunge and bought one for myself. Now I already have a tablet, the new Pixel C in which I really like, even though the reviews on that haven't been so super. The biggest complaint was that Android isn't really a productivity OS. I found it to be quite the opposite, it's an extremely capable machine. So when I read that the iPad Pro is pretty decent on productivity tasks, I thought well if they thought the Pixel C wasn't up for the task and it is, than the iPad Pro must be something special.

    It's not, every reason why I avoided iOS all of these years is still present in the latest version, every single one. As I use CodeEnvy, a cloud based IDE to do most of my programming, I assumed the iPad Pro would be able to handle to handle my work flow. It's nothing outrageous what I'm doing or expect, simply using the CodeEnvy app, Prompt 2 (a terminal app) and Chrome. I also needed Excel to calculate trade PNL's. Within the first hour of using the iPad Pro it was more than apparent that it just wasn't meant for productivity work or at least nothing on the level that I required and didn't come lose to the Pixel C's abilities.

    First, I needed to run the terminal app in the background, compiling apps can take a while, plus I run scripts and monitoring applications. However after 3 minutes iOS would terminate it's connections. After some research it seems only about 1% of the apps in the App Store can actually run in the background for extended periods of time, mostly GPS and music apps. Than their was the problem with app resolutions, more than 80% of them I had installed didn't support the iPad Pro's resolution. So again after some research it seems only about 10% of the apps available actually support it's resolution, these unsupported apps also use another keyboard, one that is extremely basic and missing many of the features of the systems default. Now, app developers are working on this problem but the real problem, which is that apps in iOS are resolution independent in the first place just isn't a good idea. However it seems that their is no other way to do it because of this so called Walled Garden Paradigm.

    Apps in iOS are basically islands and in some weird way are even like OS's themselves, they basically have to fend for themselves With little contact to actual system except through hacks, okay, API's but it sure sounds like a hack to me. So every time a new feature is added to iOS app developers have to manually update their code to support it. Which brings me to the next issue, dual app view, only about 120 apps or so support it, again, we have to wait for the app developers. Now I'm not saying Android is the better option for any of you, it's all about preferences but when I enabled the dual app view feature in Android 6.0, every app from that moment on supported it. Further, every app I have installed into my Pixel C supported it's resolutions. When I connect a monitor to it, everything is supported, resolution, aspect ratio, I can even change the DPI to make it look more like a proper desktop UI and it supports extending the desktop, not just mirroring. Since the Pixel C has a USB C, I'm using the same port-replicator I bought for my MacBook 12" which has, HDMI, SD Card reader, 2 USB 3, mini USB and Ethernet, connecting a display to the Pixel C couldn't be easier. When I connected my monitor to the iPad Pro it looked like complete crap, black bars, the DPI was so large it looked like a child's toy and it just supported mirroring which absolutely sucks because you can't have two monitors.

    File system or should I say lack of because except for iCloud, iOS doesn't have one, it depends on it's apps to manage them. This is absolutely ridiculous and frankly Apple should be ashamed of themselves for leaving it this way for the last 8 years. Dealing with files in iOS is a complete nightmare. Every time I grab a file from the cloud I end up creating at least 4 copies of the same files because when you send a file to an app, it sends a copy, leaving the original in the app your sharing from. So keeping track of which file is the latest version is impossible. Why am I sharing in the first place, on every single mobile device I've ever used, the sharing feature was used to send content to an online source, never was it used as a method to manage files, especially not as the primary method. Also I have yet to have seen an app that can Share to every compatible app installed, their always missing apps in the share list, why because unlike Android which creates it's Share lists dynamically on a system level, the app developers for iOS apps have to manually create a Share profile, which means apps can pick and choose which apps they want to support. When you install the DropBox client, every app that can create a file from that time on should be able to Share to it, period. Instead we have to wait for the app developers for everything in iOS. People say that Android is fragmented, fine but so is iOS, except in it's case, it's the apps that are fragmented. Anytime a new feature is added, every app should automatically be able to do it because the system manages it, not the apps.

    The keyboard, I first bought the Apple keyboard, however I really didn't like the way it felt to type on, I missed having the function keys and the biggest issue, no backlite, something I simply cannot live with out as I type at night in bed a lot. It also doesn't provide any protection so I had to buy the hard case, 200 bucks + for a mediocre keyboard. So I bought the Logitech, a much, much better typing experience however there is one problem that became hugely apparent while using it. I wanted a mouse, not every time, just when the keyboard was connected. Why, well like Tim Cook said about notebooks with touchscreen's being a failed idea mostly do to poor ergonomics, the user has to constantly reach up to navigate the UI (get's old real quick), the iPad Pro, ironically, falls under the same category. Foot in mouth next time Tim, I'm sure you didn't realize at the moment that you were also talking about the iPad Pro but it's the same exact thing.

    The Pencil, I'm not an artist so I can't really say if it's good or not. The one thing I do know is that I can't use it throughout the system. Something I desperately wanted to do, so in the drawer it went, instead I use a Wacom, has pressure sensitivity, palm rejection and writes great, no lag. In fact I can't tell the difference between the two when using apps like EverNote, Bamboo Paper, OneNote, etc. the iPad Pro is a finger print magnet, I just wanted a stylus to navigate the UI with, also without a mouse the Wacom is the closest thing I can get, works a lot better with it than without when using the keyboard, that's for sure. Is there an actual Apple device available without compromises, there is absolute zero excuse for not allowing the Pencil to function throughout the system. This idea that the iPad Pro is a touch device only completely fell apart the second Apple made the Pencil and keyboard, two accessories that break this touch only paradigm. The only reason why Apple is doing this is to save a little face from all these years of saying the stylus is garbage. This is also why I'm pissed that Pro doesn't have mouse support. The OS certainly supports it by the way, my brother has an iPad Air 2 which is JailBroken and he installed mouse drivers just fine, works great.

    There is potential here, however even with great apps the blatant problems in iOS prohibit it from ever becoming a proper productivity tool. Now I fully realize that there are plenty of people that get by just fine with using the iPad Pro, I'm just not one of them. The Pixel C is a much more capable machine for what I do, I have every app that I need which by the way are the same exact apps I had installed on the iPad Pro so I don't get this, no apps for Android tablets thing, I have over 60 apps, all of them look and perform great. In fact, they actually look better on the Pixel C because they all support it's resolution. I have a stylus, the same Wacom. I use for the iPad Pro. I have an actual file-manager with all of my files in a single area, organized by folders. I can access my firms secure NAS drive using Open ID, I have all of my cloud storage, other computers, external HD's and FTP servers mounted as local assets, so when I click on save, the file is saved directly on whichever remote storage I choose. None of that, click on Share BS. When I'm editing a file and need to use more than one app, each app uses the same exact file, no creation of multiple files from Sharing, just open, edit, save, go to other app, open, edit, save. I can find any file in less than a minute, I can find every file that contains a persons name inside of the files In less than a minute. I tried to do this in iOS, I just gave up, finding files in iOS is like trying to find Noah's Ark in Turkey. Zipping and sending files in iOS, well, just also sucks, hopefully the files your sending aren't located in more than 2 apps. I use the Pixel C as a desktop computer as it has mouse support and looks great when connect to a monitor with extending desktop capabilities. Since I can run Linux desktop applications and quickly mind you, it actually makes for a decent desktop machine, however I just purchased an Nvidia Shield TV, installed Arch Linux on it and am now using that as my desktop computer. The performance of the Pixel C was so good when running Linux apps that the Shield TV was a no brainier. Yes, there are GPU drivers for it, in fact my CUDA applications work great on it. I can encode a video file using the GPU to compute faster than most laptops using their CPU's.

    Write now I am compiling an app in the background, while downloading a 20GB .rar file to a connected HD, while streaming a movie directly from OneDrive without having to download it first, to my sons TV in his room, I have Gimp running on my monitor as I was editing a picture, (I'm running Arch Linux in a Chroot under Android, to use applications I just start them up through an X-Terminal, works great), while I'm typing this up in Chrome on the Pixel C itself. The iPad Pro doesn't come close to that level of multitasking, running two apps in a split screen view is a nice feature however I would give it up in heart beat to be able to run any and all apps in the background.

    I'll end it here, the iPad Pro is still just an iPad, it's not a laptop replacement, it's not a productivity machine, it's an iPad. A content consumption device, just with a larger display. Those wanting one, wait, at least until version 2 comes out. There are just tom any issues that need to be worked out and most importantly, no apps that really take advantage of it.
  • boozed - Friday, January 22, 2016 - link

    MaxiPad, surely.
  • definitelyReal - Friday, January 22, 2016 - link

    Lol
  • xerandin - Saturday, January 23, 2016 - link

    You win this comments section. Not really worth much, but it's better than the guys in here defending a product that has left most of everyone everywhere completely nonplussed.
  • Constructor - Saturday, January 23, 2016 - link

    Ideologue, much?

    I've simply bought it because I wanted to use it, and I do. Every single day. And it is fantastic.

    If you're "nonplussed" by it, you're likely asking the wrong questions to begin with.

Log in

Don't have an account? Sign up now