10 ms·
Apple Said to Work on Mac Chip That Would Lessen Intel Role
- xemoka 10y agoThis is interesting given Microsoft's move to full windows-on-arm (and not that travesty that was Windows RT). Something I'm certainly looking forward to—if not only for the devices that it creates, but a chance for more open mobile computing. (Sh|C)ould this be a concern for Intel?
- gumby 10y agoThere is only one piece of "news" (possibly speculation) in this article: that they may offload some processing to the ARM coprocessor as a transitional step. Interesting idea! But the idea that they have the Mac OS running on their own ARM chips -- Apple shareholders should be annoyed if the company weren't doing this. OS X was running for a long time on Intel before anyone decided to make Intel based Macs.
- deleted 10y ago[deleted]
- Brakenshire 10y ago> But the idea that they have the Mac OS running on their own ARM chips -- Apple shareholders should be annoyed if the company weren't doing this. And if the company wasn't floating the idea of switching. Should at least give them leverage in negotiations with Intel.
- joezydeco 10y ago...or iOS will be graduating up to be the new OS across both mobile and desktop platforms? Earlier today via HN.... http://www.macworld.com/article/3163248/ios/the-future-of-ios-is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html http://www.macworld.com/article/3163248/ios/the-future-of-io...
- dgfgfdagasdfgfa 10y agoPeople have been saying this since the inception of iOS; given the trajectory of Cocoa vs UIKit, I don't see much sign of this.
- equalarrow 10y agoCocoa over the last few years has made a lot of cleanup/progress on its api's. Making a Mac app in Swift 3 is almost as painless as making an iOS app nowadays. I feel like there has been a big difference in just the last few years. Swift is a big part of this, but also, I'm sure Federighi's group is the real reason.
- emdowling 10y agoThis is one of the big reasons why I don't buy the whole narrative in these parts around Apple abandoning the Mac. They are spending far too much time on improving Cocoa APIs as you mention to be working towards abandoning or deprecating it.
- nomel 10y agoI'm not familiar with either API, but why wouldn't it be possible to get Cocoa working in iOS? I imagine UIKit would be optimized for small, low power, devices, which will always exist in some, ever shrinking, form. It's all just a BSD variant, when you get down to it.
- dgfgfdagasdfgfa 10y agoThere's nothing stopping Cocoa from working on iOS (or UIKit on Mac OS), but they operate on different UI paradigms.
- manmal 10y agoThey have used a chimera though, UXKit: https://9to5mac.com/2015/02/05/uxkit-framework/ https://9to5mac.com/2015/02/05/uxkit-framework/
- 10y ago
- H4CK3RM4N 10y agoThe impression I got was that they were offloading background checks while the computer was sleeping to the ARM chip. Hopefully bringing iOS's low power performance to the desktop.
- John23832 10y agoAs long as it's still x86/AMD64 we're good. I really don't want to see PPC/Intel fragmentation again.
- DeepYogurt 10y agoProbably arm this time around and if you look at the linux ecosystem you'll see that there's nothing to fear.
- bostand 10y agoWhat?
- 5ilv3r 10y agoNo he means that running x86 legacy mac programs on an arm mac with an emulator as a compatibility shim would be slow. Linux is totally different, because you can clone an entire DISTRO, cross compile it, and have a native arm environment with no compatibility shims slowing things down.
- some-guy 10y agoI thought it was mostly painless. Vast majority of applications provided an Intel binary right away without many issues. Rosetta wasn't too terrible for simple tasks for the rest of them.
- TwoNineA 10y agoSounds similar to big.LITTLE where by big are Intel cores for performance and power nap and maybe in the future less power intensive tasks are handled by LITTLE (ARM part).
- danjoc 10y ago>Is it IBM compatible though? Man, I hated hearing that question. It was so utterly retarded, but trying to explain to the person who asked why it was a retarded thing to say always came off as damage control. >Yep, not IBM compatible. Not interested. Maybe Apple can get away with their own chips now. It sounds like they just want to take more R&D away from Mac though. "Just stick an A10 in it."
- 5ilv3r 10y agoThe need for IBM PC compatibility has been dead longer than software sold in boxes. Longer than compaq has been gone. Longer than USB has been a thing. Longer than current CS students have been alive, even!
- __d 10y agoiOS applications are now compiled to an intermediate representation which is then translated to the target CPU instruction at install time. macOS applications could similarly be built to run on multiple instruction sets with basically no effort from the developers. Perhaps initially it might be restricted to first-party apps, or maybe AppStore apps, but having fat binaries is something macOS developers are used to doing ... The difficult bit would be the runtime migration from x86 to ARM and back. For processes that can restarted, it's easy. For running, stateful applications it would be more difficult. But I think things like Mail.app already use a backend daemon to manage their datastore: you could suspend the UI process and restart the backend daemon on the low-power CPU fairly simply ...
- chrisballinger 10y agoFrom what I understand bitcode is still somewhat architecture dependent and wouldn't work well for ARM<=>x86 translation.
- alrs 10y agoThere's always a hedge afoot. Apple had OS 7 running on Intel as early as 1992. https://en.wikipedia.org/wiki/Star_Trek_project https://en.wikipedia.org/wiki/Star_Trek_project
- astrodust 10y agoNeXT had an Intel version as a hedge as well. Seems those two projects were destined to merge together.
- pvg 10y agoThat was actually their product rather than a 'hedge' for a while.
- astrodust 10y agoIt started out as a hedge against their own hardware being an impediment to sales, then ended up being their entire business. I guess it was a good hedge to have!
- protomyth 10y agoConsidering they had NeXTSTEP release versions running on x86, PA-RISC, SPARC, and its original home 68000, they did pretty well. I do wonder why the MIPS chips were ignored.
- mmastrac 10y agoI think that in the long run you'll see a hybrid ARM/x64 Mac sharing the same case in the same way we have hybrid graphics. If you look at most of the processes running on a Mac, how many of those need to be running on the power-hungrier Intel chip? You could easily offload much of the kernel, Dock, compositor, Twitter desktop, etc to a lower-power ARM. In the case where you aren't running any x64 apps, you could then power that chip down and run solely on ARM.
- deleted 10y ago[deleted]
- bhewes 10y agoThe Playstation 4 does this as the south bridge is really just an ARM chip. So I think you are right.
- monocasa 10y agoAnd the PS3 before it. And the WiiU, and the Wii. And every AMD chip since about 2013 (AMD Platform Security Processor, their equivalent of Intel's ME). Honestly, pretty much every complex electronic device (and quite a few not so!) out there has a bunch of ARMs inside of it doing system management. This is borderline a non-story IMO. Hell, an ARM7TDMI was a pretty common core to use on SD cards a few years back. The damn things are everywhere.
- brandonmenc 10y ago> ARM7TDMI was a pretty common core to use on SD cards Which is crazy, because that was the main CPU in the GameBoy Advance.
- wmf 10y agoThe PS4 southbridge has 256MB of RAM, runs FreeBSD, and downloads game patches and such. This seems far more ambitious than a BMC/ME.
- throwawayish 10y ago
- bitmapbrother 10y agoApple should just buy AMD. It would only cost them about 15 Billion or so and they would get an x86 license. If they really want to control their own destiny this would be the way to go.
- MekaiGS 10y agoFrom my understanding the x86 license is not transferable upon purchase.
- erik 10y agoI wonder about the other x86 licenses that have been out there in the past. Via still offers x86 apparently. It looks like Cyrix ended up with Texas Instruments. Transmeta looks messy. IBM used to make x86 chips as well. And I wonder if any of this relevant to making modern x64 compatible cpus?
- msbarnett 10y agoIIRC AMD's cross-licensing deals with Intel over certain key patents are null and void if AMD is bought, which puts a real damper on the main reason anyone would consider purchasing the company.
- acdha 10y agoI believe this is the agreement you're referring to and it looks like it applies even to a change in ownership of 50% of the company: https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm https://www.sec.gov/Archives/edgar/data/2488/000119312509236...
- bitmapbrother 10y agoDoes Apple even need to own a majority ownership to control the company? Couldn't they just purchase 49.9% of the company and set up the board of directors in their favor? With that much stake getting the company to do what you want it to do wouldn't be that difficult it seems.
- 5ilv3r 10y agoCan you just imagine how long the battery would last on an arm based macbook? Days?!
- magila 10y agoIt is actually quite difficult to beat Intel on power efficiency once you start talking about laptop class CPUs. The combination of Intel's advanced fabrication tech and their highly efficient core family of microarchitectures gives them a significant advantage outside of the ultra-low-power space.
- 5ilv3r 10y agoI don't think that's true. Arm chips just don't clock as high as intels can, and no one* cares about clock speed any more. That ship has sailed. Multiprocess web browsers will drive the sales of massively multicore arms (with tons of ram!), and intel will be sunk.
- magila 10y agoIt's not just about clock speed. While Intel Core CPUs don't scale down to power budgets as low as ARM cores, they are impressively efficient on a perf/watt basis. Smart phones achieve high battery life mostly by being very aggressive about reducing CPU load in software (see iOS killing apps the moment they go into the background). General purpose operating systems don't work like that so there's more reliance on the hardware to keep power draw down.
- Redoubts 10y agothey are impressively efficient on a perf/watt basis Is that true? I thought people were trying out ARM rack servers because of the power efficiency vs perf.
- magila 10y agoThe key word there is "trying". ARM servers have had a tough time gaining traction in no small part because the hoped for power efficiency gains have not been realized.
- Philipp__ 10y agoTotally expected, because they need to increase performance and lower battery consumption. Now the extent of taking job from main Intel's CPU and spectrum of possibilities of ARM coprocessors are yet to be seen. I can see it doing some hardware related tasks that do not interfere with actual higher stack of macOS and x86 space. But this is all pretty common. This title looks little clickbaity imho.
- throwawayish 10y agoI expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either. (1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only exist in separation: eg. IBM TIMI allows to move applications across physical processor ISAs, while various clustered virtualization implementations can move live VMs across distinct hosts.
- pertymcpert 10y agobit.LITTLE isn't a mixing of architectures, it's a mixing of micro-architectures. And the fact that big.LITTLE designs are commonly used now, and even Apple adopting their own version of it in their latest SoC is a validation of its benefits.
- throwawayish 10y agoPrior approaches to mixing architectures in one system (and actually moving applications at runtime dynamically, as in big.LITTLE,) were ...
- gigatexal 10y agoI'd always be open to Apple putting a supercharged ARM chip in a prosumer laptop. We could always run a variant of linux on the laptop if OS X were too buggy.
- hackcasual 10y agoAssuming the bootloader isn't locked down
- gigatexal 10y agoThere's always that risk: they'll do some sort of jail like they do with iOS.
- redial 10y agoOne can hope, but judging how Linux handles MacBooks right now I'm not so sure they are the ones to bet on to provide a bug free experience.
- wang_li 10y agoThis sounds weird. Are they going to have two versions of every executable? One arm and one intel? Or would this low power/power nap mode only support a tiny subset of functionality that apple chooses to include in their OS release?
- craigcabrey 10y agoYou make it sound like they've never done that before (Universal binaries).
- wang_li 10y agoBut those weren't both loaded into memory at the same time. Thinking about this I've convinced myself that what will happen is the ARM core will periodically check for various statuses (i.e. connect to your imap/pop server and see if there is new mail) and turn on an indicator or perhaps wake the intel cores. Which is to say that the powernap/low power functionality will be restricted to either things apple delivers ootb or to a special API. Not as something that automatically migrates whatever workload is running on the powerful intel cores into a slow motion version of the same thing running on the ARM cores.
- an_account 10y agoYes, "power nap" is an existing feature that only does specific OS/apple specific operations (syncing, notifications, mail, calendar, indexing).
- H4CK3RM4N 10y agoFrom the article it looks like the arm chip will have tasks offloaded onto is, like a GPU has graphics tasks offloaded onto it from the CPU.
- ropiku 10y agoThey sort of do this already with iOS apps during development. iOS Simulator is a simulator, not an emulator so the developing app is compiled and run in native x86.
- throw2016 10y agoI think the problem is while ARM is good at lower power the moment you need sustained performance the power requirements shoot up and throttling begins. The flagship ARM A72 and A73 are not adequate for true desktop class performance, somewhat catching up to Intel's low end core u laptop chips. It's increasingly looking like to get x86 level performance ARM would lose its low power advantages. The AMD Zen on the other hand appears to be extremely efficient. I fiddled with ARM boards on and off for over 3 years excited by the possibilities of tiny form factor desktop class computing at laughably minimal costs with ARM SOCs. The reality is the extremely poor to non existent driver support and the 'effectively closed' ARM ecosystem is a deal breaker that left me disillusioned and strangely relieved with the the open PC ecosystem.
- 5ilv3r 10y agoOddly, ARM is eating the PC architecture from the inside. What's on your raid card? An arm. What's in your usb devices? An arm. What's in your SSD? An arm. A PC is beginning to look like a network of arms with an intel driving. How long will the intel core last?
- gpderetta 10y agoIntel margins in that single chip are probably a few orders of magnitude of ARM royalties on all those embedded CPUs combined. Intel has little to fear from those chips. On the other hand, Apple does seem to have the capability to design competitive desktop class CPUs, so who knows.
- pertymcpert 10y agoThe absurd margins are in fact the reason why Intel need to fear ARM. It gives an incentive to lower the costs by designing them out of systems, even if it means sacrificing peak performance.
- gcp 10y agoApple doesn't use ARM designs. Their own A10 leaves the ARM designs far behind. They just use the architecture.
- lend000 10y agoIt's finally happening! The increase in competition in both the foundry and architectural spaces is exactly what we need to push us past this stagnation of Moore's Law. Intel needs to sacrifice Microsoft and make x86 a legacy architecture. There are huge parts of their processor designs that no one at the company modifies (or even understands) from one generation to the next, but which they cannot remove for backwards compatibility purposes. It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology.
- Analemma_ 10y ago> It's time to start fresh with a new architecture if they want to maintain their reputation of having the most powerful technology. They tried that, though. It was called Itanium and it went nowhere. Now, Itanium had all kinds of other problems and I wouldn't call its failure incontrovertible evidence against "Intel should make a new architecture", but I can understand why the company isn't eager to try that again. Backwards compatibility exerts an powerful gravitational pull that is extremely difficult to break away from if you're not started a new platform ex nihilo (which Apple did for the iPhone).
- lend000 10y ago> It was called Itanium and it went nowhere. It was popular in its intended niche (HPC) for a while, but the value proposition was not sufficient. It dropped some x86 baggage but it didn't add anything fundamentally superior on top of it -- the ILP could easily be attained by having more cores on x86. To be honest I actually really like what they did with Itanium, but it wasn't a good enough innovation to break off the family line of backwards compatibility.
- scholia 10y agoIt wasn't intended to be a niche product. That was just how it ended up....
- pcwalton 10y ago
- MR4D 10y agoThis has been rumored for some time. I believe it's true, but then again, Apple kills off most projects before they see the light of day. Whether this ever makes it to consumers is the important question. That being said, I've seen a number of comments about running iOS apps on Macs, or "convertible" Macs/iPads, and so on. I think those are off base given the supposed purity that Apple always talks about. However, there is one thing I've never seen mentioned - a combined Mac/iOS binary. Similar to the old Universal binary for PPC/Intel, this could be a single app that just has different UX depending on the device it's run on. I'm not sure why nobody has talked about that option, as it seems most likely to me, and gives more weight to the ARM everywhere strategy. One "app", and it would be native, with native UI on whichever device it's running on (Mac/iOS/TV/Watch/etc.). Given Apple's investment into a streamlined complier that they rolled out with Watch, many if not most of the pieces are already in place for this. It would not surprise me if that is the big announcement for this summer (or next at the latest).
- plussed_reader 10y agoI feel like they've been doing this to osX, starting with 10.9 it seems like a lot of the visual flair of iOS has filtered into the macOS environment. I fear that this will dumb it down too much for the power users, and conversely over-complicate it for the average iOS user. I'd love to be wrong...
- MR4D 10y agoYes, but this is not specifically what I'm talking about. Think of something like MS Outlook - it's a big, complex app with lots of features. Now imagine that you only write the app once, but design two interfaces for it - one set for the Mac, and the other for the iPad. You compile through XCode, and upload to the App store. Apple notes that their are interfaces for both iPad and Mac, and posts it in both app stores. Obviously the mechanics would not be exactly like this (I presume a manifest of some kind), but it should be pretty close. For Apple, this would bring more developers onto their tooling (yes, even many of those that complain about XCode), and allow more developers to target multiple platforms with little extra effort. In fact, one of the more interesting things is that Apple could even create new platforms that just require some interface additions and an updated manifest. Have a bug in your code? One fix. One upload. One code review.
- roryisok 10y agoAbout two weeks ago I commented on a post here (a concept design for a new mac pro) joking that the next mac pro would probably run and arm CPU and have the ram soldered on. Looks like I was on to something
- ChuckMcM 10y agoIt has been interesting to watch the ARM ecosystem unfold. Sort of like seeing a levy breach where just a trickle of water starts flowing over it and then more and more and more. Apple has the resources and the motivation to build a "desktop" 64 bit ARM processor. The history here is also interesting. After debuting the Macintosh in 1984, and getting into fights with Motorola over what should be in the next generation chips, they did the unthinkable and adopted an entirely new instruction set architecture, PowerPC. That relationship ended on a fairly rocky note and Apple did not have the IP rights to continue PowerPC development or the infrastructure access. They switched to Intel's architecture with great fan fare and started using ARM in their mobile offering. Now ARM has reached the point where it is adopting "high end" features faster than Intel can invent new ones. And Apple has both proven to itself that it can design and fab a completely bespoke CPU design without any input from the original owner. So here we are looking down the barrel of "bespoke chip architecture round II." It gives Apple some unique advantages that neither Microsoft nor Google can match.
- ben_jones 10y agoIt's really interesting how the historical strengths of companies can persist even after decades of evolution. If the people are coming and going, how is this institutionalized success being cultivated and maintained?
- ChuckMcM 10y agoTo be honest I don't know the answer to that. That said, Apple has always had corporate value of being maximally responsible for their own destiny. It's hallmark card wisdom to know the things you can change and accept the things you can't change, but in Apple's case their history has been filled with finding things we can't change and replacing them with something we can. So where one company might say "Well we have to work with what ever the microprocessor company will agree too" Apple wants to say "The microprocessor company will do what ever we require of them." And if they can't find such a company they look at becoming a microprocessor company. A lot of that thinking was laid out fairly extensively in the lawsuit over manufacturing sapphire they got into. The manufacturer (GT Advanced) complained (reasonably I think) that Apple's contracts were so onerous as to make them employees of the company in everything but name. And that appears to be how Apple likes it, complete control of their destiny when ever possible.
- faragon 10y agoAnyone knows how far is Apple from getting the following desktop system as one SoC? - 4GHz 12-core 64-bit ARM OooE with 256KiB L2 cache per core - 12MiB of L3 cache - Integrated graphics with 128MB eDRAM - PCI-Express buses - 35 GB/s DDR4 memory controller - 5-65W power usage
- wmf 10y ago4GHz 12-core in 65W isn't going to happen. (Intel is currently at 2.1GHz: http://ark.intel.com/products/93356/Intel-Xeon-Processor-D-1567-18M-Cache-2_10-GHz http://ark.intel.com/products/93356/Intel-Xeon-Processor-D-1... ) Hurricane could probably run at 3GHz but to get to 4GHz might require serious work. Apple hasn't used eDRAM but in theory they could adopt it. The rest looks like no big deal.
- ClassyJacket 10y agoInteresting. The article says that Apple is considering an ARM co-processor, not a replacement for the Intel CPU. I have no doubts at all that Apple have at least had extensive internal discussion and testing about this. In fact, I believe they've probably done extensive internal discussion and testing about replacing the Intel one altogether, but can't get there yet. It'd give Apple more control over their device design and release schedule, potentially lower power consumption, and straight up more profit via vertical integration. Like the PowerPC transition, they could come up with a new Rosetta - which was the emulator that ran old PowerPC apps on x86. Microsoft has recently demoed x86 apps on ARM, and I'm sure Apple could do the same. As far as I know there's no fundamental reason ARM processors can't be as fast as x86 ones, they just haven't been targeted for those kind of devices yet - but I'd be happy to be corrected by any CPU experts. And with Apple's success in the mobile processor space, I have no doubts that if anyone could pull this off, it'd be them. So what's holding them back? Thunderbolt. They've gone all-in on that already - touting as the future of high speed external devices, and giving the MacBook Pro nothing but four Thunderbolt enabled USB-C ports and a headphone port. But Thunderbolt is an Intel property, only available on their CPUs. The 12" MacBook already doesn't have Thunderbolt (the MacBook Pro does), but it feels like with software compatibility, this would be an all-or-nothing thing. I don't see Apple continuing to sell both x86 and ARM machines on an ongoing basis. So how would they get Thunderbolt into the MacBook Pro? Having a co processor to handle PowerNap would allow them to take a small step in that direction without losing Thunderbolt or having to develop a slow x86 emulator. They could even offload other parts of the OS to the ARM cpu, freeing up the main CPU for other software, and to go into low power mode more often.
- _s 10y agoThat's actually a interesting point - I wonder if it's possible to license the Thunderbolt tech in some way, and have it hooked up to the ARM Chip; something like what Asus does to give AMD thunderbolt: http://www.eteknix.com/asus-give-am3-boards-thunderbolt-support/ http://www.eteknix.com/asus-give-am3-boards-thunderbolt-supp... Saying that - and I hope someone corrects me here if I'm wrong, I was under the impression that Apple & Intel jointly created Thunderbolt (or perhaps it is an Intel only tech), which means Apple may have some sway here. Just thinking about it more - Thunderbolt is just a protocol driven over USB-C now, so I'm fairly certain USB (3/C) might eventually be able to cover everything Thunderbolt does, or apple takes their "lightning" protocol to replace Thunderbolt, and use that over USB instead of Thunderbolt over USB. Just musing but it is a very under appreciated aspect to all of this as well!
- vondur 10y agoI often wonder why Apple doesn't purchase something like AMD. They could design their own x64 chips and GPU's.
- sounds 10y agoAMD's license for the parts of x64 owned by Intel is conditioned on AMD not getting sold. The license wouldn't be transferrable to the buyer. (So, yeah, AMD could do their own slightly-different chip, using just the bits and bobs that are strictly theirs.)
- flukus 10y agoRemember when apple was tied to the power pc chips? This would likely end up the same.
- hogrammer 10y agoThis might make it harder to build a Hackintosh, too.
- jrickert 10y agoGood news for Apple and overall progress, but sad news for those of us in the Hackintosh community. Apple's support for Intel CPUs is really what enabled the whole movement to get traction. I really prefer to see Apple moving toward standardized vs proprietary hardware options.
- bo1024 10y agoAnd inversely, I wonder how this news is for Linux on Mac hardware....
- ksec 10y agoI have read multiple article but i have yet to see anyone mention it. Isn't this about Security more then anything else? IF it is about power, Intel SoC uses very little power during Power NAP. And any saving by switching to ARM should be negligible, when you consider the memory and I/O needed during Power NAP. If it is about cost, Apple could have worked with AMD on Mac. I am pretty sure Ryzen and Vega works better on dollar / performance / Power. Especially on the Desktop Mac. Considering AMD has done special chip with console, I dont see why Apple couldn't use this model as well. Since Intel's CPU has IME which Apple has no control, would that be a reason? Apple taking security in their own hands.
- londons_explore 10y agoI consider this a mostly tactical move to get better prices out of Intel. Sure, the plan as presented might work, but the migration will take years, be messy, and lead to lots of unhappy customers due to poor emulation performance, dropping legacy app support, bugs in a new architecture etc.