Apple aims to sell Macs with its own chips starting in 2021

That said, the experience of trying to browse a local newspaper's website with NoScript turned off on my 2015 MacBook Pro tells me that, yes, JS on shitty websites is a problem. And not one that most people would find to be particularly avoidable. Heck, even GMail is getting to be noticeably slow on that computer.

The A12X from 2018's iPad Pro is the sort of chip I'd expect to see in an ARM laptop, and its multicore scores are similar to the top end of 2018 Macbook Pros.

2020's iPad revision didn't get much in the way of processor improvements (just one more GPU core), so the new 16" MBP has pulled ahead with an 8-core i9, but when we get a new iPad based on an A13X or A14X I expect it to be back in that range again.

And these are in thin fanless tablets. With a proper cooling system, there's got to be some extra juice to be squeezed out of them.

That's, if you'll pardon the pun, an Apples to Oranges comparison. Apple isn't making "high end ARM chips" either if your comparator is powerful servers. You need to look at what Apple is doing within their power envelope and compare that to what everyone else is doing within _their_ power envelopes. The A13 Bionic is an uncooled 6W TDP chip blowing past 95W base TDP chips that require hefty active cooling.

I'm typing this with a Surface Pro X running a ARM64 CPU called SQ1 which a customization of a Snapdragon 8cx. It is quite high end and is not made by Apple. It might not be the amazing custom CPUs they have on iOS devices but it is still a pretty good CPU.

You're not wrong. In general, it's true that a microbenchmark amplifies the Apple A13's strengths due to power limits. The assumption I make is that microbenchmarks indicate the true peak performance of Apple's architecture, and as power limits become a smaller constraint when Apple uses its chips in laptops and desktops they will make available that performance in a more sustained way.

But even low power Intels don't compare that favourably. Intel's new i7 10510U delivers very nice single core performance [1]. But it's worth noting that 1) that still does not quite match the A13's burst performance 2) that chip is still rated for a power profile much larger than the A13's and 3) as always in these discussions - Intel's "TDP" is a marketing term not a power limit. At high turbos the chip is permitted to consume quite a bit more power than the 15W it's rated for.

This particular Intel chip boosts to 4.90GHz. For Apple chips, even stuff like clockspeeds are a matter of conjecture, but Wikichip without a source claims that the A13 tops out at 2.65GHz [2] which if true indicates a lot more thermal and frequency headroom in bigger form factors.

I just benchmarked my MacBook Pro+Safari in Jetstream 2.0 [3] - not a microbenchmark - and it scored nearly 145 compared to the nearly 130 the iPhone 11 scores [4]. That's with a "45W TDP" Core i7 8850H topping out at 4.3GHz. It's hard to benchmark iPhones well, but all evidence points to the fact that they are actually really fast.

[1]: https://browser.geekbench.com/v5/cpu/search?utf8=%E2%9C%93&q...

[2]: https://en.wikichip.org/wiki/apple/ax/a13 - worth noting that high-end Qualcomm SoCs also operate at comparable frequencies.

[3]: https://browserbench.org/JetStream/

[4]: https://www.anandtech.com/show/14892/the-apple-iphone-11-pro...

One of those 'few other' was Scaleway, but they recently buckled up and ended their ARM server lineup abruptly[1]. They were running Marvell ThunderX SoCs(Upto 64 cores, 128GB RAM).

So, Amazon might soon takeover ARM server market i.e at-least till Tim Cook does a Satya Nadella and brings in Apple IaaS with ARM CPUs.

[1]https://news.ycombinator.com/item?id=22865925

The conclusion of your article is precisely about how motherboard manufacturers don't obey the official/nominal behavior and how that makes it irrelevant:

> Any modern BIOS system, particularly from the major motherboard vendors, will have options to set power limits (long power limit, short power limit) and power duration. In most cases, at default settings, the user won’t know what these are set to because it will just say ‘Auto’, which is a codeword for ‘we know what we want to set it as, don’t worry about it’. The vendors will have the values stored in memory and use them, but all the user will see is ‘Auto’. This lets them set PL2 to 4096W and Tau to something very large, such as 65535, or -1 (infinity, depending on the BIOS setup). This means the CPU will run in its turbo modes all day and all week, just as long as it doesn’t hit thermal limits.

Intel desktop processors will sustain boosts for an arbitrary amount of time. Yes, they will exceed the nominal TDP while doing so, so do AMD processors (AMD's version of "PL2", which they call the "PPT limit", allows power consumption up to 30% higher than the nominal TDP while boosting, and there is no official limit to how long this state may occur).

These limits are of course observed much more strictly on laptops since power/thermal constraints actually make a real-world difference there. But overall, Ice Lake perf/watt is competitive with Renoir and its IPC and per-core performance is actually higher than Renoir. You just get fewer cores.

Whereas other PC shops typically will just throw PCs together and assume they'll fix issues found in patches.

That's not going to fly for "just works" Apple product image - and why it's positioned and priced as a "luxury" product.

https://news.ycombinator.com/item?id=12816474

https://news.ycombinator.com/item?id=16130872

https://news.ycombinator.com/item?id=13364583

Don't bother with the links, the comments are more informative. In some of the comments people explain why it's Intel's fault and not Apple, in some comments people explain processor speeds. A lot of it is about the keyboard that they changed, but that is not related to this. My point was more that I think Apple should put the amount of effort into their laptops that they did in 2009, whether or not they do is subjective until we see their new processors.

Would love to learn more from sources if people might provide a newb an intro.

It's not trivial to port x86 software to ARM, or even run an energy efficient emulator.

Is that correct?

Just use compiled, strongly typed languages.

No: Javascript, Python, PHP, Ruby Yes: Java, C#, C, C++, Rust.

Unfortunately, the majority of users seem conditioned to accept software with awful performance, so there's no impetus for developers to upgrade their skills.

Hardware is fast and cheap, and it's getting even faster and cheaper. It's perfectly fine to utilize this power, if it makes developing products faster, easier or cheaper.

Now, there are still cases when you need to send a machine to roam the mountains of another planet. This may justify doing some assembly.

Anandtech architecture reviews are helpful, as always. Worth reading for a page or two from the linked page:

https://www.anandtech.com/show/14892/the-apple-iphone-11-pro...

https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re...

The short of it is: massively wide execution units, massive amounts of SRAM, massive amounts of cache at all levels. There's no real "secret sauce", they're just willing to pay to make an incredibly fat core and Qualcomm and company are not.

They have 16 MB of system cache on A13 for 2 high-performance and 4 low-performance cores, which is as much as a 9900K gets for 8 cores and as much as Zen2 gets for 4 cores. Plus another 8MB per big core on top of that (so up to 24MB per core in single-threaded mode), and 4 MB per small core.

It helps that they're a vertically-integrated company, they don't have to sell their processors on the open market at competitive prices such that an OEM can also make a profit selling a finished product at competitive prices, they just sell the finished product.

I've thought for years that the overhead of the extra decoder hardware and legacy cruft was non-trivial (though Intel claims that's not true). The evolution of ARMv8 (where ARM went much closer to it's RISC roots) seems to disagree. This explains the performance per watt issue (and potentially some IPC).

That said, scaling IPC (instructions per clock) seems to have a pretty big limit. x86 has basically hit a wall and it's been lots of time and research for small gains. Additionally, the biggest challenges in large systems is that the cost to do a calculation on some piece of data is often less than the cost to move that data to and from the CPU. As Apple increases cache size, frequency, and starts dealing with bigger interconnect issues, I suspect we'll see a distinct damper on their performance gains.

Qualcomm (and ARM as the designers of the core) has a very different problem to solve. They can't make money off of software. They make money when they sell new chips and they make more money from new designs than from old ones. This means incremental changes to ensure a steady revenue stream. Since Apple having a fast, proprietary CPU doesn't actually affect Qualcomm or ARM, they most likely don't even see themselves as in direct competition. Most people buy Android or iOS phones for reasons other than peak CPU performance and Qualcomm is fairly competitive with a lot of these (esp actual power usage).

A further complication is that they also need "one design to rule them all". They can't afford to make many different designs, so they make one design that does everything. Apple doesn't need to spend loads of time and money trying to optimize the horrible aarch32 ISA. Instead, they spend all that time on their aarch64 work. ARM and Qualcomm however need to add that feature so the markets that want it still buy their chips.

Apple shipped their large 64-bit design only a couple years after the ISA was introduced. Put simply, that is impossible. It takes 4-5 years to make a new, high-performance design. It took ARM 3 years for their small design (basically upgrading the existing A9 to the new ISA) and closer to 4.5 years to actually ship their large design (A57) and another year for a "fixed design (A72, though it's actually a different design team and uarch). Though the gap has been closing, 2.5 years in the semicon business is an eternity.

A crufty ISA and non-CPU scaling problems seem to explain Intel/AMD. A late start, bigger market requirements, and perverse incentives against increasing performance seem to explain ARM/Qualcomm

The 5775c (https://wccftech.com/intel-broadwell-core-i7-5775c-128mb-l4-...) was a good example of a no-compromises (from a cache standpoint) CPU from Intel that just annihilated their other CPUs at the time... it's not that hard to do, provided you're willing to pay the price for it somewhere else.

Apple provides brief windows of automated compatibility, but code untouched since 2003 won’t run on a mac today, and code untouched since 1986 wouldn’t run on a 2003 mac.

It's not really a difficult concept to understand. If your CPU runs at 5GHz then maximum time a single cycle is allowed to take is 0.2 nanoseconds. CPU designers have to make sure that this limit is never exceeded anywhere on the chip. If you make a even the slighted mistake in some unimportant corner of the CPU you will end up limiting the maximum performance of the entire CPU.

Most CPUs are optimized for a specific clock frequency and going beyond it is not possible without sacrificing stability.

The platform ended up failing, but they spun out ARM. If ARM end up overtaking Intel on the desktop, it gives the story some entertaining irony/symmetry.

I think that's the fundamental mistake in reasoning:

If ARM is cheaper for AWS, then AWS has no reason at all to offer it to its customers at a discount because the customers will not move if no discount if offered. As long as there's no mass market for ARM PCs/servers that work with all the modern software that anyone can rack and sell a-la ServInt/Erols/EV1 circa 1996 there won't be pricing pressure.

This has played time and time again in transit pricing.

Actually more that they bit way more than they could chew when they started the original 10nm node, which would've been incredibly powerful if they had managed to pull it right. But they couldn't, and so they stagnated on 14nm and had to improve that node forever and ever. They also stagnated the microarch, because Skylake was amazing beyond other (cutting corners on speculative execution, yes), so all the folowing lakes where just rehashes of Skylake.

Those were bad decisions that were tied to Intel not solving the 10nm node (temember tick-tock? Which then became architecture-node-optimztion? And then it was just tick-tock-tock-tock-tock forever and ever), and insisting on a microarch that, as time went by, started to show it's age.

Meanwhile AMD was running from behind, but they had clearly identified their shortcommings and how they could effectively tackle thme. Having the option to manufacture with either Global Foundries or TSMC was just another good decision, but not really a game changer until TSMC showed that 7nm was not just marketing fad, but a clearly superior node than 14nm+++ (and a good competitor to 10nm+, which Intel still is ironing).

That brings us to 2020, where AMD is about to beat them hard both on mobile (for the first time ever) and yet again on desktop, with "just" a new microarch (Zen 3, coming late 2020). The fact that this new microarch will be manufactured on 7nm+ is just icing on the cake, even if AMD stayed in the 7nm process they'd still have a clear advantge over Zen 2 (of course, their own) and against anything Intel can place in front of them.

That brings us to Apple. Apple is choosing to manufacture their own chips for notebooks not because there's no good x86 part, but because they can and want to. This is simply further vertical integration for them. And this way the can couple their A-whatever chips ever more tightly with their software and their needs. Not a bad thing per-se, but it will separate even more the macs from a developer perspective.

And despite CS having improved a lot in the field of emulation, cross compilers, and whatever clever trick we can think of to get x86-over-ARM, I think in the end this move will severely affect software that is developed multiplatform (this'd be mac/windows/linux, take two and ignore the other). This is some slight debacle that we've seen with consoles and PC games before.

PC, Xbox (can't remember which) and PS3 were three very different platforms back in 2005-ish. And while the PS3 held a monster processors which was indeed a "supercomputer on a chip" (for it's time), it was extremely alien. Games which were developed to be multiplatform had to be developed at a much higher cost, because they could not have an entirely shared code base. Remember Skyrim being optimized by a mod? That was because the PC version was based on the Xbox version, but they had to turn off all compiler optimizations to get it to compile. And that shipped because they had to.

Now imagine having Adobe shipping a non-optimized mac-ARM version of their products because they had to turn off a lot of optimizations from their products to get them to compile. Will it be that Adobe suddenly started making bad software, or that Adobe-on-Mac is now slow?

Maybe I got a little ranty here. In the end, I guess time will tell if this was a good or a bad move from Apple.

Me too. But if the apps I need don't come to ARM, I don't care too much about ARM on the desktop/laptop/workstation.

I think you make a key point here. A whole lot of code now runs inside one runtime or another, and even outside of that, cross-architeture toolchains have gotten a lot better partly thanks to LLVM.

The instruction set just doesn't matter even to most programmers these days.

And the move to ARM isn't guaranteed to bring them more sales. Customers might dislike it and software makers might dislike it.

It sounds nice in theory but in practice is hard. Writing CUDA or OpenCL is not exactly pleasant or easy and compilers do a poor job at vectorizing code.

Se we use accelerators when it's an absolute must.

They are mainly polishing things.

>Nobody followed them last time.

Breaking compatibility with software and operating systems and hardware is bad for the consumer.

With x86 I can run any software I need and I can optimize for cost and performance. I can use diverse CPUs, use graphic cards, memory chips, cases, PSUs, SSDs and HDDs from different makers at different price points and performance points.

I can hit exactly the sweet point I need to. And if something breaks, it won't be hard to replace.

I'm not a developer so forgive my ignorance, but isn't this what cross-compiling is for? I get that compiling natively can increase performance and find obscure hardware issues, but it's my understanding that, for example, ARM builds of GNU/Linux binaries are just cross-compiled by server farms that are also natively compiling the AMD64 builds.

Also, fat binaries and JIT emulation have been a thing forever, especially for Apple who has dealt with these changes twice now (68k -> PPC -> x86-64).

I just don't see this being any different than current multi-platform efforts like Debian, NetBSD, etc., except it's a for-profit company with billions of dollars and thousands of expert employees behind it.

I mean, I suppose it depends on what sort of development you're doing, but in 2020 most libraries do work on ARM. There'll no doubt be a painful period (as there was with the death of PPC), but it shouldn't be that dramatic.

At least both architectures are 64 bit little endian, so all those buggy C programs that do illegal type casting might still work.

One issue might be that X86 is pretty relaxed when it comes to unaligned memory accesses. I'm not sure how ARM64 handles it.

Every architecture switch has casualties, what I feel might be shortsighted by Apple this time is the x86 Cocoa apps that die this time are not going to be replaced by Catalyst iPad ports or ARM builds, they'll be replaced with Electron apps.

Granted, the move to ARM is a bit more work, but again I don't think anyone should be especially surprised by it. As soon as the "A" processors started posting real, positive benchmark numbers I figured that Apple would move to them and away from Intel. In my minds eye I can see Apple differentiating machines depending on how many ARM chips it has. MacBook Air - 2 A15; MacBook - 4 A15X; MacBook Pro - 12 A15X; Mac - 128 A16X (or something like that)

Anything external will suffer, and apple probably aren't gonna cry about that.

I get the point you're trying to make, but unless you owned both the last PPC mini and the first Intel mini at the same time, as I did in 2006 (and still do), you have no idea what you're talking about.

I prefer to use a local box for faster feedback. But even if someone would prefer using a remote box, they can also use a Windows laptop to do the same thing.

But even for software that is available cross platform, or that has comparable equivalents, the app could be the greatest thing since sliced bread, that can't fix the cluster fuck that is windows.

Edit: I should add: I haven't tried a Linux desktop in quite a while (I use Debian servers on a daily basis). Maybe it's gotten better, but given the number of "hey cool, it uses Electron so that means there'll be a Linux version" comments I see, I'm not really that optimistic.

Yes, but then you have to run Windows or Linux.

I think that people don't (on the whole) get Macs in order to run particular software, but many (myself included) do get Macs in order to run MacOS. (Silky smooth trackpads don't hurt, either.)

Is there a good machine that allows me to run an ok operating system with command line that has fewer software limitations (Linux) and doesn't feel unpredictable and sometimes broken (Windows)?

I use Linux. I like Linux. But sometimes some mainstream software won't run there. A VM helps but doesn't solve everything.

Don’t forget that “Apple‘s software” includes utilities like Preview, Spotlight, Finder, the screenshot utility, and even System Preferences where Microsoft isn’t delivering a competent alternative. Let me know when enabling or disabling a network card doesn’t dump me into the Windows Vista Control Panel in a completely separate window.

And Windows still updates itself too much. It’s infuriating. The whole concept of active hours sucks. Microsoft’s “solution” to their update nightmare is to make you keep your computer on all the time. Every time I fire up my gaming PC it wants to update and hijacks my ability to shut down or restart. They should have a “consumers who don’t give a shit about KB1234567 .NET 3.5 patch” channel that releases no more frequently than monthly or maybe even quarterly.

Then if you own an iPhone like half the USA and are already interested in a laptop that costs at least $999 it’s really hard to look away from the Mac.

Considering that smartphones are more important to most people than their laptops, including many people that use laptops for a living, it shouldn’t be surprising that macOS is such a compelling option. My laptop is now basically just for work while my phone is my “PC” - my personal computer.

And in that sense iOS is a driver as a reason to use macOS. I’m not going to give up Handoff and AirDrop just to save a few bucks - and which Android phone costs $399, has the fastest available processor, has a solid camera, and will get 5+ years of software updates?

I run basic software like a browser, command-line tools, editors, a few IDEs - it's all completely cross-platform stuff - and I think it's worth getting a Mac for that. I don't know any better hardware for personal computing. What do you use that's better designed, integrated and constructed?

The fact that most software nowadays are cross platform and run on Mac is actually an improvement from earlier situation! (Gaming is lagging behind because of DirectX and other windows only engine)

For designers not on Figma: Sketch, OmniGraffle, Principle, xScope and a fully featured OS color picker and palette manager that works across all apps.

As a developer, I wouldn't want to miss: Paw, Alfred, iA Writer, Monodraw and Kaleidoscope.

A niche favorite that really has no analogues at all: Lumen video synthesizer

Only the design stuff is probably in the "worth getting a Mac for" category though.

If you hadn't included that restriction, I'd tell you about Numbers. Not all spreadsheet type problems fit into its limitations, but for those that do, it makes you ask "Why don't all spreadsheets work this way?"

But you did make that a restriction on your criteria, so forget I said anything. :)

The first non-Apple software I thought of when you asked the question was PDFpen, which operates vaguely like what is now called "Acrobat DC" used to. Acrobat drives me up a wall; it's like they asked, "How can we make the Microsoft ribbon interface even worse? Let's do that!"

I have about three Markdown editors that are Mac-only that I like better than any cross-platform alternative I've tried. (Byword, Markdown Pro and MultiMarkdown Composer.) I have three because none of them does everything right, so I occasionally have to switch for some task or other. I'd happily switch to something cross-platform if it matched the union of those three apps' features, those I care about, anyway.

I suspect I have three solid Markdown editors to choose from because they're all based on solid OS-level rich text editing features that exceed what you get on Windows, so the non-Mac competition has to waste a lot of resources reinventing wheels. Just as one example, you get grammar checking for free in most Mac native text-editing software. Where it doesn't occur, it's usually because the app is cross-platform and is thus avoiding Mac-specific features.

A related example is the built-in dictionary. You can get dictionary/thesaurus apps on other platforms, but they generally aren't as deeply integrated as the one on macOS.

Then there are the times where you have a cross-platform app that simply works better on macOS. VLC and MacVim (as compared to gVim) come to mind.

do you mean talk time or standby? Because I do not remember this.

Seems much more likely we just used our "single-app" mobiles WAY less. Maybe you were on cellphone calls 4-6 hours a day? But I do not remember any cell phone in the 90s and early 2000s that had a 30+ hours talk-time (plus 150 hours of standby).

While Apple did definitely go down that road in 2016, since then MBP batteries have grown year on year back to the maximum (any bigger and they wouldn't be allowed on planes).

The iPhone has gotten thicker and heavier year-over-year for every year since the iPhone 6, mainly due to monotonically-increasing battery capacity, and the new MacBook Pros are also thicker, heavier and with a bigger battery than the outgoing ones too. I'm not sure where this "they always make it thinner and cut battery capacity!" meme comes from.

That and hackintoshes are becoming more common. You can't maintain your profit margins if they become too normal.

only for old CPUs. Also non-T2 chipset support probably will be discontinued too.

Anyway, Hackintosh shutdown it's matter of time, 'cause Apple naturally cares about his closed ecosystem.

That sounds like an absolute nightmare. Imagine having to track down a bug that only appears after your program has gone through cross compilation on Apple's servers.

Multi-arch "fat binaries" have been the norm much more recently than that. For a long time, typical macOS binaries supported both 32-bit and 64-bit x86.

Likewise, fat binaries are used to support the various different ARM variants on iOS devices (armv7, arm64, etc).

The ARM-based laptop will be the iBook (following iPad, iPhone patterns).

My best guess ...

I'm happy reading their opinion pieces (by matt levine) but I see no reason to not dismiss their usual lets-see-if-we-are-right stuff.

That was a piece of bad reporting that claimed widely spread threats to international security

Funny I should run into you again, though. A couple days ago I replied to you when you were arguing Vox is reputable even though their reporting on COVID-19 was just flat out wrong.

Looks like you are pretty forgiving to news outlets, if not just gullible.

The normal iPad is quite popular with musicians, a bigger one could be neat for that too.

Outside of the silky OS and tight Linux coupling, it has been a joy to buy computers (albeit at a premium) that last more than 2 years.

I still have a 2009 iMac that is perfectly fine for everything except iOS development (due to an Xcode OS minimum) and a 2015 MBP for that. While my new work 16 MBP is a performance beast compared to the 2015 MBP, I can certainly be productive and expect to be for years to come with my personal kit.

One of the issues back in the PPC days was lack of applications on Macs. Partially due to the chip, as more apps supported Intel architecture. As soon as the switch to Intel happened it made porting existing software much easier.

Assuming they move to ARM. I would bet my morning coffee that the plan is to merge iOS and OSX then start porting over mobile apps into the desktop system as opposed to requiring existing software packages to rewrite desktop software for the new platform.