TFA starts off with a piece of actual news and then veers off into rumors and unsubstantiated BS which is presented as facts.
>Apple is in the process of migrating its Mac line to ARM processors as it looks to reduce its reliance on Intel.
>Apple is in the process of migrating its Mac line to ARM processors as it looks to reduce its reliance on Intel.
1. There are articles that suggest Apple could move the Macbook, MacBook Air to their own ARM SoC, and leave the higher end MacBook Pro, Mac Pro, iMac on x86-64 for Professional Apps. In the case How is the Macbook different to iPad Pro with Keyboard? It is one thing to have a transition between two ISA, it is another thing to have the platform permanently on two ISA.
2. Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for use in iMac and Mac Pro CPU that runs from 100W to 220W. The Desktop Mac represent 20% of all Mac unit, that is roughly 4M. Majority of those are iMac, not iMac Pro or Mac Pro with high TDP.
3. If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
4. The rumours would have some ground before WWDC, but Apple just announced a monster Mac Pro. Catering for real Hollywood professionals and Rack Mount Mac Pro for Servers.
Yes, everyone believes it is coming, just like they believed the iPhone was coming, the iPad was coming, the Apple watch was coming.
There are enough news to support such rumors than there are news to discredit them.
But of course, there are stories like AirPower too.
- Cost
- Motherboard size
- Performance per watt
- Battery life
- Custom optimizations
I see no impediment to Apple running two CPU architectures in parallel for a decade. Arm for ultra-portables and base model Macs, Intel for mid/top spec macs.
Then eventually once the worldwide ecosystem becomes less x86 dominated, I could imagine Intel chips being a BTO option for people who need it, possibly even implemented as a secondary CPU available through a hypervisor.
But why does anyone really care about x86 vs ARM anyway? Assuming 100% of Mac software is recompiled, the only thing which would affect me is having Windows VMs with native speed... And I could easily replace that with a headless NUC and Remote Desktop.
Why is this a problem? Maybe they phase one of them out when they make the change? Or maybe leave them as slightly differentiated products like the jumble of different laptops they already have.
> Is Apple going to spend hundreds of millions a year just to invest into Mac Desktop / high performance CPU, for [Pro]
This seems like a number you just made up. Here is a comparison of last year's A12 ($50?) and a 2017 Xeon 8176 ($5K?):
https://www.reddit.com/r/apple/comments/9midcx/apple_really_...
> If Apple want to lower its reliance on Intel ( After it has all of its modem and wireless patents sort out with Intel ), why not just use AMD to leverages the price or switch to AMD. AMD gets the PR win for Apple using it, win win for both companies.
Well they're fed up with Intel and there's the price gap but the primary reason is that the chip performance is rapidly converging so there is a massive opportunity to create a unified platform. Further they've been able to create a year plus performance gap between themselves and the competition in mobile on a commodity platform and with third party fab - if they do the same thing in desktop the Mac platform could really take off and they could go after the console market too.
You will have R&D just for the high TDP CPU, you don't just magically scale up your Phone CPU and expect it to work in a Server / Workstation. And that CPU has comparatively small volume. I.e The Unit Economics does't work.
The only Unit Economics would work better is to follow a similar strategy as AMD, where you have a single die and they are replicated across the 45W to 220W product line. This is a small sub 100mm2 Die Size with 4M yearly unit. But that is excluding the complexity of I/O where EPYC had a 400mm2 I/O die.
https://news.ycombinator.com/item?id=20292762
1. MacOS and iPad are similar, but distinct user experiences. Its more than hardware (one with keyboard, one without), its about those differences in experience. Apple is nothing if not patient about introducing change to computing paradigms and experiences, so it's fine to co-exist for a while. Switching to ARM gives them better margins, better control over price, better control over physical chassis constraints, better control over features offered, access to a better chip team than Intel's, and now TSMC and/or Samsung's better EUV processes. E.g. features-wise, Intel still isn't shipping LPDDR4 chips, something the 4 year old iPhone 6S had.
2. Basically, x86 becomes a co-processor, just like how discrete GPUs are handled. This avoids having to compete with tiny sliver of market that wants Xeons.
3. AMD is a lateral move, with exactly the same lack of control over core technologies problem. Also AMD is historically not as reliable a supplier for volumes that Apple has.
4. See #2 and my comment. Also, they needed to intro Mac Pro to satisfy / shore up existing Mac contingent before they abandoned entirely. This is a multi-year journey.
That's become my hunch too in the transition to ARM, with Apple producing a SoC that integrates an entry level x86, with usual 2 upgrade options. Eg the next product line would be:
$1599 -- Dual-Core 1.5ghz A14 + Dual-core 1.2ghz x86
$1899 -- Quad-Core 1.9ghz A14 + Quad-Core 2.4ghz x86
$2199 -- Quad-Core 2.5ghz A14 + Quad-Core 2.7ghz x86
I think they will take a different approach. Put a decent keyboard on a future iPad Pro. Make iOS more like macOS. And then they'll eventually kill macOS.
So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common.
I also need a Windows VM quite frequently for the odd program that only runs in Windows, or if I need to run Visual Studio one day. Windows is also very important for me to keep around so I can test software products in the same environment as other windows users, and there are definitely a handful of windows users out there.
Sure there may be alternative options in both areas but I'm not interested in solutions that work 80% of the time. I can't let my development environment get in the way of my work.
With that said, I sincerely doubt Apple will kill x86 wholesale overnight. I'm guessing there will be a transitional period of quite some time.
Also, windows has been doing a ton of work around getting onto arm. I managed to test on my rpi 3, and it was pretty good. it would probably be very doable.
Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers.
Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market.
Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.
Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS.
TLS is in just about everything.
You really need to develop and QA on the expected deployment platform
Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others.
It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production.
Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path.
Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten.
Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.
There are, of course, many Docker repositories that lack ARM images, and you couldn’t use the exact same build locally as in production, but I think those are not actually huge, unresolvable issues. (The latter is straight up a non-issue with a good CD pipeline.)
Windows 10 also runs on ARM platforms, with the ability to transparently emulate Intel. I’m sure this is or will be usable inside of VMs even if dual booting is not an option.
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
Video decoding/encoding is handled by a VPU (not GPU), HDMI is handled by a separate HDMI PHY, and most of these components have mainline, libre kernel support if you use an Allwinner based single board computer.
Microsoft has started branding some Mali GPUs as DirectX 11 capable, though YMMV on using these features.
I'm not sure thats true. At the very least its going to suck for the first year as gaps are being filled, but those differences might matter too. I would hate to have to duplicate every single Dockerfile just because of this, as engineering orgs are typically heterogenous (win/lin/mac).
Few images should need Dockerfile changes unless they are bootstrapping from scratch. People are already using Docker and Kubernetes on Raspberry Pi and other small ARM devices.
A clear message that's been coming from Apple over the past few years is that developers are not a market they care very much about. I strongly suspect a lot of us won't be using Macs for development in the future.
The list you added to your post is a good example of this - all those apps are examples of things that had a community outside of the app store before they had iOS versions. They're not good or successful because of Apple, but in spite of Apple.
Really sounds like they have some detailed knowledge, but yeah, no source is mentioned.
https://www.bloomberg.com/news/articles/2018-04-02/apple-is-...
EDIT: I think you may have been referring to the 9to5mac article- I'm going to leave this comment here, but the current article is way more specific.
Has that calculus changed in the meantime?
Then again Apple was also the other partner (with Acorn) in founding ARM.
https://en.m.wikipedia.org/wiki/Apple%27s_transition_to_Inte...
Regardless, that makes the financial calculus even more suspect as they would have even fewer units to amortize the cost over. But I don't work for Apple, and quite frankly the CPU market could certain use the injection of some more competition.
Quite the opposite. Apple, according to the book The Race for a New Game Machine, was an unprofitable demanding customer. The scale of the XBox 360 and PS3 dwarfed Apple's usage and IBM made several decisions that were contrary to Apple's needs. PowerPC for the embedded market has been the primary driver of PowerPC development.
I'm glad Apple opted to move to Intel then. The Cell is the hardest thing I ever tried to write code for.
Intel is behind on process and has been for a couple of generations right as everyone hits a process wall.
For the first time since I got into computers in the late 80s Intel looks vulnerable.
As to whether Apple would go ARM on a MacBook who knows, I’d guess they wouldn’t but they could straight buy AMD in cash so it’s not beyond the realm they could tool up for desktop class ARM.
I can't help but think there must be some secret benefit to make them pursue such a risky endeavour for something so tangential to their comparative advantage. Apple doesn't sell custom components, they sell consumer experiences. They must be planning on going a completely different direction with iOS to warrant custom processor technology.
How is this risky?
At least, that's according to what I've read about it.
The cross licensing deal (of AMD on x86) with Intel would be off. Pretty much AMD is not sellable in this regard.
AMD could produce/design an ARM chiplet, attached with infinity fabric to their Zen2.
But now, Moore's law is in the process of hitting a brick wall. Those big wins for free just aren't there. And if there's a x86 to arm JIT, it's either going to be single core, or the arm cores are going to have to have a stronger x86 like memory model, thus negating a huge part of their architectural win.
IMO, Apple's going to make their own x86 chips because the base x86_64 patents are going to expire real soon now, and they have enough patents from the crazy amount of fabless acquisitions to potentially cross license the rest.
Processors are commodities now, and that's really going to shake things up in crazy ways.
This simply isn't true, it wasn't until the G3-300 was released that the 68k emulator could run 68k code at 40MHz comparable speeds, and that was after 10 years of ppc601s and 603s running 68k system binaries at slower than quadra speeds on 180 and 200MHz processors.
Neither part of that statement is true. I had an LCII with a 68030-40Mhz card before upgrading to a 6100/60. The 6100/60 (601-60Mhz processor with a half speed bus) was much slower running 68K software than my LCII. It was about the same speed once I bought SpeedDoubler.
Also, between the slower bus, the slow shared graphics memory and System 7 on the PPC being emulated, it felt much slower than a decent 486-DX2/66 or a Pentium-60.