Apple's Cyclone Microarchitecture Detailed

http://www.anandtech.com/show/7910/apples-cyclone-microarchitecture-detailed

by pinaceae • 12 years ago

267 112 12 years ago

anandtech.com

glasshead9692• 12 years ago

Here is the LLVM Commit the article refers to.

https://github.com/llvm-mirror/llvm/blob/7b837d8c75f78fe55c9...

doe88• 12 years ago

And for those interested the whole commit and corresponding discussion thread on the LLVM-dev mailing list:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/thread...

https://github.com/llvm-mirror/llvm/commit/7b837d8c75f78fe55...

tdicola• 12 years ago

Very cool analysis of the new chip. If I were Intel I would be more than a little concerned about what Apple is up to here. Would be very interesting to see what Cyclone can do in a proper laptop/desktop with more RAM.

gatehouse2• 12 years ago

I'm impressed with Apple's work and it reaches all the way down to the user experience (I can play GTA San Andreas on my 5s), but the pace of Intel's research over the last 10 years has been absolutely demonic. I think for Apple to compete on that front would require an extreme investment.

For example see the second chart here: http://preshing.com/20120208/a-look-back-at-single-threaded-...

fidotron3• 12 years ago

The only reason for Intel's R&D spend over that time is that mobile chips are even more terrifying, especially once you factor in the compute capacity on the GPU.

The memory bottleneck is the real problem, but once you start getting systems conceptually related to nVidia's Tegra K1 (or even the PS4 system architecture) where the CPU is relegated to a sort of system co-ordinator Intel are going to have a major headache and find themselves in that single threaded performance niche that kept the SPARC and POWERs of the world occupied prior to their decline.

sanxiyn3• 12 years ago

I guess Apple is plucking low hanging fruits, but speedup from Apple A6 to Apple A7 (spaced almost exactly a year) is about 50% in average, which corresponds to more than 2 years of speedup in recent Intel cores. I also note that this speedup was achieved without increasing clock, which is not the case for Intel.

userbinator3• 12 years ago

I would be very interested to see some ARM results in that chart in the future; at the moment, all the RISCs there are pretty dismal.

Not so long ago I remember doing some calculations on the SPEC results, normalising them to a single thread and clock frequency to determine the per-cycle efficiency of various CPUs, and x86 came out at least a factor of 2-3x ahead of the rest.

fidotron3• 12 years ago

Apple almost certainly have a MacBook Air based on one of these chips at prototype stage.

There are many reasons in favour, including keeping negotiations with Intel over price interesting, but probably the main thing preventing them running with it would be an inability to manufacture the chips fast enough, which is a major concern in mobile land. This is why lots of Android devices exist in variations based on different chips as hedges by the device manufacturer on long term availability.

BugBrother• 12 years ago

The volumes for desktop/laptop are almost trivial compared to the volumes for handheld. (At least for Apple.) So making the processors in volume for a Macbook Air would probably not be a problem.

Also, Apple probably have little problem getting preferential treatment from manufacturers.

masklinn• 12 years ago

The volumes for desktop/laptop are almost trivial compared to the volumes for handheld. (At least for Apple.)

Yep. IIRC Apple ships something like 10 million laptops/year. They ship 3 times that in phones… every quarter

sliverstorm4• 12 years ago

I would think porting OSX to ARM would be the real hurdle? Not undoable by any means, but the lion's share of the challenge.

wiml• 12 years ago

The machine-specific parts of OSX already run on ARM in the form of iOS.

Also remember Apple has already successfully made two or three architecture transitions already: m68k to PPC to i386 to x86_64.

mcculley• 12 years ago

I wouldn't imagine porting OS X to ARM would be the hurdle as most of it is already done in that iOS is most of OS X. Apple has full control of that source code base and probably already has done this, like they did during the transition to IA-32.

It would be the third party applications that would be a hurdle. Without a transparent layer like the deprecated Rosetta, they would not be able to run existing applications and would have to explain that a new MacBook Air can't run all of the old MacBook Air applications.

Maybe if they come out with an ARM powered laptop, they will call it something other than MacBook Air to avoid that confusion.

mikeash3• 12 years ago

The real challenge will be figuring out the compatibility question for third-party software. Do you make everybody recompile before their stuff works on the new hardware? Do you ship an emulator for x86-64 for a while, like they did when they went PPC->Intel?

OS X and its predecessors have already been ported to run on a bunch of architectures: x86-64, i386, PPC64, PPC32, PA-RISC, SPARC, and Motorola 68k. All, or nearly all, of the CPU-dependent parts of the OS are the parts that are shared between OS X and iOS. Making OS X run on ARM would be trivial for Apple, and I'd be shocked if they didn't have it up and running already as a hedge.

rsynnott6• 12 years ago

Given Apple's history with this stuff, there's a very good chance that that's already done. Intel was supported internally for years before the PPC -> Intel change.

gozzoo• 12 years ago

I don't think they will go that path. It would make much more sense to introduce a desktop version of iOS itself. iOS has already everything that's needed for a light desktop OS. It would provide much better experience than ChromeOS, there are already thousands of applications doing about anything and it would require very little effort to adapt iOS to run as a desktop OS and to adapt the existing applications. I think that a hint for that is the recent port of Microsoft Office. If users want more sophisticated OS they can just use 13" MacBook Pro. It's quite easy to guess that the next version will be thinner and lighter and probably cheaper - very similar to the current MacBook Air.

coldtea• 12 years ago

They've already ported it. iOS is OSX for ARM plus different UI stuff -- all the kernel, basic userland etc are there.

So, it's mainly a matter of porting the higher level stuff -- mainly the Cocoa libs, which are slightly different on iOS vs desktop OS X.

userbinator3• 12 years ago

but the lion's share of the challenge.

This would've been the perfect phrase last year.

mx12• 12 years ago

I don't think that Apple will completely get away from x86 for a long time. Attempting to emulate the x86 on an Arm would be terribly slow.

I do however, think that they will eventually include both arm and x86 processors in the Macbook Air. That way, backwards compatibility is preserved and low power apps can run on the arm. In the current Macbook Pros they have dynamic switching of GPUs, there's no reason they couldn't use the arm as a coprocessor or even run the full OS.

Here a few technical points:

* LLVM - You can compile once for both both architecture and then the JIT will take over compiling for the specific architecture (Take a look at llvm for the OpenGL pipe line in OSX)

Full screen app- When an app is full screen (if it's a low power app) then the x86 could sleep and the arm could switch to running the app.

App nap - If all x86 apps are a sleep, switch over the running the arm processor exclusively

*Saving State - It's possible to save the state of apps in OSX, a similar mechanism could be used to seamlessly migrated between processors.

This is pure speculation, but it is feasible. There would be many technical challenges that Apple would have to solve but the a capable. The advantage Apple has is that they have absolute control over both platforms.

fidotron3• 12 years ago

That is an interesting idea.

At one point I had a machine which allowed movement of data between apps running in Windows 3.1 on a DX4 and Risc OS on a StrongARM. I'm wondering how hard it would be with OSX (a far stricter OS than Win3.1 or Risc OS) to allow a sort of process level separation, where the OS and any ARM compatible processes are running on an ARM, but you keep an x86 around and spin it up for certain processes.

legulere• 12 years ago

Nah, LLVM is to slow for JIT. However the final compilation step still could be done at install-time or link-time.

joakleaf• 12 years ago

No reason to JIT -- They already support fat binaries.

noahl2• 12 years ago

I'm skeptical about moving existing apps seamlessly between x86 and ARM processors, because you'd need guarantees about process memory layout that I don't think any current compiler makes. Imagine the memory image of a process running on the ARM chip. It has some instructions and some data:

    |        Data          |         ARM insructions        |

You could certainly remove the ARM instructions and replace them with x86 instructions. However, the ARM instructions will have hard-coded certain offsets in the data buffer, like where to look for global variables. You would have to be sure that the x86 instructions had exactly the same offsets. For another issue, if the data buffer contains any function pointers, then the x86 and ARM functions had better start at exactly the same offsets. And if there are any alignment requirements that differ between x86 and ARM (I don't know if there are), then the data had better be aligned to the less permissive standard on both chips.

None of these problems are impossible to solve. They could be solved easily by adding a layer of indirection, at the cost of some speed, and then Apple could go back and do the real difficult-but-fast implementation later.

However, why would it? When its ARM cores are essentially desktop-class, there's no need to have an x86 chip other than compatibility with legacy code. Looking at Apple's history, it seems pretty clear that it likes to have full control of its own destiny, and designing its own chips is a logical part of that, so having its own architecture could be considered a strategic move too.

So given the difficulty of implementing it well, and assuming that Apple eventually wants to have exclusively Apple-designed ARM chips in all of its products, if I were in their shoes, I wouldn't bother to make switching work. I might have a product with both kinds of chips, but I would just have the x86 chip turn on for x86 apps, and off when there were no x86 apps running, and know that eventually those apps would go away. (And because I'm Apple, I have no problem pushing vendors to switch to ARM faster than they want to, so this won't be a long transition.)

However, an even cooler move would be to make LLVM IR the official binary representation of OS X, and compile it as part of the install step of a new program. That gives Apple several neat capabilities:

1) They can optimize code for the specific microarchitecture of your computer. Maybe not a huge deal, but nice

2) They can iterate on their microarchitecture without having to care about the ISA, because the ISA is an implementation detail. This is the technically correct thing that everyone should have done years ago (yes, I'm annoyed).

3) They can keep more secrets about their chips. It's obnoxious, but Apple would probably care about that.

So, there's my transition plan for Apple to move to its own chips. It probably has many holes, but the biggest one is still the question of what Apple gains from this. Intel still has the best fabs, and as long as that's true, there will be some advantage in sticking with them. Whether the advantage is big enough, I don't know. (And when it ends in a few years, then who knows?)

zaroth• 12 years ago

  I do however, think that they will eventually include both arm and x86
  processors in the Macbook Air. That way, backwards compatibility is
  preserved and low power apps can run on the arm. In the current Macbook
  Pros they have dynamic switching of GPUs, there's no reason they couldn't
  use the arm as a coprocessor or even run the full OS.

Battery life of the Macbook Air is already outstanding. I think I want something more than just better battery life for all that complexity, but eventually it will all be just "taken care of" by the toolchain, so why not?

I think the low hanging fruit would be running iOS apps native on the Macbook Air.

klodolph• 12 years ago

I don't think that Apple will completely get away from x86 for a long time. Attempting to emulate the x86 on an Arm would be terribly slow.

It's not you're emulating an entire operating system: the operating system (and many libraries) are native, but the application code is emulated. It's faster than you think, and Apple has already done it twice: once in 1994, and once in 2005 (exercise for the reader: try extrapolating).

Apple's applications would be 100% native long before the ARM version shipped. Some intensive tasks—text rendering, audio/video/image encoding and decoding, HTML layout, JavaScript—these would also be native on third-party apps, since you just have to write the right glue into the emulator. This would be a lot easier than the 2005 switch from PowerPC to x86, which involved emulating a system with 4x as many GPRs and the opposite endian: ARM has 2x the GPRs as x86-64.

Sure, a bunch of apps will see reduced performance. Some will break. But remember: Apple has only been on x86 for ten years. We had the same problems during the PowerPC->x86 transition: you had to wait about two years to get a version of Photoshop that ran on x86 + OS X.

I'm willing to bet that Apple has been testing OS X on ARM for years now.

graetzer• 12 years ago

I don't think they would nessesarily build in both processors. They'll just assume that developers will update their apps very fast.

The whole XCode toolchain already supports x86_64 and arm64. It's trivial to build "fat" binaries with clang that run on both platforms.

_pmf_• 12 years ago

I don't think that Apple will completely get away from x86 for a long time.

The switch from PPC to x86 was less painful than many thought. I don't see any particular reason why the "fat binary" approach (which is technically gross, but quite practical) would not work for switching from x86 to ARM.

Developers will hate it, but the whole app store farce shows what Apple thinks of developers.

lallysingh• 12 years ago

If they wanted to, sure. They have all the infrastructure ("fat binaries") from the ppc switch.

sanxiyn3• 12 years ago

"Cyclone is a wide machine. It can decode, issue, execute and retire up to 6 instructions/micro-ops per clock."

This is truly amazing. In comparison, Cortex-A15 can issue 3 instructions per cycle, for example.

higherpurpose• 12 years ago

Nvidia's Denver is said to have 7. It's also rumored to have 2x the performance of Cortex A15. If it's true it could reach Sandy Bridge performance level either at first or 2nd gen (on FinFET 16nm) and Haswell/Broadwell level by 3rd gen (most people don't realize the performance between Haswell/Broadwell compared to Sandy Bridge is only like 15-20 percent, since Intel stopped focusing on performance). I also think in 2nd gen Denver SoC (2 process nodes from Tegra K1), Nvidia will have at least a 1 Tflops, possibly 1.2 Tflops GPU (Xbox One level).

ChuckMcM• 12 years ago

It is interesting that in the 'chip wars' everyone went to Intel for their chips (or Motorola) and that allowed a lot of R&D to be re-couped. But as Apple is baking their own chips, what is the market for Nvidia's Denver? It has to compete with Broadcom, Samsung, and others for a fraction of the Android device pool? Challenging to justify the levels of R&D that Apple is applying without a predictable return.

That said, I'm going to be watching for the Denver chip, it will be an interesting counter point to the A7.

ris• 12 years ago

Never believe anything about unreleased NVidia SOCs

marcosdumay• 12 years ago

Whatching those Mill presentations just spoiled me...

jpwright2• 12 years ago

Cortex A-15 can also run at nearly double the clock rate though: 2.5 GHz vs 1.4 GHz.

rsynnott6• 12 years ago

Cortex A-15 can also run at nearly double the clock rate

Cortex A-15 _does_ run at nearly double the clock rate (though with a substantially higher energy consumption on the rare occasion it actually scales up all the way). Apple is historically very conservative with its mobile device clock speeds, and I'd expect that Cyclone has a fair bit of headroom here.

userbinator3• 12 years ago

Keyword being "up to". There's a reason Intel hasn't really upped the issue width much, despite x86 having higher code density than ARM -- memory bandwidth. It's hard to keep wide execution cores saturated.

szatkus• 12 years ago

I wonder if Nvidia Denver could match with this chip.

leejoramo• 12 years ago

On balance, I think that Apple would use most of the energy savings from reducing to 20nm for other things: longer life and lower weight for the battery, improvements in the camera, wireless, increased RAM.

antimagic• 12 years ago

In the iPhone definitely. For the iPad, it already has more than adequate battery life (most people get several days use out of one before needing to recharge), so the extra clock speed could be used to handle multiple apps on-screen simultaneously (for example).

raverbashing2• 12 years ago

I am thinking that this is looking up to be what the G5 aimed to be.

Unfortunately the ARM architecture, even with those optimizations is probably slower "clock by clock" compared with x86/PPC

But yes, I think this is something Apple is probably testing (Desktop Mac OSX on ARM)

chucknelson2• 12 years ago

Pretty impressive that Apple is capable of such CPU disruption with just a few small acquisitions. Is PA Semi the main reason for this, or could Apple have been building up a CPU design team for years before that acquisition?

ddebernardy• 12 years ago

If memory serves, Cook mentioned that Apple's semiconductor division was larger than Intel during one of the last investor conference calls.

sliverstorm4• 12 years ago

What? Apple has 80,000 employees. Intel has 105,000. So I doubt any Apple division is larger than Intel, if you catch my drift.

bryanlarsen• 12 years ago

Is a $270 million acquisition a small acquisition these days? Not to mention the fact that they acquired a team responsible for two large CPU disruptions: DEC Alpha and StrongARM. A third disruption is perhaps not so surprising.

chucknelson2• 12 years ago

Just seems like billion is the new million when acquisitions are concerned, but yes, I guess it wasn't that small overall. Did not realize PA Semi was founded by a lead designer at DEC. Thanks for the info, and Wikipedia filled in the rest for me :)

rch• 12 years ago

Didn't some of the Transmeta people end up at PA Semi too?

stonemetal• 12 years ago

There's little benefit in going substantially wider than Cyclone, but there's still a ton of room to improve performance.

Didn't AMD, and Intel more or less say the same thing about 3 wide? No real benefit from going wider. Is that because of the differences in micro architecture or is it more about getting a little more performance without having to ramp the clock speed? What makes 6 wide good for ARM but not x86 or x64?

fournm• 12 years ago

This is probably completely and utterly wrong as it's just a guess, but potentially the Thumb [1] instructions (small, limited subset of shorter instructions in ARM) might allow for a wider setup. Thumb instructions make a bunch of simplifying assumptions that might remove some of the issues with going wider. Not that I have any idea if Cyclone even supports them in the first place.

[1] http://en.wikipedia.org/wiki/ARM_architecture#Thumb

wtallis• 12 years ago

The biggest wart on the ARM instruction set was the predicate attached to basically every instruction. That's gone in the 64-bit ARM ISA, so there's no need for a 64-bit Thumb (and there isn't one).

jobu2• 12 years ago

It really seems like Apple is ahead of the curve on mobile R&D. I wonder if they'll ever consider reselling some of these chips. It's unlikely Steve Jobs would've ever done it, but I'm not so sure about Tim Cook.

kevinchen2• 12 years ago

Apple bought PA Semi so they could be in charge of chip design and not have to share with anyone else. It's a competitive advantage, and Tim Cook isn't stupid. He won't license away a crown jewel for a few short-term dollars.

rsynnott6• 12 years ago

People mightn't want to buy them if they did. These chips are _big_, which means that they're expensive to make. Apple can get away with it because their only costs are manufacture and licensing, and because they have high margins which can absorb a bit of a hit. If they were selling them, though, they'd presumably want to make a profit, and that profit would make the end product almost certainly the most expensive mobile chip on the market.

From a marketing point of view, too, it'd be a hard sell in Android-land. Apple has been very careful to steer clear of spec-oriented marketing, but can you imagine the less-sophisticated enthusiast market's response to, say, the Galaxy S6 using a dual-core 1.3GHz chip instead of a quad-core 2GHz?

jobu2• 12 years ago

What about something for the server market? I know some companies have been switching to ARM chips as a low-power alternative in large server farms. It seems a 64-bit chip might be a good fit in that market.

rmrfrmrf3• 12 years ago

IMO it's unlikely. It seems like Apple has to go through a lot to meet their own manufacturing needs, so ramping up production just for third parties would put even more strain on the already-large demand.

Plus, from a market standpoint, Cyclone was developed to meet Apple's own needs. To sell these chips would introduce a "demand" variable into the equation that I think would stifle development.

At any rate, this is a really interesting topic because I think that Apple's oft-critized isolation actually worked much to its own benefit here.

NextUserName• 12 years ago

Congrats Apple for all your achievements. It is amazing what can be accomplished when you employ Chinese Engineers and manufacturers who's tech espionage (they steal trade secrets) is one of their best known traits/assets.

axman6• 12 years ago

Proof? Even informed speculation?

Apple have made several aquisitions in the last few years to give them the technology they need to make these sorts of developments. Even if some of the tech had been stolen, it would require a lot of work to put it into practice.

I know I'm feeding the troll, but I couldn't help it; this is just too ridiculous.

towski• 12 years ago

What is a tock?

stephencanon• 12 years ago

LMGTFY: http://en.wikipedia.org/wiki/Intel_Tick-Tock =)

CodeWithCoffee• 12 years ago

Apple also uses a similar strategy with the iPhone. The iPhone 4 and 5 both made major form changes (retina display and screen shape) whereas the 4S and 5S were focussed on refinement (faster CPU, 64-bit CPU respectively). It has also been noted (possibly on the Accidental Tech Podcast, or somewhere similar) that a 'tick' year for the phone tends to be a 'tock' year for iOS and vice versa; iOS 5 and iOS 7 (released with the 4S and 5S respectively) were bigger changes than iOS 4 and 6.

watersb• 12 years ago

Anand also taught us that an iPad draws about as much power as an 11-inch MacBook Air.

Configure an ARM platform with 8 GB of DDR3 DRAM and a PCIe-based SSD, and you may well blow the power budget versus the current Intel platform design.

Intel has turned its attention to total platform power: moving the VRMs on-die, and also identifying third-party motherboard components which draw silly amounts of power.

I think that Intel is on track here. Apple will of course push their design talent in order to deliver the best mobile devices they possibly can. But this does not necessarily mean a move away from Intel for a laptop or desktop.

JTenerife• 12 years ago

Good on Apple! That's the best that can happen to us customers. Even for an Android / Windows guy like me :-).

Apple's Cyclone Microarchitecture Detailed

Related Stories