Live data from Hacker News

ARM Mac: Why I'm Worried About Virtualization

bmalehorn.com

141–150 of 313 posts

Re: ARM Mac: Why I'm Worried About Virtualization

#141

It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests. It's tru…

With just less than 10% of market share, do you really think it will change the whole thing? Unless Microsoft pushes for ARM too, I don't see any changes soon

Re: ARM Mac: Why I'm Worried About Virtualization

#142

Once again -- Apple will do what the entire industry without Apple couldn't do. In this case, force a migration to ARM-based servers, so that prod is running on the same architecture as the developer's machine. Apple is finally killing x86.

There isn't really any advantage to ARM compared to modern x86. Closed ARM is IMO worse than x86. Now, if someone made the x86 license more open that would be cool, but so far it's all downsides at least for me.

> Closed ARM?

Is there any suggestion that the architecture that Apple is using is any different to what is being used by lots and lots of other licensees? If not then it's much more open than x86.

If you mean that you can't buy an ARM CPU today to plug into your own motherboard then understood but that's probably now a matter of time. At least making such a CPU is possible - no-one is going to make x86 more open.

Re: ARM Mac: Why I'm Worried About Virtualization

#143

Earlier quoted context omitted.

It's ludicrous to assume that anybody has $2000 to spend on fantasy hardware. It's month of disposable income outside of the SV bubble. Better question might be, how many of the most common open source projects are managed by volunteers in their spare time? These will not build for ARM, unless there is a free tool doing it automatically for them. Currently GitHub + travis/circle can do for x64 on every push to master…

You don't need a cluster of them, one $50 machine is enough for home use. Travis et. al. will be buying those 96-core Marvell ARM machines and plowing through builds.

Do they run their own metal? I thought they were on AWS.

Re: ARM Mac: Why I'm Worried About Virtualization

#144

I'm actually not worried, for a few reasons; - I already do cross-arch development day-in and day out between x86 and ARM, and have only run into hard blockers on a library or tool a handful of times. The solve was generally pretty straightforward to either use an ARM-compatible alternative, or to cross-compile it myself. - We've done this many many times before and it's not that bad. I know I'm not the only one old…

Tons of x86 code accesses misaligned addresses.

Re: ARM Mac: Why I'm Worried About Virtualization

#145
post #73
post #15

But linux can be run on arm natively. Moreover, most packages are also compiled for arm. So apt-get install will work just the same. I'm sure they will be able to target Apple's specific arm chips when they come out.

Apple released a list of open source projects that they have ported to ARM, they intend to upload patches to each of these projects: - Bgfx - Blender - Boost - Skia - Zlib-Ng - Chromium - cmake - Electron - FFmpeg - Halide - Swift Shader - Homebrew - MacPorts - Mono - nginx - map - Node - OpenCV - OpenEXR - OpenJDK - SSE2Neon - Pixar USD - Qt - Python 3 - Redis - Cineform CFHD - NumPy - Go - V8

Great to see Homebrew and MacPorts on that list. That's a huge signal that Apple plans on supporting developer / tinkerer use cases.

Re: ARM Mac: Why I'm Worried About Virtualization

#146
For my most recent project[1], I wanted to see if Amazon’s Graviton instances would be a good choice for my docker deployments (I was deploying MongoDB, an Express server, and several instances of the Janus WebRTC server). I was developing in Pop OS on an x86_64 desktop (since we’re gonna have to start specifying now) and found the toolchain around building ARM64 images to be pretty simple once I got it set up.

I benchmarked some `t2a.nano`s against some `a1.medium`s and found that the `nano`s were sufficient for my needs, so I went with them (they are cheaper than `a1.medium`s, even if the `a1`s have a better price-to-performance ratio).

I didn’t find it too difficult to rebuild any of these projects for cross-architecture usage. Even Janus, which has a TON of C/C++ dependencies (some of which have to be compiled from a particular version of the source) easily built for ARM with no change in the Dockerfile.

So I kind of feel like OP is exaggerating the effort required to migrate servers to ARM. Sure it might be a hassle when you have tons of microservices, but you can move them incrementally, and most things recompile with no changes. And regardless of what architecture your dev machine is, you’ll want to be able to compile for and work with both architectures if you want to get the most out of the infrastructure on offer in 2020.

[1] Shameless plug: https://chrisuehlinger.com/blog/2020/06/16/unshattering-the-...

Re: ARM Mac: Why I'm Worried About Virtualization

#147

Mac book was never really a dev platform. Maybe for front or nodejs, or definitly for native apple apps, but seriously, brew and so are so subpar.

I develop low-level code like compilers just fine on a MacBook.

What's "low level" about a compiler?

Re: ARM Mac: Why I'm Worried About Virtualization

#148

It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests. It's tru…

If I understand correctly, hypervisors don't emulate hardware, that's what emulators (like QEMU) do. That would mean that physically the most performant option to run x86 code on an ARM CPU is dynamic translation (like QEMU-TCG or the new Rosetta JIT support).

Rosetta 2 is ideally a static binary transformation, it only falls back to emulation when this doesn't work. So it's a bit different than TCG :)

Re: ARM Mac: Why I'm Worried About Virtualization

#149

It is very likely that ARM-based Macs will lack a performant hypervisor upon release. We will have to see how VMWare responds. I'd bet it will inspire new products and innovation and the desktop space will move towards a less x86-x64 centric world. In the end it is a short term problem. Someone will respond and provide a performant hypervisor that can run on an ARM host and virtualize x86-x64 and ARM guests. It's tru…

If I understand correctly, hypervisors don't emulate hardware, that's what emulators (like QEMU) do. That would mean that physically the most performant option to run x86 code on an ARM CPU is dynamic translation (like QEMU-TCG or the new Rosetta JIT support).

Broadly speaking yes. Generally, hypervisors mediate access to shared hardware whereas emulators implement simulated hardware in software.

The very first hypervisors worked using dynamic binary translation. They would run a "guest" operating system by executing a stream of native instructions directly on the host CPU. This stream would be dynamically translated to remove and trap in software any privileged operations so the hypervisor could handle them. Modern hypervisors take advantage of hardware features that allow you to more efficiently trap on privileged operations. ARM started to add some of these features starting in 2013 [1]. In contrast Intel first started adding these features to the Pentium 4 in 2005 [2]. When such hardware features were released, they actually were not faster than the software translation. These days the hardware based options are faster. There is even hardware support for running nested hypervisors. So the first question we need to ask is how hypervisors implemented with ARMs hardware features stack up to Intel. I have no doubt that parity at a minimum will be reached I just don't know what the current state of play is. As indicated in my original comment, if I had to bet on release we wont quite have the performance or feature set you would be used to with a product like VMWare Fusion.

The second question we need to ask is whether there is a way to efficiently emulate x86-64 processors on ARM hosts. Even better if you can do this while taking advantage of the supporting infrastructure hypervisors already have in terms of the emulated devices and other features. QEMU just gets you the CPU and a short list of a devices. The fully experience of a seamlessly virtualized guest requires a lot more than that. But at the core you are right that it is going to require QEMU-TCG, Rosetta 2, or some similar technology because the silicon just is not there to execute x86-64.

Exciting stuff! We'll see where it all lands.

[1] https://lwn.net/Articles/557132/

[2] https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-x

Re: ARM Mac: Why I'm Worried About Virtualization

#150
post #82

Earlier quoted context omitted.

Every time Microsoft or Apple majorly screws something up, people say this. It still hasn't happened yet. However, I think Apple has been a far greater threat to Linux adoption than Microsoft. Why? Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux. There is real value in proprietary commercial end-user application software. Most companies wh…

> Because it gives techies the *nix environment they want, with the software and hardware support no one will give them on Linux. The UNIX experience on the Mac is pretty shitty. Ancient versions of all the tooling. Command-line utils have that weird BSD well-water flavor. No package management. Funny Docker quirks. The hardware used to be pretty nice, but honestly I'm still having trouble forgiving them for getting…

Tap the volume icon and swipe left or right without letting go to do it one fell swoop.
Post reply on HN