Linus Torvalds says ARM just doesn't look like beating Intel

[David Hess]

Apple have long unified the code base of macOS and iOS - they just need to ship an ipsw file for iPad Pro with a full installation of OS X in it, and ship a new release of Xcode enabling the existing aarch64 toolchain on macOS SDK, and you get an ARM-based laptop running OS X in the existing iPad Pro hardware, and app developers will get the apps ready in about an hours of time.

And you got it right about the code - it is one recompile away from universal compatibility. Apple have done quite a good job at keeping the software layers coherent across different hardware platforms so far, so it is pretty much that as long as you keep clear of lower layers of IOKit, the code is identical across all platforms.

I would enjoy watching them try this.  There are enough low level differences like page size between x86 and Apple's implementation of 64 bit ARM to cause major performance problems if not outright failure and Apple's proclivity to lower amounts of system memory will make this worse.

[technix]

Apple have long unified the code base of macOS and iOS - they just need to ship an ipsw file for iPad Pro with a full installation of OS X in it, and ship a new release of Xcode enabling the existing aarch64 toolchain on macOS SDK, and you get an ARM-based laptop running OS X in the existing iPad Pro hardware, and app developers will get the apps ready in about an hours of time.

And you got it right about the code - it is one recompile away from universal compatibility. Apple have done quite a good job at keeping the software layers coherent across different hardware platforms so far, so it is pretty much that as long as you keep clear of lower layers of IOKit, the code is identical across all platforms.

I would enjoy watching them try this.  There are enough low level differences like page size between x86 and Apple's implementation of 64 bit ARM to cause major performance problems if not outright failure and Apple's proclivity to lower amounts of system memory will make this worse.

For an app developer all those low level differences are masked. In fact the developers are strongly advised not to perform low-level access and always go through their API, and any app that requires low level access are long banned from the App Store. So as long as Apple can make sure that their API doesn't suffer from those differences, 99% of the apps are not going to be affected.

[janoc]

No-one would set out to make a new design with such a complex set of instructions today. The x86 architecture will endure as long as legacy support is required but it may be that a RISC cpu may be made to translate all but the most frequently used x86 instructions into calls to a software routine that emulates x86 instructions with a set of the native RISC instructions.

Which is, coincidentally, pretty much what the Intel microcode does. The x86 instructions are basically "emulated" already.

[David Hess]

I would enjoy watching them try this.  There are enough low level differences like page size between x86 and Apple's implementation of 64 bit ARM to cause major performance problems if not outright failure and Apple's proclivity to lower amounts of system memory will make this worse.

For an app developer all those low level differences are masked. In fact the developers are strongly advised not to perform low-level access and always go through their API, and any app that requires low level access are long banned from the App Store. So as long as Apple can make sure that their API doesn't suffer from those differences, 99% of the apps are not going to be affected.

Did I say low level access? I was referring to low level differences.  MMAP and memory allocation are impacted by the page size.

Unless you mean that Apple discourages anything involving memory allocation.  That would be fun also.

99% of applications may not be affected, and I think that is optimistic, but the 1% which are will be unusably slow.  Keep in mind that we are discussing desktop applications running on ARM64 and this problem will exist even without emulation.

There is a discussion thread over on RWT about this issue with Apple's design choices.

[technix]

I would enjoy watching them try this.  There are enough low level differences like page size between x86 and Apple's implementation of 64 bit ARM to cause major performance problems if not outright failure and Apple's proclivity to lower amounts of system memory will make this worse.

For an app developer all those low level differences are masked. In fact the developers are strongly advised not to perform low-level access and always go through their API, and any app that requires low level access are long banned from the App Store. So as long as Apple can make sure that their API doesn't suffer from those differences, 99% of the apps are not going to be affected.

Did I say low level access? I was referring to low level differences.  MMAP and memory allocation are impacted by the page size.

Unless you mean that Apple discourages anything involving memory allocation.  That would be fun also.

99% of applications may not be affected, and I think that is optimistic, but the 1% which are will be unusably slow.  Keep in mind that we are discussing desktop applications running on ARM64 and this problem will exist even without emulation.

There is a discussion thread over on RWT about this issue with Apple's design choices.

On iOS you are not even supposed to call malloc(3) or mmap(2) directly. You should create objects instead for local storage, and there is absolutely nobody you can IPC with through shared memory.

[David Hess]

On iOS you are not even supposed to call malloc(3) or mmap(2) directly. You should create objects instead for local storage, and there is absolutely nobody you can IPC with through shared memory.

Were we discussing iOS?  I thought this was about OSx and desktop applications on ARM64.

Apple have long unified the code base of macOS and iOS - they just need to ship an ipsw file for iPad Pro with a full installation of OS X in it, and ship a new release of Xcode enabling the existing aarch64 toolchain on macOS SDK, and you get an ARM-based laptop running OS X in the existing iPad Pro hardware, and app developers will get the apps ready in about an hours of time.

This just makes the discussion I linked to more relevant if Apple's operating systems are as screwed up as Linus suggests.  One of the posts discusses performance loss between 1 and 2 orders of magnitude (!) just because of the page size problem and how the TLBs are handled.

Can Apple leverage OSx on ARM64 to replace x86 when their laptop and desktop market is such a small part of their business?  Would this even make sense?

Historically the companies which have tried to do what Apple may attempt failed at it miserably because of performance problems.  DEC Alpha looked fine on benchmarks until real applications used real memory.  I think IBM had the same problem at least once and did not manage to solve it.

And on the hardware side there is still no ARM64 (or ARM32) system standard so it is not ARM64 (or ARM32) versus x86; it is Apple's ARM64 versus x86 so there is no economy of scale or network effects to take advantage of.

[timb]

On iOS you are not even supposed to call malloc(3) or mmap(2) directly. You should create objects instead for local storage, and there is absolutely nobody you can IPC with through shared memory.

Were we discussing iOS?  I thought this was about OSx and desktop applications on ARM64.

Apple have long unified the code base of macOS and iOS - they just need to ship an ipsw file for iPad Pro with a full installation of OS X in it, and ship a new release of Xcode enabling the existing aarch64 toolchain on macOS SDK, and you get an ARM-based laptop running OS X in the existing iPad Pro hardware, and app developers will get the apps ready in about an hours of time.

This just makes the discussion I linked to more relevant if Apple's operating systems are as screwed up as Linus suggests.  One of the posts discusses performance loss between 1 and 2 orders of magnitude (!) just because of the page size problem and how the TLBs are handled.

Can Apple leverage OSx on ARM64 to replace x86 when their laptop and desktop market is such a small part of their business?  Would this even make sense?

Historically the companies which have tried to do what Apple may attempt failed at it miserably because of performance problems.  DEC Alpha looked fine on benchmarks until real applications used real memory.  I think IBM had the same problem at least once and did not manage to solve it.

And on the hardware side there is still no ARM64 (or ARM32) system standard so it is not ARM64 (or ARM32) versus x86; it is Apple's ARM64 versus x86 so there is no economy of scale or network effects to take advantage of.

I dunno, Apple seamlessly switched from m68k to PPC to x86 to x64 already, so... They certainly have the track record!

In fact, I guarantee you Apple has had macOS running or ARM for *at least* the last 5 years. (Apple secretly had Mac OS X 10.0 to 10.4 running on Intel, so they could easily switch if IBM couldn't follow through with performance commitments. This ended up being a very good decision.)

Right now you can use the same code base to target iOS and macOS (obviously each platform will use different UI and input code). So, there should be no reason why, if Apple releases macOS for the iPad Pro, that Xcode couldn't push out a fat binary that targets both ARM64 and x64. Hell, I could even see them resurrecting Rosetta to do binary translation so you can run existing x64 apps!

If anyone could pull this off, it's Apple.

[David Hess]

I dunno, Apple seamlessly switched from m68k to PPC to x86 to x64 already, so... They certainly have the track record!

In fact, I guarantee you Apple has had macOS running or ARM for *at least* the last 5 years. (Apple secretly had Mac OS X 10.0 to 10.4 running on Intel, so they could easily switch if IBM couldn't follow through with performance commitments. This ended up being a very good decision.)

Right now you can use the same code base to target iOS and macOS (obviously each platform will use different UI and input code). So, there should be no reason why, if Apple releases macOS for the iPad Pro, that Xcode couldn't push out a fat binary that targets both ARM64 and x64. Hell, I could even see them resurrecting Rosetta to do binary translation so you can run existing x64 apps!

I will stipulate all of the above but performance was never a reason to switch to or stay with Apple.  They were always competing for only their own users.

If anyone could pull this off, it's Apple.

More likely if anybody could screw up making Apple ARM64 the new desktop and server standard, it is Microsoft.  And then Linux would have to drop the ball as well.

[tooki]

I wouldn't be surprised if we saw an ARM based laptop running OS X from Apple in the next few years. Sell it for ~$600. They've got the software infrastructure in place to do it; basically they could flip a switch in Xcode and have it produce x64/ARM64 fat binaries. […]

The reverse (cross-compiling iOS apps for Intel) is already commonplace: the iOS Simulator in Xcode isn't an ARM emulator, it's actually a host for native x64 code. Xcode actually compiles an Intel binary which runs natively on the Mac's Intel CPU. I'm not a developer at all, but my understanding is that this is highly effective for almost all testing except for performance profiling, which of course has to happen on an actual hardware iOS device.

[technix]

I wouldn't be surprised if we saw an ARM based laptop running OS X from Apple in the next few years. Sell it for ~$600. They've got the software infrastructure in place to do it; basically they could flip a switch in Xcode and have it produce x64/ARM64 fat binaries. […]

The reverse (cross-compiling iOS apps for Intel) is already commonplace: the iOS Simulator in Xcode isn't an ARM emulator, it's actually a host for native x64 code. Xcode actually compiles an Intel binary which runs natively on the Mac's Intel CPU. I'm not a developer at all, but my understanding is that this is highly effective for almost all testing except for performance profiling, which of course has to happen on an actual hardware iOS device.

Apple have written clearly in their documentation that when running iOS apps in the simulator, for any libraries that is common between the two platforms the macOS version is used in place of an iOS version recompiled targeting macOS kernel. I doubt that Apple would bother maintaining two separate code bases of the same library, as the bulk of the code is written in architecture-agnostic high-level language, and the few spots that are platform-dependent are conditionally compiled in the same source file.

If the information extracted through jailbreaks have told me anything, Apple have long unified the code base for macOS on desktop platform, iOS on mobile platform, tvOS for set top boxes, watchOS for wearables, and the embeddedOS running in MacBook Pro Touch Pads and Lightning video output peripherals. There isn't 5 separate operating systems, those are a single, unified Darwin operating system packaged with different libraries and sold under different brand names.

[tooki]

Absolutely. Of course, those libraries make up the vast majority of what we consider "an operating system" these days. But there's no question that Apple has been bringing many of those libraries closer and closer together under the hood, mostly in the direction of bringing more efficient libraries from iOS to macOS.

For sure, this is a great tribute to the modularity of Unix, that a single kernel can form the foundation of so many systems running on such disparate hardware over the years. (Just Darwin specifically was born on m68k, then moved to x86 and 32-bit PPC, then 64-bit PPC, then x64, then 32-bit ARM, then 64-bit ARM as timb already said.)

What I've always found impressive about the Mac and its architecture migrations is how a single install runs on multiple architectures. Sure, fat binaries aren't difficult in concept, but no other vendor seems to have actually made it work in practice. To this day, my Mac Pro (Xeon tower) is actually running an OS install (of macOS Sierra, 10.11) that dates back to a 2003 PowerBook G4 originally running Mac OS X 10.2, migrated via disk cloning from a machine that wasn't even the same CPU architecture! That is, I've never done a clean install or "system migration", just performed in-place OS upgrades. The upgrade to 10.5 made it a Universal Binary (PPC/x86) that could simply be cloned to the Mac Pro. Later versions stripped out the PPC code and moved everything to x64.

[technix]

Absolutely. Of course, those libraries make up the vast majority of what we consider "an operating system" these days. But there's no question that Apple has been bringing many of those libraries closer and closer together under the hood, mostly in the direction of bringing more efficient libraries from iOS to macOS.

For sure, this is a great tribute to the modularity of Unix, that a single kernel can form the foundation of so many systems running on such disparate hardware over the years. (Just Darwin specifically was born on m68k, then moved to x86 and 32-bit PPC, then 64-bit PPC, then x64, then 32-bit ARM, then 64-bit ARM as timb already said.)

What I've always found impressive about the Mac and its architecture migrations is how a single install runs on multiple architectures. Sure, fat binaries aren't difficult in concept, but no other vendor seems to have actually made it work in practice. To this day, my Mac Pro (Xeon tower) is actually running an OS install (of macOS Sierra, 10.11) that dates back to a 2003 PowerBook G4 originally running Mac OS X 10.2, migrated via disk cloning from a machine that wasn't even the same CPU architecture! That is, I've never done a clean install or "system migration", just performed in-place OS upgrades. The upgrade to 10.5 made it a Universal Binary (PPC/x86) that could simply be cloned to the Mac Pro. Later versions stripped out the PPC code and moved everything to x64.

I have a single library code base written in Objective-C, originally intended for iOS, that passed the unit tests targeting macOS, iOS, tvOS and watchOS at the same time. The library code contained some pretty deep runtime manipulation, but no conditional compiling.Efficiency is very good across all platforms, even on a heavily loaded iPhone 4S.

[timb]

Absolutely. Of course, those libraries make up the vast majority of what we consider "an operating system" these days. But there's no question that Apple has been bringing many of those libraries closer and closer together under the hood, mostly in the direction of bringing more efficient libraries from iOS to macOS.

For sure, this is a great tribute to the modularity of Unix, that a single kernel can form the foundation of so many systems running on such disparate hardware over the years. (Just Darwin specifically was born on m68k, then moved to x86 and 32-bit PPC, then 64-bit PPC, then x64, then 32-bit ARM, then 64-bit ARM as timb already said.)

What I've always found impressive about the Mac and its architecture migrations is how a single install runs on multiple architectures. Sure, fat binaries aren't difficult in concept, but no other vendor seems to have actually made it work in practice. To this day, my Mac Pro (Xeon tower) is actually running an OS install (of macOS Sierra, 10.11) that dates back to a 2003 PowerBook G4 originally running Mac OS X 10.2, migrated via disk cloning from a machine that wasn't even the same CPU architecture! That is, I've never done a clean install or "system migration", just performed in-place OS upgrades. The upgrade to 10.5 made it a Universal Binary (PPC/x86) that could simply be cloned to the Mac Pro. Later versions stripped out the PPC code and moved everything to x64.

Exactly. Glad to see that others get this as well! Apple really does have a fine software team that, for the most part, knows what the hell they're doing.

People love to shit on Apple, and yes they've got their problems (what company doesn't), but I think they've got the best combination of hardware and software on the market right now.

[tooki]

Indeed. In a way, Apple just sells software, which happens to require a laptop or phone shaped dongle!

[technix]

Indeed. In a way, Apple just sells software, which happens to require a laptop or phone shaped dongle!

Maybe not... Ever heard of Unibeast? It is just too sad that Apple don't have a passable AMD graphics driver. Before I upgraded the graphics to R9 380 on my workstation (had a GTX 650 Ti) I was running OS X on it too.

[Jeroen3]

Stop comparing with Apple. Apple developers have by far the easiest job around when it comes to compatibility. They're all in one building deciding how their software runs on their hardware.
Linux has the added difficulty that there are hundreds of different platform variants around it should be compatible with. With many to come in the future.

[Marco]

They are not the only ones. Last week I've read an article that some Dutch politicians are saying IoT devices should pass a security test before being allowed on the market.

Yet the internet is allowed to remain retarded by design?

We need a new internet, with sane ISPs who promise (with punishments upto and including expulsion) to use due diligence in using best practices (ie. ingress/egress filtering) and to knock DoS originators off the net. A spamming IoT device should be easily identifiable and kicked off the internet through an automated process.

[David Hess]

We need a new internet, with sane ISPs who promise (with punishments upto and including expulsion) to use due diligence in using best practices (ie. ingress/egress filtering) and to knock DoS originators off the net. A spamming IoT device should be easily identifiable and kicked off the internet through an automated process.

That will be fun; so the internet itself will have automated DoS capability built in.  Instead of saturating a system with incoming traffic, get the system to generate outgoing traffic which triggers the automated process to block it.

This idea is right up there with allowing incoming traffic to rewrite your firewall rules.

[nctnico]

A spamming IoT device should be easily identifiable and kicked off the internet through an automated process.

And cutting off internet to -for example- an entire hospital?  You are seeing these kind of problems already with blacklisting e-mail hosts where one out of a million customers could cause the entire ISP to become blocked. Luckily it seems less and less people are using the e-mail blacklist services because in the end it does more harm than good.

[langwadt]

They are not the only ones. Last week I've read an article that some Dutch politicians are saying IoT devices should pass a security test before being allowed on the market.

Yet the internet is allowed to remain retarded by design?

We need a new internet, with sane ISPs who promise (with punishments upto and including expulsion) to use due diligence in using best practices (ie. ingress/egress filtering) and to knock DoS originators off the net. A spamming IoT device should be easily identifiable and kicked off the internet through an automated process.

For every complex problem there is an answer that is clear, simple, and wrong.

[Marco]

And cutting off internet to -for example- an entire hospital? 

You can always sell them a high uptime contract with a 100K$ fine for fucking up.

Allowances can be made in the new internet TOS ... it's just a question of providing incentives for not being a moron.

At the moment there is no risk for poor security, even ISPs are allowed to just go on the bloody internet without proper egress filtering without penalty. It's insanity.

[technix]

And cutting off internet to -for example- an entire hospital? 

You can always sell them a high uptime contract with a 100K$ fine for fucking up.

Allowances can be made in the new internet TOS ... it's just a question of providing incentives for not being a moron.

At the moment there is no risk for poor security, even ISPs are allowed to just go on the bloody internet without proper egress filtering without penalty. It's insanity.

This is now pure evil. Living in China the government cutting off access to various sites is already frustrating enough.

[David Hess]

Allowances can be made in the new internet TOS ... it's just a question of providing incentives for not being a moron.

At the moment there is no risk for poor security, even ISPs are allowed to just go on the bloody internet without proper egress filtering without penalty. It's insanity.

Would those be the same incentives which convince ISPs to use egress filtering?  They have sure been a success so far.  Egress filtering is trivial and they cannot even do that successfully.

[Marco]

No, as I said there are no incentives.

The backbones don't really care, DDOS traffic is as profitable as normal traffic to them. The ISPs don't care, because they don't get punished for being morons. The customers don't care, because they don't get punished for being morons. Except in the tragedy of the commons sense, where we all get punished for not punishing morons.

The Internet needs something similar to the Certificate Authority industry in ensuring due diligence, as broken as the CA industry is is at least there is some stick to beat the worst of the worst with.

[David Hess]

Stop comparing with Apple. Apple developers have by far the easiest job around when it comes to compatibility. They're all in one building deciding how their software runs on their hardware.
Linux has the added difficulty that there are hundreds of different platform variants around it should be compatible with. With many to come in the future.

Apple also does not compete in markets where performance of large applications matter; they only have to optimize at most for small applications.  In this respect, iOS and OSx are toy operating systems and this is reflected in Apple's retreat from servers and high end desktop and portable computers which I can hardly blame them for; most of their sales and profits comes from iOS anyway.

In OS X and in earlier versions of iOS, the size of a page is 4 kilobytes. In later versions of iOS, A7- and A8-based systems expose 16-kilobyte pages to the 64-bit userspace backed by 4-kilobyte physical pages, while A9 systems expose 16-kilobyte pages backed by 16-kilobyte physical pages.

https://developer.apple.com/library/content/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html

That will make for great fun porting OSx and OSx applications to A9 or later.  Now I question if Apple does have OSx running on A9 or later hardware.

The page size problem is not insurmountable but it is problematical enough for performance and memory requirements to place a premium on not increasing it.  It would look bad if the same large application was either an order of magnitude or more slower or took several times as much memory (and was still slower) on ARM than on x86.