Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM Mac: Why I'm Worried About Virtualization

bmalehorn.com

Post reply on HN
Print view View original

211–220 of 313 posts

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

#211

Post by mmcconnell1618 »

ArgyleSound wrote: post #126
ryandvm wrote: post #82

Earlier quoted context omitted.

> 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…

> I'm still having trouble forgiving them for getting rid of the physical ESC key and turning volume control into a two-step routine on the TouchBar To be fair it's always been a one-step routine on the touchbar (touch and drag the icon) and they brought back the escape key.

Touch and drag is easy to jump the volume up/down variable amounts but really sucks compared to a single key press for "just a little louder" or "just a little quieter." There is something satisfying in the discrete steps of volume notches.

On the other hand, my speakers have a physical volume dial that provides feedback via friction on movement so I like that better than touchbar or physical up/down buttons.

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

#212

Post by flatiron »

thayne wrote: post #85
smspf wrote: post #71

So many wrong assumptions ... 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling. 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-c…

> Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-case. I think the argument here is you can't build your own docker images that you use in production and run them on your mac without emulation (unless your production workload also runs on ARM).

If you don’t have an environment between your laptop and prod you got more things wrong than this ARM migration.

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

#213

Post by smspf »

bmalehorn wrote: post #99
smspf wrote: post #71

So many wrong assumptions ... 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling. 2. Generic container images like the Ubuntu mentioned usually have aarch64 (arm64) support, so running the x86_64 image makes no sense for the presented use-c…

Author here. > 1. If emulating aarch64 (arm64) on x86_64 is 6x slower (on your system, btw, it's not an universal constant), it doesn't mean emulating x86_64 on aarch64 will be 6x slower. It'd probably be worse, or at least that's my gut feeling. Yup, performance benchmarks are inherently flawed and nobody knows anything right now without the hardware. However if ARM -> x86 emulation is anything like x86 -> ARM emula…

I agree on the performance loss. Just for kicks, I ran the same commands on some real aarch64 (32 cores, 3.0GHz, ARMv8.? - can't remember and already logged off the machine, but I can double check tomorrow). Without further context, numbers:

  someuser@some-aarch64-machine:~$ docker run arm64v8/ubuntu bash -c 'dd if=/dev/urandom bs=4k count=10k | gzip > /dev/null'
  10240+0 records in
  10240+0 records out
  41943040 bytes (42 MB, 40 MiB) copied, 2.18298 s, 19.2 MB/s
  someuser@some-aarch64-machine:~$ docker run amd64/ubuntu bash -c 'dd if=/dev/urandom bs=4k count=10k | gzip > /dev/null'
  warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
  warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
  warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
  10240+0 records in
  10240+0 records out
  41943040 bytes (42 MB, 40 MiB) copied, 6.72324 s, 6.2 MB/s

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

#214

Post by _msw_ »

phamilton wrote: post #112

> ec2 only offers 6 general-purpose ARM instance sizes m6g, c6g, r6g each support 6 sizes for a total of 24

Disclosure: I work at AWS building cloud infrastructure

C6g, M6g, and R6g (powered by AWS Graviton2) each support 8 sizes, along with bare metal. A1 instances (powered by AWS Graviton) have 5 sizes, along with bare metal.

That's a total of 33 distinct instance sizes.

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

#216

Post by sudosysgen »

klelatti wrote: post #142
sudosysgen wrote: post #131

Earlier quoted context omitted.

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.

x86 is already relatively open, there's more than four companies developing x86 chips, though for now they are mostly focused on very low power outside of Intel and AMD.

There is no indication that I'll ever be able to buy an ARM CPU and plug it into motherboard with the feature set I choose and plug into it peripherals that follow a standard and open interface with good performance. The only companies that make ARM CPUs that could at all be useful in such an open platform don't make CPUs fast enough. I don't think Apple or Amazon will ever sell me a socketable CPU with high speed PCI support and XMP memory support.

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

#217

Post by TheNorthman »

sigjuice wrote: post #210
TheNorthman wrote: post #181

Earlier quoted context omitted.

To be clear, we don't know if the ARM MacBook will be able to run Linux natively. We only know that Apple won't continue support for Boot Camp and therefor Windows anymore. Linux was never supported.

There won't be native Linux. https://news.ycombinator.com/item?id=23640746 (Craig Federighi confirms Apple Silicon Macs will not support booting other OS) EDIT: fixed link

I don't understand your point. Native Linux isn't restricted to x86_64.

EDIT: Your new link doesn't tell a different story. From the comments:

> It is still possible to disable secure boot using csrutil. Apple has never officially supported booting Linux on a Mac.

> https://twitter.com/never_released/status/127585087215369011...

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

#218

Post by my123 »

lfy_google wrote: post #205
outworlder wrote: post #188

On the flip side, I guess ARM Macs will now allow the use of hypervisors for Android simulators, instead of a full hardware virtualization. ... thus making Android development better on Macs?

Android Emulator developer here. In addition to what the other comments said about android emulation with hypervisors existing already for x86, we're also looking into the Hypervisor.framework API for Apple silicon. It won't be a trivial task (hoping for pre-existing code to port over maybe?) but we have the other pieces like using Hypervisor.framework for x86 already, and being able to cross compile the other code f…

Hello,

OpenGL is deprecated but still supported on Apple Silicon, even for arm64 apps.

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

#219

Post by jmull »

m000 wrote: post #87
pantalaimon wrote: post #24

Earlier quoted context omitted.

When was the year of the macOS desktop?

It's not about stealing users from macOS. It's about stealing developers. Hell, Apple is at the mercy of Microsoft and Adobe right now. I'd bet they had to line their pockets very well, so that they don't get any funny ideas. But Apple can't just pay-up every cross-platform software developer. Smaller developers will have to re-evaluate whether macOS remains a viable target platform for them. Which can translate to a…

> ... while macOS requires you buy Apple hardware ... macOS as a gaming platform ...

So nothing is changing. ARM Mac isn’t going to change the Linux desktop/laptop story.

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

#220

Post by kube-system »

mey wrote: post #167
starsinspace wrote: post #52

Earlier quoted context omitted.

To give a different perspective: I find Apple's move to ARM the most exciting thing to happen in desktop computers in many years. I'm typing this from a PC running Win10. Current plan is: as soon as ARM desktop Macs become available (and assuming they don't screw it up in some weird way), I'd like to switch.

If it's ARM that excites you, Surface Pro X (Windows) and Pinebook (Linux) exist today. If it's macOS, you could switch now. What about the combo of macOS + ARM do you find compelling?

Because of the network effects of software development. The number of people that use those devices you list is basically a rounding error, so they're ignored by most software development.

Apple has a monopoly on their hardware, and they will likely sell a significant number of devices. This will lead to a lot more development for ARM that never would have happened otherwise.

That, in turn, may make tilt the balance in favor of ARM for a lot of other use cases outside of OSX when other tools, applications, and hardware vendors better support ARM.

Post reply on HN