> ec2 only offers 6 general-purpose ARM instance sizes m6g, c6g, r6g each support 6 sizes for a total of 24
This seemed like the weakest argument in the article; as arm becomes more popular it will get more support.
ARM Mac: Why I'm Worried About Virtualization
241–250 of 313 posts
Re: ARM Mac: Why I'm Worried About Virtualization
#242Any company with a load of binaries built without any effort towards supporting cross platform builds that uses Docker is gonna have a bad day with this. They buy a bunch of new MacBooks and then find they can't use them until they spend a few weeks porting everything.
I suppose that depends what they’re written in. Some languages (e.g. Go) far simpler than others.
Re: ARM Mac: Why I'm Worried About Virtualization
#243I guess someone will port Docker to JVM, and use the JVM optimized to whatever ARM processor there will be.
Docker is written in Go which already has first-class cross-compilation support, so getting the Docker tools running on ARM is practically a non-issue.
Re: ARM Mac: Why I'm Worried About Virtualization
#244Earlier quoted context omitted.
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 (…
Awesome, thanks for testing this out!
A 3x slowdown is not as bad as 6x, but it's still quite a bit. I also saw a slowdown of ~4x when I tried this experiment on a native Linux x86_64 running ARM - perhaps the Mac -> Linux virtualization slowed it down further.
5x may have been a bit alarmist, but regardless we should brace ourselves for a big performance hit on x86_64 virtualization.
Re: ARM Mac: Why I'm Worried About Virtualization
#245Earlier quoted context omitted.
Do they run their own metal? I thought they were on AWS.
Well, if they are, that makes things even easier -- Amazon has offered ARM instances since 2018 [1]. [1]: https://aws.amazon.com/blogs/aws/new-ec2-instances-a1-powere...
I think they have both. They offer POWER and LinuxONE as options and those aren't available in your average cloud provider. They probably have a sweet deal with IBM Cloud.
I'd love to have a POWER and an IBM LinuxONE in my shed, but that's not going to happen.
Maybe the POWER, but the Z most likely not.
Re: ARM Mac: Why I'm Worried About Virtualization
#246> 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.
Thanks, I didn't know about c6g, m6g, r6g. I've updated the post to remove this mention - I only counted a1 instances.
That still leaves storage optimized and GPU optimized instances missing. I'm guessing storage should be easy enough to add, but what about GPU?
From my novice experience with GPUs, they need finicky drivers that must be ported by the GPU manufacturers, so I figure it might take a while to get competitive ARM GPU instances.
Re: ARM Mac: Why I'm Worried About Virtualization
#247Earlier quoted context omitted.
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...
I have to say I don't understand your point either.
Okay, so we can disable secure boot. What is the next step? How does one get to running Linux natively from there?
Re: ARM Mac: Why I'm Worried About Virtualization
#248I guess someone will port Docker to JVM, and use the JVM optimized to whatever ARM processor there will be.
Docker is written in Go which already has first-class cross-compilation support, so getting the Docker tools running on ARM is practically a non-issue.
Yeah, I thought about the conceptual idea, similar to what MS did: https://threatvector.cylance.com/en_us/home/teardown-windows...
Re: ARM Mac: Why I'm Worried About Virtualization
#249For 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 ben…
Cool, thanks for sharing. It's these kind of experiences that I was hoping to gather from making this post.
Did you notice at the end that you did NOT end up choosing ARM? You ended up going with x86_64 because that's what made more sense for your backend. That's part of my point - developers should choose their backend architecture based on the performance and pricing of their backend, not their development laptop. And if that decision is "we should keep using x86", then there will be a big performance hit in development.