
Apple Said to Work on Mac Chip That Would Lessen Intel Role - VeXocide
https://www.bloomberg.com/news/articles/2017-02-01/apple-developing-new-mac-chip-in-test-of-intel-independence
======
ChuckMcM
It 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
It'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
To 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.

~~~
kevin_b_er
So is the lesson taking contracts from Apple is not a good idea?

------
mmastrac
I 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.

~~~
wmf
This sounds incredibly kludgey and at odds with Apple's de-investment in
macOS. (As in "reduced investment", not "divestment".) Adding massive
complexity to eke out another hour or two of battery life seems like a poor
choice when there are so many things to be fixed in the OS.

~~~
r00fus
Why so? A Mac is a very high ASP item - why not, for example allow iOS apps to
run in macOS (using the ARM processor).

Ultimately, the 2016 MBPs are a great example of why Apple needs to divest
from Intel. The poor timing for Kaby Lake mobile processors and lack of low-
power RAM were both Apple's reasons stated when the topic of "the MBP isn't
keeping up with the competition" arises.

And who's to say that macOS.next will be anything similar to the current
macOS?

~~~
wmf
_why not, for example allow iOS apps to run in macOS_

That's not what the article is talking about and it's a bad idea for UX
reasons (no touchscreen).

 _And who 's to say that macOS.next will be anything similar to the current
macOS?_

Don't even go there; a vocal minority of Mac users including me _do not want_
anything like that. And getting back to the article, if the OS is radically
different then presumably it doesn't need both Intel and ARM processors.

~~~
r00fus
> Don't even go there; a vocal minority of Mac users including me do not want
> anything like that.

I'm a Mac user too. Unfortunately, Apple is notorious for doing what they
think is right, regardless of their user base. Need I say "lightning
headphones" or "no magsafe, just USB-C"?

Both of these strike me as positioning for the future _Apple wants_ despite
the concerns the vocal parts of their userbase.

~~~
X86BSD
Skate where the puck will be, not where it is.

------
ClassyJacket
Interesting. 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
That'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-supp...](http://www.eteknix.com/asus-give-
am3-boards-thunderbolt-support/)

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!

~~~
ClassyJacket
I almost posted that link too, but according to this comment, that product was
cancelled and never released because Intel refused:
[https://www.reddit.com/r/Amd/comments/539kvq/will_amd_cpusmo...](https://www.reddit.com/r/Amd/comments/539kvq/will_amd_cpusmotherboards_have_thunderbolt/dab2g3n/)

There's still a mention of an expansion card on their site:

[https://www.asus.com/us/Motherboard-
Accessory/ThunderboltEX-...](https://www.asus.com/us/Motherboard-
Accessory/ThunderboltEX-3/)

But it's only compatible with ASUS motherboards that already have Thunderbolt.
So I'm not sure what the point of it is (just to upgrade from ThunderBolt 2.0
to 3.0 maybe?), and as far as I can tell... still requires intel.

So as far as I'm aware, no product has ever released with Thunderbolt that
doesn't use an Intel CPU (and even then, only higher-end ones).

Licensing aside, it may be a technical issue - ThunderBolt is an extension of
PCI-express, which just isn't part of the ARM design. I'm not sure how
feasible it would be to add it.

~~~
wmf
Plenty of ARMs have PCIe, maybe even the A9.

~~~
ClassyJacket
Any examples?

~~~
wmf
Nvidia Tegra, all server ARMs, all Wi-Fi APs, higher-end embedded SoCs (e.g.
Marvell), etc.

~~~
ClassyJacket
Interesting. I didn't know that.

However, that still doesn't mean Intel will certify anything for Thunderbolt
that doesn't use their processors. I still haven't seen any evidence of a
certified Thunderbolt host device existing that doesn't have an Intel CPU.

------
gumby
There 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.

~~~
joezydeco
... _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-
io...](http://www.macworld.com/article/3163248/ios/the-future-of-ios-
is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html)

~~~
dgfgfdagasdfgfa
People 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
Cocoa 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
This 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.

------
alrs
There'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
NeXT had an Intel version as a hedge as well. Seems those two projects were
destined to merge together.

~~~
pvg
That was actually their product rather than a 'hedge' for a while.

~~~
astrodust
It 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
Considering 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.

~~~
rvense
Maybe SGI didn't want to play ball...

~~~
protomyth
Probably, but it just seems rather odd since MIPS had an open system spec and
Windows NT had been ported to it.

------
lend000
It'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_
> 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
> 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
It wasn't intended to be a niche product. That was just how it ended up....

------
ksec
I 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.

------
MR4D
This 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
I 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
Yes, 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.

~~~
TheOtherHobbes
One basic problem - macOS has many, many more features than iOS.

There would be a lot more involved than redesigning the UI. The two platforms
have fundamentally different class trees all the way from the view and user
event classes down to core OS hooks.

There's some limited overlap, but not as much as you might expect.

Merging the two platforms and creating a UI-level split wouldn't be
impossible, but it would be a huge job and would effectively mean a rewrite of
both OSs - and probably of WatchOS and TvOS too.

It's not obvious this would be a good thing to do. MS tried it, and that was
pretty much a disaster.

~~~
scholia
_> MS tried it, and that was pretty much a disaster._

Do you mean the Windows Runtime subsystem? How is it a disaster?

------
jrickert
Good 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
And inversely, I wonder how this news is for Linux on Mac hardware....

------
TwoNineA
Sounds 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).

------
throw2016
I 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
Oddly, 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
Intel 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
The 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.

------
John23832
As long as it's still x86/AMD64 we're good. I really don't want to see
PPC/Intel fragmentation again.

~~~
some-guy
I 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.

~~~
jlawer
Rosetta was mostly painless because the raw performance of the Intel chips
were multiples of the G4 chips in the macs (especially considering most
systems doubled the available core count). Even so Creative Suite was slower
as high performance plugins used altivec which was not emulated. This wasn't
an issue for compatibility as the G3's never had it, so almost every app had
non altivec code paths.

The overhead was mostly acceptable because the performance boost from the chip
change hid a lot of it. Not to mention the CISC vs RISC thing worked in
Apple's Favour. There are few PPC instructions that were required to be
supported that couldn't be covered with a small number of x86 instructions.

There is not a publicly available ARM chip that has single thread performance
anywhere near the i5 / i7 chips being used. Add to this the complexity of
converting SSE to equivalent instructions and the overheads dealing with edge
cases, I am not sure there is much chance of equivalent performance.

The one thing going for Apple with an intel -> arm switch is that almost all
major apps a built using Xcode. When PPC -> x86 happened, the apps that lagged
the most were the ones stuck on CodeWarrior and other 3rd party IDEs that
apple never gave sufficient notice to port in advance of the general
announcement (however I will concede that codewarrior was owned by Motorola so
it may not have made the jump anyway).

I think if Apple does release ARM based macs, it will be with apps
specifically recompiled, not using an emulation layer.

~~~
renesd
Performance per watt is pretty good on ARM. Most performance these days is
about IO. How fast is the memory subsystem?

There are intel chips with 400 gigs per second memory subsystems. But the
cores run at around 1.4ghz. Even a single thread with that much memory
bandwidth can be much faster. Likewise with cache. If you have 32MB of cache,
you can do quite a lot more processing in cache, and be lots faster for many
things.

Considering that macbookpro laptops haven't really gotten better single thread
performance in years - the things that really matter are IO, and performance
within the power/heat budget.

ARM is competitive now within the macbook power requirements. The A10 chip is
75% as fast as the i7-6600U in some single core benchmarks. At a much lower
power budget.

Within the chromebook space, where ARM and Intel laptops are currently
competing - Intel often produces faster laptops. However, they are also often
more expensive. Lots of people in many-many reviews say their ARM based
chomebooks are too slow.

Having been through the raspberrypi 1,2,3 performance leaps, I can say that
the latest one is quite usable as a desktop machine for word processing, web
browsing and media playing.

The Samsung Chromebook plus with ARM is shipping, and the one with Intel isn't
yet. The ARM one is cheaper, and the intel one is apparently more performant.
Both have a similar battery life. The ARM one has better support of android
apps. GUI app development is now 10x more active on ARM compared to intel, and
the apps are optimized more for ARM.

GPU performance is improving faster on mobile chipsets than Intel is
improving. Because of the demand from mobile VR applications. Some are
predicting performance will be faster than laptops in a mobile power budget
this year (see ARM Mali-G71). It's even faster than some nvidia discrete
mobile chipsets. Since many apps are performance limited by the GPU, and not
the CPU, I'd say ARM chipsets will win for many users low-mid users this year.

ARM is already taking over the low end laptop market. I won't be at all
surprised if they take the mid range market by the end of the year. Especially
as the market for chromebooks, and the low end laptops picks up. Because then
more laptop class ARM based chips will go into production.

I think the demand will be there, as the android using market also want to use
laptops that sync better with their apps.

[ED: add note about high performance ARM chips coming] High performance ARM
chips are coming to super computers. The Post-K super computer by Fujitsu is
expected to be one of the fastest computers in the entire world. If not the
fastest. Will ARM take the super computer performance crown? I think so.

~~~
scholia
There will certainly be ARM-based laptops running Windows 10. Have you looked
into that?

They are different from the Surface RT (Windows on ARM) machines because the
also run traditional x86 apps (not just a port of Office).

~~~
renesd
Yes, good point. It will be interesting to see how popular they are this year.
I also wonder if Office performance will be good enough for most people. I'm
pretty sure MS know what they are doing with that, and the answer will be yes.

~~~
scholia
I'll buy one if they are cheap and include a sim slot. It would basically be a
smartphone with Windows desktop software (mostly Office in my case) running on
an 11.6-inch screen...

------
vondur
I often wonder why Apple doesn't purchase something like AMD. They could
design their own x64 chips and GPU's.

~~~
sounds
AMD'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.)

~~~
detaro
I thought that deal goes both ways, AMD also licensing important parts of
AMD64/x86_64 to Intel, so both sides would have a strong interest in keeping
it alive in some form.

------
wang_li
This 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
You make it sound like they've never done that before (Universal binaries).

~~~
wang_li
But 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
Yes, "power nap" is an existing feature that only does specific OS/apple
specific operations (syncing, notifications, mail, calendar, indexing).

------
bitmapbrother
Apple 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.

~~~
msbarnett
IIRC 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
I 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/000119312509236...](https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm)

~~~
bitmapbrother
Does 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.

------
Philipp__
Totally 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
I 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
bit.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
Prior approaches to mixing architectures in one system (and actually moving
applications at runtime dynamically, as in big.LITTLE,) were ...

------
londons_explore
I 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.

------
xemoka
This 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?

------
5ilv3r
Can you just imagine how long the battery would last on an arm based macbook?
Days?!

~~~
magila
It 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
I 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
It'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
_they 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
The 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.

------
faragon
Anyone 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
4GHz 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-1...](http://ark.intel.com/products/93356/Intel-Xeon-
Processor-D-1567-18M-Cache-2_10-GHz) )

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.

------
gigatexal
I'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
Assuming the bootloader isn't locked down

~~~
gigatexal
There's always that risk: they'll do some sort of jail like they do with iOS.

------
roryisok
About 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

------
danjoc
>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."

~~~
__d
iOS 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
From what I understand bitcode is still somewhat architecture dependent and
wouldn't work well for ARM<=>x86 translation.

