Apple’s abandonment of Intel chips is inevitable (2018)
theverge.com
theverge.com
Certainly doable, but there's a lot more boring spadework needed beyond the sexy CPU.
* This is why I always laughed when I saw articles comparing laptops by CPU clock speed rather than actual performance.
Hasn't Apple been pretty obviously moving in that direction? Their T2 chip does a lot. Given how Intel doesn't let third-parties make alternatives to their own southbridge chipsets any more (a change that screwed Apple's product strategy at the time), there's not much more that Apple could move into the T2 until they're ready to abandon Intel CPUs, too.
Is this some kind of test for when they move to ARM? Or do they want to do what they have done before and cannibalize the Mac platform for non professionals?
Kind of like how the Honda Civic has gotten bigger with more features over the years, to where it surpasses the original Accord. I'll bet the Honda Fit from now will grow in the same way and they'll have to invent a new "budget honda" for the next generation of young people.
> Expanding a car's footprint — the wheelbase multiplied by the track width — gives it a lower fuel-economy target to meet under the CAFE standards negotiated by automakers and regulators.
https://www.autonews.com/article/20160814/OEM11/308159946/is...
https://www.theonion.com/a-statement-followed-by-a-question-...
That's why I'm skeptical that we'll ever get an "Arm MBP". Apple would rather do away with laptops, they see them as annoying and expensive legacy that just happens to be unreplaceable at the moment. There is no point investing into a massive and bloody transition of a segment you are trying to divest from.
Also, part of the UI rethink has to happen in the OS, which is why Apple eventually spun out a dedicated tablet OS. They are coming around.
It was not technological limitations preventing Apple from making one themselves.
And they've been shipping PCI-e on their chip for T2. I'm pretty sure the iPad displays are Embedded Display Port, but don't have a source for that.
0: https://emerythacks.blogspot.com/2013/04/connecting-ipad-ret...
What would make it laptop-class, other than by adding more USB-C ports?
These limitations are perfectly reasonable for an iPad but not for a laptop.
FWIW nothing but a single TB 4 port (not even an audio jack) would work just fine for me, but I know some others feel differently for their use.
Considering that USB4 will be Thunderbolt 3 compatible, I'd guess that we'll start seeing more Thunderbolt ports soon.
Just about all peripheral communications standards for consumers are open standards, like PCIe, USB, SPI, Ethernet, SATA, SAS, and even Thunderbolt now. The only problem I could think of would be the Intel-owned HDMI but it's nothing DisplayPort + a simple dongle can't sidestep.
I know Apple couldn't depend on Intel for it's basic GMA acceleration anymore but it could simply use what's in the iPhone for basic display acceleration.
I’ve tried using an iPad Pro as a computing platform to run some of my code (mostly for fun but also it makes for a more interesting demo) and this is quite noticeable.
I think part of up this is simply because of Intel’s design approach, and also because Apple’s target is devices that can run quickly and then go to sleep to save power/heat.
Not to imply that Apple couldn’t design for that but it isn’t a mobile use case that they have been shooting for to date, and I suspect the current, publicly released chips would not be appropriate for a laptop much less an iMac.
Apple’s ipod designs remind me in spirit of the design of the Alto: focused on the display before anything else.
The recent Catalina update that caused a bunch of older programs to simply stop functioning strongly implies Apple doesn't care that much about being backwards-compatible any more.
As for hardware lifetime...I’m still using a 2014 iPad, 2015 iPhone and only stopped using my 2015 MacBook because it got caught in the rain.
They could also just license it from Intel. AMD has some hot designers (some who cycled through Apple!) but overall has little to add to Apple (in my ignorant-of-the-true-state-of-Hines opinion. And I admire both companies).
Apple’s never been afraid to license something rather than do a perfectly legal legal clean room but-almost-perfect clone.
I doubt they’d bother.
Now of course I’ve never seen the intel/amd agreement so I’m just speculating as to what it says. But the weight of precedent/tradition makes a prohibition on transfer unlikely.
A device that initially only runs what Apple ships (web browser, Pages, Keynote, and Numbers) plus a few essential iOS apps (Facebook, WhatsApp, etc), priced competitively, is good enough to create a sizable market.
MS Office, FireFox, Chrome, and the like only are only nice to have at launch. It’ll be fine if it takes a few months for them to become available. They probably can do without Photoshop for years.
Apple isn't Microsoft, but their consistent failure attempting something like this may be a tale of caution.
Both options kinda suck.
This just isn't true. I looked up some benchmarks. The iPhone X with the A11 Bionic got a Geekbench score of 918 for single core and 2368 for multi-core. To put that in perspective an old 15-inch MacBook Pro from 2013 with a Core i7-3840QM clocked in at 820 and 3199 respectively.
Or compile it all in Xcode. Not terrible, I just happen not to like guis.
I'm actually surprised how long Apple takes to obsolete APIs (carbon lingered forever) and how far back they are willing to support old hardware. They project an insouciance towards old APIs but tend to give a lot of advanced warning (e.g. the obsolescence of 32-bit applications was announced at least five years ago). They seem to be far less conservative towards UI, and prefer to rewrite rather than update which leads to a bunch of new bugs. That might be what gives people the impression that they junk APIs quickly.
* that's a matter of personal taste, not meant to start a flame session.
The switch from 68k to PowerPC was because PowerPC was an extremely powerful up-and-coming architecture at the time. A PowerMac 7100 (one of the earliest models) blew a 68040 Mac out of the water.
So when IBM came to them asking "hey how about we scale down POWER to a desktop chip for you?" Apple also brought in Motorola so that they could dual-source their chips and not be dependent on one company, and PowerPC was born. Rather than being an up-and-coming competitor, PowerPC probably wouldn't exist without Apple's involvement (they would probably still have pursued a scaled-down POWER, but it wouldn't be PowerPC)
One of the thing about these rumours is that they are always 6 months or so before another new Mac product launches or refresh. It could also have been coincidence since Mac used to update once a year, and any rumours would always fit into that time frame.
But I cant help and wonder if this is just a tactics from Apple on pricing. Apple doesn't get any marketing subsidies from the Intel stickers since Apple dont use any of those. Surely Apple would still want an equivalent incentives if not more.
[1] https://arstechnica.com/gadgets/2011/05/apple-could-adopt-ar...
But what was clear though was Steve wanted a notebook, and Intel Centrino was the perfect fit. And the roadmap from IBM was a dead end. And it was very obvious, ( unless you belong to those group that does not believe in Notebook market) that switching to Intel was the only choice.
But this time there is nothing ARM / Apple CPU can do that Intel cant. The only real advantage Apple get is cost reduction. Intel isn't like IBM where it has no low power roadmap, and Intel's IPC aren't far behind either.
Less so on the Mac because of the much smaller visibility. But generally speaking he does tends to get it right before anyone else as we are closer ( months before launch ). Those who claims to be accurate are often weeks before launch. There are so fundamental differences.
Imagine a 15" iPad Ultra Pro with comparable hardware, running iOS, with wireless keyboard and mouse / touchpad. Could it be a real workstation?
If powerful processor and plenty of RAM would make a laptop then your Playstation was a laptop too! :)
Thankfully I’m not clinging to any older unsupported apps so I realize it’s easy for me to be pro ARM Mac - which is why I don’t expect Apple to go ARM only any time soon but offer a choice for quite a while while the market settles out.
And who knows, Intel could turn it around. They haven’t managed for the last 7 years or so, but I suppose it could still eventually happen.
But if, eg, MacBook Air turns into MacBook ARM but MacBook Pro remains Intel - this would be a very difficult schism. Many publishers might look at it as being pro customers staying on Intel and cost-sensitive customers on ARM, which could damage adoption.
The risk is having no carrot and no stick - not entirely dissimilar to Itanium's problem.
…which has historically been fairly terrible at being either.
Not to mention that they are shipping an iPad version already.
Even Adobe's transition from PPC to Intel took 15 months after Intel Macs started shipping and 22 months after the x86 Mac dev kits were publicly announced (though I wouldn't be surprised if Adobe had a heads-up if not actual dev kits even before Apple publicly announced their Intel transition).
And let's not forget all the fuss Adobe made when the rest of the world was ready for Flash to die. This company has a history of being very defensive about their technical debt.
I expect the transition to be done before the end of 2022, with intel support being dropped from the latest OS two years later, and no more macOS updates for intel-based macs two years after that.
Not a thing what I would normally do but my rendering desktop was out of commission for a few days while waiting for parts to arrive.
Two points to think about on this issue:
1) When Apple moved away from PowerPC, they did so entirely.
2) Apple historically* wanted to keep its hardware offerings simple and easy to understand, and supporting multiple architectures could muddy their offerings.
* When Jobs returned to Apple, he killed the confusing lineups in favor of one option each of desktop or mobile, for pros and home users. This has changed a bit lately, but I can imagine ARM and Intel options of Macbook vs Macbook Air vs Macbook Pro being a nonstarter.
Anyway, I agree, an ARM Macbook Air would be awesome, assuming the software followed suit.
that was the point that apple realized intel had become incapable of leading the industry any longer and started looking beyond intel.
Apple has done this twice before(68K and PPC), and currently runs a split CPU architecture ecosystem - granted there are hard product delineations between them today, but there aren’t any significant technical reasons why Apple couldn’t effectively support both ARM and Intel Macs - and do so for an indefinite period of time.
The real issue is MBPs.
* Apple tried to drop it once before (but the 12’ MacBook didn’t do well enough to usurp the MBA)
* The latest iPad advertisement talking about “your next computer” and the keyboard + trackpad attachment
Aberration May be a bit strong. Stopgap living beyond its intended life may be more appropriate?
I hope Apple learns from Sun's mistakes.
Also, somewhat related: does anyone remember Transmeta? They were about a decade too early but their ideas on low-power, low-heat x86-compatible mobile-friendly processors were pretty cool. https://en.wikipedia.org/wiki/Transmeta
Sun never had the volume Apple does. SPARC was far from competitive with x86 in its later days, unlike Apple's A-series chips.
Transmeta? I was there from ~2001 until we closed the doors. What some people still don't understand was that Transmeta's failure was a business failure, not a technical one. When Crusoe launched it had greater power efficiency than Intel's chips. Intel has _officially_ credited Transmeta with kickstarting Intel's focus on power. Execution and business failure cost Transmeta to slip more than a year at which point opportunity and customer goodwill had sailed. Someone really should write a book about all the drama.
What do you think about wasm?
I have been around compiler internal formats and "bytecode" representations since the mid 80es. WASM is simply brilliant for what is designed for. I'm particularly in love with the structured control flow (key for enabling 1-pass translation). I used a block structure IR a compiler IR in the mid-90es. (EDIT: am I being trolled?)
I think wasm will be the portable bytecode we have all been promised. It will literally run our flying cars.
It also melts away the need for an MMU and because of that, the operating system. Requiring an OS, kernel/user code is no longer referentialy transparent, but with wasm, you can basically have an infinite number of hypervisors.
So, yes, they learned. I suspect they will ship an x86 emulator as they did with Rosetta, additionally.
I'm unsure whether some classes of desktop applications can ever be as useful on mobile platforms as they are on the desktop. I'm thinking of applications that legitimately need a lot of screen estate to stay useful like digital audio workstations or IDEs with extensive debugging support.
I contend that useful desktop applications are sometimes useful precisely because they run on a desktop.
All of which means that, starting this year and definitely in the next few years all possible patents on the core x86-64 standard will expire, with each additional year bringing a few extra extensions. As far as what Apple requires to run historic macOS code, they clearly have not built a dependence on every cutting edge new instruction. They officially supported 2010 Mac Pros (which were on the Westmere chips) until last year, and 10.15 can still be made to run on them.
Ever since Apple giving up on Intel chips has been discussed one general assumption/objection that I have always seen essentially assumed is that it also means abandoning x86 too, and in turn an enormous amount of macOS software, compatibility, etc. But need that actually be the case? x86-64 going patent free for all the essential parts opens up a lot of options for a lot of players. Maybe I've missed a lot of discussion (and if so I'd love to be directed to it) but so far I really haven't seen it considered much. 20 years is a long time in tech, but it's not forever. Without IP holding them back, need Apple ever give it up? They can focus on ARM, but a high performance hardware/software translation layer would certainly change the math around a transition wouldn't it?
> starting sometime around 2020
That prediction hasn't proven wrong yet, but it's looking increasingly unlikely. If the Mac were a bigger part of their revenues, they'd probably be further along in the transition though.
AMD already has ARM server experience with the https://www.amd.com/en/amd-opteron-a1100
Then they will slowly deprecate MacOS, but only after they made sure that development of software can be done one the modified version of iOS.
Through that's just a wild guess.
It just doesn't make sense to adapt iPadOS even more to a MacBook Air computer if they're not going to include a touchscreen. With them holding out as long as they have on touchscreens, I can't imagine them reversing course.
Apple had been letting Macs and Mac OS languish for a few years but has really stepped up their game over the last couple of years. I think they will keep them separate for a long time while brings things together under the hood.
Apple certainly has Mac OS ported for Arm and they also certainly have their own apps cross-compiled for Arm Mac OS. Once the OS and libraries are ported, the apps are relatively easy to adapt to the new system.
Meanwhile, it's 2020 and and x86 instruction sets upgrades are infrequent compared to ARM. And x86 CPUs still are required to support 16-bit devices from 35 years ago.
Also, the x86 instruction set gets upgraded with practically every single generation of Intel and AMD processor.
RISCV, on the other hand...
A64 is part of ARMv8 which was announced in October 2011 and was a brand new instruction set. It is not compatible with legacy 32 bit ARM applications and doesn't carry the relevant technical debt.
RISC-V was announced in 2010. It may have many admirable qualities but claiming that it has the advantage of a newer architecture is not correct in this context.
Incidentally, I think one of the remarkable features of ARM's recent commercial success - generally completely unremarked on - is how they have, relatively seamlessly, switched users from legacy 32 bit to an new 64 instruction set.
or the arguments against an operating system in C instead of assembler years before that.
The licensing terms are what make risc-v interesting and the technical arguments won't stand the test of time.
Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the source and destination addresses. But for branch prediction reasons, and prefetching, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
There's a lot more that I can go into.
Those use cases work just fine with the shifts and adds trick you can do for multiply by constant. Honestly I was always baffled that ARMv6-M required a multiplier. Seemed to be the closest thing to an albatross over it's head, so much so that there were those M0's with an iterative, 32 cycle latency, bit serial multiplier.
> Even more baffling, is that the same extension that adds integer multiplication, also requires integer division, telling me that the spec authors think that multiplication and division are of the same circuit complexity, and used with the same frequency. And for one example for how goofy of an idea that is, ARM has never included integer division in its core ISA.
ARMv7-M (the closest ISA to Rv32-EM) requires integer divide.
> Then there's the whole JALR mess, which I don't know how to describe it other than "tech debt". Basically, they tried to simplify different kinds of jumps and returns into a single extension, by allowing any register to be used for the return address. But for branch prediction reasons, you really do want to have a single link register, so the spec says "please don't use anything other than x1 as the link register, or you might not get proper performance".
I don't really see this as a problem. For instance it neatly encodes unconditional jump without link as a jump with link to x0. Reminds me of some of the cute ways to encodes jumps from SH without being quite as ascetic.
> There's a lot more that I can go into.
Please do. Like totally unironically. I obviously have a pretty high opinion of RISC-V, but I appreciate someone who helps keep my biases in check.
I was under the impression that cores with only a hardware multiplier could emulate the division instruction.
From the ISA specification[1]: "RV32I can emulate almost any other ISA extension".
[1]: https://riscv.org/specifications/isa-spec-pdf/ (Chapter 2, RV32I Base Integer Instruction Set,)
And? Base RISC-V is meant to be as simple as possible; if you're designing an ultra-low power microcontroller you probably don't want a hardware multiplier, and you shouldn't be forced to have one. The "G" general purpose set of extensions is what you need for an application processor.
Something like RV64GC would be what most compiler writers would be targetting.
> telling me that the spec authors think that multiplication and division are of the same circuit complexity
Given the profiles of the spec authors I highly doubt this is the case; the number of modern cores which support hardware multiplication but not division is very small.
> Anybody that's written a compiler or even stared at assembly would tell you how prevalent integer multiplication is, for any sort of loop or pointer addressing.
For a loop you'll probably try to avoid as much multiplication as possible by transforming the induction variable to make it amenable to strength reduction.
I think those transform to an integer multiplication…like never? They're almost always an offset to a base pointer that's incremented as you go through the loop…
What's wrong with supporting a slow path? The alternative is to say x1 is always used, in which case you don't get the flexible, but more costly, alternative register variant, no?
Jokes aside the real reason why it's extremely unlikely is that they put a lot of money into ARM and they simply have no reason to switch to it. For this to happen ARM would need to do something like massively increase the price of their IP licenses, or simila. Which won't happen.
For all intents and purposes, RISC-V being open just puts it on the same footing for Apple as ARM is for them.
I heard somewhere that this year Intel was going to begin to phase out support for BIOS, which would allow Intel to eliminate CPUs booting up in "real mode".
I think as long as plain PCI is something supported, some sort of 16-bit support has to be in the firmware because of option ROMs. Though I'm not sure UEFI couldn't service those with some sort of emulation layer (may as well, UEFI's already complex enough).
Nothing prevents them slapping ARM frontend onto Zen
I would love an AMD MBP. Intel's chips have rapidly diminishing value for pretty much all use cases and AMD is firing on all cylinders with Dr Lisa Su.
Intel has already lost the mobile market, threw the towel in on the cellular chip market and sold the division to Apple, lost the console market to AMD, and the worlds largest cloud provider AWS has started selling access to both AMD and ARM servers at a much cheaper cost/cpu rate.
The education market is rapidly moving to ARM based Chromebooks.