The Apple iPad Pro Review
by Ryan Smith, Joshua Ho & Brandon Chester on January 22, 2016 8:10 AM ESTSoC Analysis: On x86 vs ARMv8
Before we get to the benchmarks, I want to spend a bit of time talking about the impact of CPU architectures at a middle degree of technical depth. At a high level, there are a number of peripheral issues when it comes to comparing these two SoCs, such as the quality of their fixed-function blocks. But when you look at what consumes the vast majority of the power, it turns out that the CPU is competing with things like the modem/RF front-end and GPU.
x86-64 ISA registers
Probably the easiest place to start when we’re comparing things like Skylake and Twister is the ISA (instruction set architecture). This subject alone is probably worthy of an article, but the short version for those that aren't really familiar with this topic is that an ISA defines how a processor should behave in response to certain instructions, and how these instructions should be encoded. For example, if you were to add two integers together in the EAX and EDX registers, x86-32 dictates that this would be equivalent to 01d0 in hexadecimal. In response to this instruction, the CPU would add whatever value that was in the EDX register to the value in the EAX register and leave the result in the EDX register.
ARMv8 A64 ISA Registers
The fundamental difference between x86 and ARM is that x86 is a relatively complex ISA, while ARM is relatively simple by comparison. One key difference is that ARM dictates that every instruction is a fixed number of bits. In the case of ARMv8-A and ARMv7-A, all instructions are 32-bits long unless you're in thumb mode, which means that all instructions are 16-bit long, but the same sort of trade-offs that come from a fixed length instruction encoding still apply. Thumb-2 is a variable length ISA, so in some sense the same trade-offs apply. It’s important to make a distinction between instruction and data here, because even though AArch64 uses 32-bit instructions the register width is 64 bits, which is what determines things like how much memory can be addressed and the range of values that a single register can hold. By comparison, Intel’s x86 ISA has variable length instructions. In both x86-32 and x86-64/AMD64, each instruction can range anywhere from 8 to 120 bits long depending upon how the instruction is encoded.
At this point, it might be evident that on the implementation side of things, a decoder for x86 instructions is going to be more complex. For a CPU implementing the ARM ISA, because the instructions are of a fixed length the decoder simply reads instructions 2 or 4 bytes at a time. On the other hand, a CPU implementing the x86 ISA would have to determine how many bytes to pull in at a time for an instruction based upon the preceding bytes.
A57 Front-End Decode, Note the lack of uop cache
While it might sound like the x86 ISA is just clearly at a disadvantage here, it’s important to avoid oversimplifying the problem. Although the decoder of an ARM CPU already knows how many bytes it needs to pull in at a time, this inherently means that unless all 2 or 4 bytes of the instruction are used, each instruction contains wasted bits. While it may not seem like a big deal to “waste” a byte here and there, this can actually become a significant bottleneck in how quickly instructions can get from the L1 instruction cache to the front-end instruction decoder of the CPU. The major issue here is that due to RC delay in the metal wire interconnects of a chip, increasing the size of an instruction cache inherently increases the number of cycles that it takes for an instruction to get from the L1 cache to the instruction decoder on the CPU. If a cache doesn’t have the instruction that you need, it could take hundreds of cycles for it to arrive from main memory.
Of course, there are other issues worth considering. For example, in the case of x86, the instructions themselves can be incredibly complex. One of the simplest cases of this is just some cases of the add instruction, where you can have either a source or destination be in memory, although both source and destination cannot be in memory. An example of this might be addq (%rax,%rbx,2), %rdx, which could take 5 CPU cycles to happen in something like Skylake. Of course, pipelining and other tricks can make the throughput of such instructions much higher but that's another topic that can't be properly addressed within the scope of this article.
By comparison, the ARM ISA has no direct equivalent to this instruction. Looking at our example of an add instruction, ARM would require a load instruction before the add instruction. This has two notable implications. The first is that this once again is an advantage for an x86 CPU in terms of instruction density because fewer bits are needed to express a single instruction. The second is that for a “pure” CISC CPU you now have a barrier for a number of performance and power optimizations as any instruction dependent upon the result from the current instruction wouldn’t be able to be pipelined or executed in parallel.
The final issue here is that x86 just has an enormous number of instructions that have to be supported due to backwards compatibility. Part of the reason why x86 became so dominant in the market was that code compiled for the original Intel 8086 would work with any future x86 CPU, but the original 8086 didn’t even have memory protection. As a result, all x86 CPUs made today still have to start in real mode and support the original 16-bit registers and instructions, in addition to 32-bit and 64-bit registers and instructions. Of course, to run a program in 8086 mode is a non-trivial task, but even in the x86-64 ISA it isn't unusual to see instructions that are identical to the x86-32 equivalent. By comparison, ARMv8 is designed such that you can only execute ARMv7 or AArch32 code across exception boundaries, so practically programs are only going to run one type of code or the other.
Back in the 1980s up to the 1990s, this became one of the major reasons why RISC was rapidly becoming dominant as CISC ISAs like x86 ended up creating CPUs that generally used more power and die area for the same performance. However, today ISA is basically irrelevant to the discussion due to a number of factors. The first is that beginning with the Intel Pentium Pro and AMD K5, x86 CPUs were really RISC CPU cores with microcode or some other logic to translate x86 CPU instructions to the internal RISC CPU instructions. The second is that decoding of these instructions has been increasingly optimized around only a few instructions that are commonly used by compilers, which makes the x86 ISA practically less complex than what the standard might suggest. The final change here has been that ARM and other RISC ISAs have gotten increasingly complex as well, as it became necessary to enable instructions that support floating point math, SIMD operations, CPU virtualization, and cryptography. As a result, the RISC/CISC distinction is mostly irrelevant when it comes to discussions of power efficiency and performance as microarchitecture is really the main factor at play now.
Facebook
Twitter
RSS
408 Comments
View All Comments
Constructor - Tuesday, January 26, 2016 - link
It's only by default that the Pencil can also work like a finger if the app doesn't use the extra APIs so all apps immediately work with the Pencil without having to change anything. But their developers can distinguish the Pencil if they want to.VictorBd - Tuesday, January 26, 2016 - link
@Constructor "Apple doesn't "disallow" anything!" I'll allow the broader community to debate the historical veracity of your point. I've just heard countless stories of Apple's approval / rejection process for apps for years. If Apple allows anything (by not "disallowing") as you say, all the better. Would love it to be true. It's just not been what I've been seeing and reading since the inception of the app store.My point was that, in my humble opinion, I don't believe there will never be a utility in the App Store that allows users to toggle touch off and on. This is now - for some of us - a desired feature in light of the appearance of the Apple Pencil on the market. But my estimate is that it just won't happen. You can argue that Apple won't allow it - or that too few would want it. Either way. But a small group (percentage wise) of pen tablet enthusiasts have learned to love having this capability on the Windows pen based platform. My experience with everyone who learns of it and tries it is "Wow" and once you use it, it is compelling.
I'd be ecstatic to be wrong on the idea of such an ability showing up on the Pro! I'd love to see it on the iPad Pro. We can only hope. It may convince me to buy one again and not return it. Perhaps I can overlook the limitations of using a mobile OS to do real work. Nah, probably not.
Regarding Procreate - I already said it's great that they've implemented what they have. My point about a toggle is distinct from your point about what Procreate has done. But it doesn't matter.
I'm not here to convince anyone - I was just sharing my experiences and insights.
Constructor - Tuesday, January 26, 2016 - link
@Constructor "Apple doesn't "disallow" anything!" I'll allow the broader community to debate the historical veracity of your point.This is just a bunch of nonsense. Using the special Pencil APIs is not only allowed, but even desired and encouraged. It is in no way an impediment to admission of an app to the App Store. If anything, it's an advantage!
My point was that, in my humble opinion, I don't believe there will never be a utility in the App Store that allows users to toggle touch off and on.
Of course there won't be such a switch, because that would be a really bad idea.
Among the most obvious issues with it would be that if you lost your Pencil or if it broke, you would not be able to toggle such a nonsensically global option off again – the device would be bricked, effectively! The only way around that would be some clumsy, half-baked workarounds again. Blergh!
The Pencil is excellent for drawing and for a small number of other uses, but general touch ID operation is not its forte. Trying to handle the general UI with it feels strange, it is generally slower and less intuitive and actual multi-touch is of course not supported at all.
Which leads back to the original point: The implementation in Procreate is exactly how it's supposed to be done: Both finger touch and the Pencil are supported (and at the same time!), but it's individually configurable what exactly they can be used for in this particular (drawing) app. That's the way it should be, and that also provides the maximum effectivity as well: In Procreate the distinction provides the advantages of both finger and Pencil use, not forcing the user to abandon one for the other.
Examples: Two- and three-finger-taps within the drawing area are used to signal undo and redo, respectively. Zoom is also done with two fingers. But drawing can still be restricted to the Pencil alone.
A global toggle switch would only produce additional limitations and inconveniences. it would not be a positive.
VictorBd - Tuesday, January 26, 2016 - link
To each his own.Gastec - Monday, January 25, 2016 - link
Only $1000 !? Sing me up, I'm excited to give my monthly wage to Apple.Constructor - Tuesday, January 26, 2016 - link
And who's forcing you to do that every month, if at all?Quite apart from varying incomes my iPad Pro will most likely serve me for several years. If I replace if after four years like I did with my iPad 3 (whose new owner still gets further update support from Apple) the cost per year will be around $250 or $21 per month. Most people can afford that without a problem, and many are paying more for more frequently replaced smartphones, just hidden in their pseudo-"subsidized" phone bill (which is actually just a credit payment plan plus a radio service charge).
I'm not saying that everybody should definitely get an iPad Pro (that's still a matter of needs and preferences), but given its likely useful longevity most people certainly could without breaking a sweat.
xthetenth - Monday, January 25, 2016 - link
"With the right software, I can easily see the iPad Pro completely displacing traditional note-taking in light of obvious advantages that would come with OCR and digitizing notes for easy search."This is true and has been for at least a year or two with the combination of a Surface and desktop OneNote, which does OCR, search indexing and even recording (tied to the notes so you can cue up the part of a lecture from when a particular note was made). I'd sell my spleen to send my SP4 back to myself as a college freshman.
digiguy - Monday, January 25, 2016 - link
If we just consider displacing pen and paper, while the ipad pro is lighter and larger than the SP4, but hasn't desktop Onenote, there is a much more interesting device for that, that was recently presented, the Dynapad, which is much lighter than both, but with a 12 inch screen, cheaper, and has full windows. Sure it has a CPU similar to the surface 3, rather than surface pro, but at that size and weight (lighter than even the 10.8 inches surface 3) it's the ideal device for note-taking.VictorBd - Tuesday, January 26, 2016 - link
The dynaPad (just delivered last Wednesday) provides an almost unbelievable note taking experience. Yes, the machine is underpowered, but it is worth it at this time to have a full windows 10 device that is fully loaded with production software and data - and is incredibly light and thin. It truly is the first to provide a real feel of a digital clipboard all while providing a full desktop OS. The Wacom AES pen has the best feel of anything on the market. And windows utilities allow for full control of the touch HID layer so that it can be on or off while using the pen. Simply amazing and ALL IN w pen and keyboard at $650.Can't wait to see how well Samsung's TabPro S performs in this company next month. Great times for new, light, pen-based tablets with full desktop OS's!
Fidelator - Monday, January 25, 2016 - link
The article spends a hell of a lot of time comparing this to irrelevant devices, you fail to put clear that this is the direct competition to the Surface Pro 4 of the same price tag, "I don't know why Apple decided to send a disgusting charger" come on, its cheaper.Considering the review is about getting work done why not compare its productivity to its proper competition, after all, they are charging the same price for less storage.
Windows 10 on tablets has its learning curve but after that it's a joy -most of the time, there are still rough edges, updates have been fixing those- but those are tradeoffs for the unparalleled functionality. Nothing that justifies calling the Surface a "Laptop that can double as a tablet" its actually the opposite, I'm not saying this was a bad review or that this is a bad device by any means, but I believe it to be necessary to expand on iOS's so called Pro features when compared to similarly priced devices, like, once again, The Surface Pro 4 TABLET, there is a proper tablet UI mode where you won't experience problems with small targets that need a mouse while still retaining a significant amount of productivity.
Just my 2 cents, I feel like the subject was barely touched in the final words, still, great analysis as usual, keep these up.