VMs in ARM MBPs

[theluggage]

Will ARM include proprietary Apple VM tech of its own that will then be supported by the major VM vendors?

ARM can do virtual machines - but they are ARM virtual machines and won't run x86 code.

The reality is, if you want to run/maintain legacy x86 applications, an ARM Mac would be non-ideal - but it would be possible via an emulator (some of us still remember SoftWindows on PPC) such as:

• QUEMU (free)
• Windows for ARM (which includes an x86 emulator) although MS doesn't currently sell ARM Windows without hardware.
• The x86 emulator/translator that Apple would probably have to write to run legacy MacOS code

...but no, really, if that's an important part of your workflow then its not going to be great.

On the other hand, if you want to develop for iDevices or Android... an ARM Mac should be better (...although Android and iOS code is usually processor-independent, and testing iOS apps on mac works by compiling an x86 version of the App...)

If you are doing "web development" on Linux - Linux for ARM is well developed, most of the major packages have already been ported (go and look at what you can do on a Raspberry Pi - all of the usual suspects are there) and the major Distros already have ARM versions so you can work in a familiar environment. If you're using Apache, NGENIX, Node.js, Python, PHP, Mongo, MariaDB etc. running on ARM isn't going to make any practical difference.

Of course, if you're building Linux software written in C/C++ etc. you'll need an x86 machine (or emulator) to actually build x86 binaries for distribution - but unless you're actually working on x86-specific drivers or kernel code you could still do primary development on an ARM machine since Linux/Unix is founded on the principle of portable source code (and, its 2019, so you're probably gonna want to support ARM anyway).

Whether there will be enough demand for Parallels or VMWare Fusion to get ported is another matter (it will probably depend on whether MS makes Windows-for-ARM available to Mac users) but there is already a basic virtualisation kit in Mac OS (its used by newer Mac versions of Docker) which I'd assume would get ported.

There's a lot of interest in ARM as a Linux server platform now - and, of course, ARM is now the most widely used CPU architecture, so although an ARM Mac would close a few doors, it could open a lot of new ones...

That said, Apple have just launched an Intel-based Mac Pro so I don't think x86 Macs are going away any time soon - I suspect Apple's plan is to progressively replace the lower-end Macs with iPads.

 

[psingh01]

This is why I do not look forward to any possible change to ARM. Virtualization works by having a thin layer of software managing the sharing of resources of the underlying architecture. It’s not about translating that architecture to a different one. That is called emulation and that is slow. The Mac had that before with a product called VirtualPC which emulated x86 for PPC Macs. If the Mac switches to ARM in the near future I’d be looking elsewhere for computers.

 

[pshufd]

This is why I do not look forward to any possible change to ARM. Virtualization works by having a thin layer of software managing the sharing of resources of the underlying architecture. It’s not about translating that architecture to a different one. That is called emulation and that is slow. The Mac had that before with a product called VirtualPC which emulated x86 for PPC Macs. If the Mac switches to ARM in the near future I’d be looking elsewhere for computers.

Perhaps you don't understand machine-code translation. That runs near native speeds.

 

[fokmik]

I guess we will see how well will work some apps emulated on that upcom surface prox with custom arm cpu

 

[poorcody]

Porting Mac apps to ARM will be almost effortless given the way Apple has "architectured" things (probably akin to upgrading code from Swift 4 to 5 for example, if not simpler). So how many resources are they really going to devote to the difficult talk of making x86 binaries compatible for these edge-cases? They have the cash to give to a third-party to do it, so maybe that will happen, but I am grateful Microsoft is investing in Windows-ARM, as I need to run some PC development tools on my Mac.

I was reading about Microsoft's new stab at running x86 Windows apps on ARM (aka Surface Book X). They use emulation to run the apps, but what they found was most third-party applications spend about 80% of their time running Windows API code. That code they of course ported (often just recompiling) to native ARM, thus most x86 apps emulated are running at 80% native speed in general.

I think if Apple goes full ARM, running this version of Windows via Parallels/Fusion etc. will be very feasible (assuming a desktop ARM chip has basic virtualization features.).

 

[pshufd]

Porting Mac apps to ARM will be almost effortless given the way Apple has "architectured" things (probably akin to upgrading code from Swift 4 to 5 for example, if not simpler). So how many resources are they really going to devote to the difficult talk of making x86 binaries compatible for these edge-cases? They have the cash to give to a third-party to do it, so maybe that will happen, but I am grateful Microsoft is investing in Windows-ARM, as I need to run some PC development tools on my Mac.

I was reading about Microsoft's new stab at running x86 Windows apps on ARM (aka Surface Book X). They use emulation to run the apps, but what they found was most third-party applications spend about 80% of their time running Windows API code. That code they of course ported (often just recompiling) to native ARM, thus most x86 apps emulated are running at 80% native speed in general.

I think if Apple goes full ARM, running this version of Windows via Parallels/Fusion etc. will be very feasible (assuming a desktop ARM chip has basic virtualization features.).

It will not be effortless outside of trivial programs.

Have you ever ported a significant project, say 10 million lines of code?

 

[dogslobber]

I think you might need to buy an x86 hardware plugin card for your ARM based Mac to be able to run Windows. There are already ARM Linux distros so you can run them natively.

 

[poorcody]

It will not be effortless outside of trivial programs.

When Microsoft first released the latest ARM-Windows, every existing app in the Windows Store ran on it. Natively. Not with emulation. Code that was written before the new version of Windows existed just ran.

How? As it turns out, the binaries being generated by Visual Studio using C#, C++.NET, VB.NET, etc., over the last two decades+ were not Intel binaries, but pseudo-binaries that are translated to Intel by a Just-in-Time-Compiler at launch (part of the whole ".NET" ecosystem).

The Swift compiler, Apple's current language, can generate the same sort of output (it may already for all I know). If Apple goes ARM, long-before they announce such an intention, I guarantee XCode will be spitting out similar binaries. App Store Apps will just run.

Older, legacy code, not in the App Store? A lot of that is being forced to be "cleaned-up" by the elimination of 32-bit apps in Catalina. Getting rid of 32-bit dependencies will make developers transition to modern techniques that have no connection to the underlying processor, for the most part. Maybe some cross-platform apps that are still a mess (*cough* Adobe?), or performance-critical C++ code will have trouble, but the vast majority of software big or small written in, say, the last then years should be relatively easy.

Have you ever ported a significant project, say 10 million lines of code?

I have. Well, multi-million line code project, not sure it if was over 10 or not. I led three developers on migrating an app from NeXTSTEP Motorola to Intel (NeXTSTEP was the precursor to Mac OS X). Took a few weeks, but we had 90% of it migrated within a week. NeXTSTEP was way ahead of its time back then, and OSX has only gotten better.

Code and processor have long separated thanks to performance and compiler imporvements.
[automerge]1570669289[/automerge]

I think you might need to buy an x86 hardware plugin card for your ARM based Mac to be able to run Windows. There are already ARM Linux distros so you can run them natively.

Man, way way back in the IBM PC days, there was a card you could buy that would plug into the PC slot and basically had an Apple ][ on it. It let you run Apple software on a PC. It was really neat actually. Maybe in addition to eGPUs, we will have eCPUs?

 

[pshufd]

When Microsoft first released the latest ARM-Windows, every existing app in the Windows Store ran on it. Natively. Not with emulation. Code that was written before the new version of Windows existed just ran.

How? As it turns out, the binaries being generated by Visual Studio using C#, C++.NET, VB.NET, etc., over the last two decades+ were not Intel binaries, but pseudo-binaries that are translated to Intel by a Just-in-Time-Compiler at launch (part of the whole ".NET" ecosystem).

The Swift compiler, Apple's current language, can generate the same sort of output (it may already for all I know). If Apple goes ARM, long-before they announce such an intention, I guarantee XCode will be spitting out similar binaries. App Store Apps will just run.

Older, legacy code, not in the App Store? A lot of that is being forced to be "cleaned-up" by the elimination of 32-bit apps in Catalina. Getting rid of 32-bit dependencies will make developers transition to modern techniques that have no connection to the underlying processor, for the most part. Maybe some cross-platform apps that are still a mess (*cough* Adobe?), or performance-critical C++ code will have trouble, but the vast majority of software big or small written in, say, the last then years should be relatively easy.

I have. Well, multi-million line code project, not sure it if was over 10 or not. I led three developers on migrating an app from NeXTSTEP Motorola to Intel (NeXTSTEP was the precursor to Mac OS X). Took a few weeks, but we had 90% of it migrated within a week. NeXTSTEP was way ahead of its time back then, and OSX has only gotten better.

Code and processor have long separated thanks to performance and compiler imporvements.
[automerge]1570669289[/automerge]
Man, way way back in the IBM PC days, there was a card you could buy that would plug into the PC slot and basically had an Apple ][ on it. It let you run Apple software on a PC. It was really neat actually. Maybe in addition to eGPUs, we will have eCPUs?

What if you build with GCC? Or don't use .net? Or write in assembler?

I did do a lot of porting in the .net environment but it was 32-bit MSVC to 64-bit porting. I would not characterize it as effortless. I was the first person in the world to port Mozilla Thunderbird from 32-bit Windows to 64-bit Windows. It took a considerable amount of effort. There's additional effort in qualifying and testing including additional systems for that, setting up the kits and the switch between ports.

Yeah, how's Catalina going for users these days?

macOS Catalina Causing Serious Issues: Why Some Shouldn't Upgrade

Mac owners who have upgraded to macOS Catalina are discovering that their programs won't run on the new operating system.

www.laptopmag.com

Now, is a few weeks with three people effortless? Was it free? Did it take a day?

Did you have code that generated machine code and then executed it? We certainly did. That was some ten thousand lines of code that had to be rewritten by hand.

 

[poorcody]

What if you build with GCC? Or don't use .net? Or write in assembler?

I did do a lot of porting in the .net environment but it was 32-bit MSVC to 64-bit porting. I would not characterize it as effortless. I was the first person in the world to port Mozilla Thunderbird from 32-bit Windows to 64-bit Windows. It took a considerable amount of effort. There's additional effort in qualifying and testing including additional systems for that, setting up the kits and the switch between ports.

Oh, God, 32-bit Windows to 64-bit Windows was a total mess. I would not say porting things in Windows (or any platform-agnostic C++ code) is easy or effortless. I'm saying pure Mac apps that have been written in the last decade should be easy. Windows is a mess. That's probably what led to the whole ".net" system. The Windows Store world is/was trying to be what the Mac world is -- "cleaner" for a lack of a better word.

Yeah, how's Catalina going for users these days?

Buggy it sounds like. The developer tools are impressive though.

Now, is a few weeks with three people effortless? Was it free? Did it take a day?

That was, what, 25 years ago. I'm saying even back then the design was great but had some dependencies, today is a whole new ball game (in the Mac world).

Did you have code that generated machine code and then executed it? We certainly did. That was some ten thousand lines of code that had to be rewritten by hand.

Wow. What was that used to do?

 

[pshufd]

Oh, God, 32-bit Windows to 64-bit Windows was a total mess. I would not say porting things in Windows (or any platform-agnostic C++ code) is easy or effortless. I'm saying pure Mac apps that have been written in the last decade should be easy. Windows is a mess. That's probably what led to the whole ".net" system. The Windows Store world is/was trying to be what the Mac world is -- "cleaner" for a lack of a better word.

Buggy it sounds like. The developer tools are impressive though.


That was, what, 25 years ago. I'm saying even back then the design was great but had some dependencies, today is a whole new ball game (in the Mac world).

Wow. What was that used to do?

Relational Database query optimizer. It did cost-based query optimization and then generated machine code to execute queries. The generated machine code had dynamic optimization built into it as well.

Firefox added a JIT for Javascript many years ago. I was invited to a meeting where Brendan Eich was overseeing the effort back in 2008 but it was run by a then-Phd candidate at UCLA who eventually became the CTO. I don't recall the name. I looked at the project but didn't participate. The old Javascript interpreter was your standard interpreter code. They got huge speedups out of it and I think that all of the browsers do that today.