Announcement

Collapse
No announcement yet.

macOS 13 Adding Ability To Use Rosetta In ARM Linux VMs For Speedy x86_64 Linux Binaries

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by schmidtbag View Post
    Understood and that makes sense. I sort of misspoke:
    Why doesn't apple support both x86-64 and aarch64? Running aarch64 binaries would be more efficient if given the choice.
    What are you taking about? Apple CPUs run aarch64 natively. I mean, they are ARMv8 cores. What’s there to support?

    Rosetta allows them to also run existing x86-64 binaries on their processor with an acceptable performance. It was already supported under MacOS and now they also provide the interpreter to use inside native Linux guests. So an aarch64 Linux distribution can now also run x86-64 binaries.

    To be honest this would been useful a couple months ago. I was running a VM that needed some openshift client binary. Unfortunately the binary was only provided in x86-64. But after some digging I manage to find some older version of the client that had an aarch64 version available. Worked for the intended purposes.
    Last edited by amxfonseca; 07 June 2022, 12:30 PM.

    Comment


    • #12
      Originally posted by amxfonseca View Post
      What are you taking about? Apple CPUs run aarch64 natively. I mean, they are ARMv8 cores. What’s there to support?
      The gist of the topic is being able to run Linux software on Mac OS...
      I get the point of Rosetta. My point is, why stop at x86-64 compatibility, when these Macs are aarch64 and Linux has aarch64 binaries? It wouldn't take much effort, and the binaries would probably run more efficiently since there's no additional translation layer. To only run x86-64 Linux apps would be like charging an electric vehicle only with a portable gasoline generator, when it would be more cost effective to charge from the grid (or, just get a gasoline powered car).

      There are obvious benefits and reasons for being able to run x86-64 Linux binaries, which have already been discussed. If there wasn't any x86-64 compatibility, then there would be significantly less value to this feature. But not everyone who needs Linux binaries on a Mac are running closed-source x86-64 programs. If the programs you need are built for aarch64, why not have the option to run those for that extra boost in performance/efficiency?

      I don't get why this is something worth arguing about. It's not a hard concept or a very controversial one. Apple already did the hard part.
      Last edited by schmidtbag; 07 June 2022, 01:10 PM.

      Comment


      • #13
        Umm, aarch64 binaries already work, no Rosetta needed for those. You install aarch64 Linux in a VM and it works, along with any aarch64 software that's there already. Using Rosetta, within the Linux VM, you can now run x86-64 software.

        Comment


        • #14
          Originally posted by schmidtbag View Post
          Here's what I don't get though: why specifically x86-64 binaries, when Linux can do aarch64?
          well you see, if you are running an arm linux VM, I think, just maybe, hear me out. I think it might already be possible to run arm binaries. Now I haven't tested this myself, it's just a guess...

          are you sober? or just not bother reading the bloody headline? I get not reading the article itself, lots of people seem to do that... but this? I just don't compute. you clearly have some clue of what you are talking about, so did you just forget the entirety of the article, and glance at the headline or something?

          Comment


          • #15
            Originally posted by schmidtbag View Post
            The gist of the topic is being able to run Linux software on Mac OS...
            It is not. The gist of the topic is about running Linux binaries inside a Linux VM. More specifically, x86-64 binaries on a aarch64 Linux kernel.

            MacOS does not run Linux binaries. It provides an hypervisor framework (the same way that the Linux kernel provides KVM), that easily allows you to run a VM in MacOS without too much extra software.

            That VM will be running natively in aarch64 architecture. So everything that is compiled to aarch64 will just run. What Apple is now offering is the possibility to use Rosetta inside that Linux VM, so you can now also run x86-64 binaries. Rosetta used to only be available on MacOS (to run MacOS x86-64 binaries)

            Sometimes you can have a binary that you don’t have access to the source. Or some other software that is distributed only in binary form. Usually they are only available for x86, so it’s nice to have an option to be able to run it without losing too much performance. It’s mostly for legacy/compatibility purposes. Still useful though.

            This is simply about Apple providing Rosetta to Linux. Nothing stops you from running your aarch64 software on both operative systems. It’s actually preferred, since Rosetta is only a tool to help with transition, Apple will eventually discontinue it, like it happened with PowerPC.
            Last edited by amxfonseca; 07 June 2022, 01:51 PM.

            Comment


            • #16
              Originally posted by schmidtbag View Post
              Kind of weird for them to do this but perhaps it's Apple's way of preventing people from dual booting or outright replacing MacOS. After all, if you run Linux, you're pretty much not going to use any of Apple's products
              Not true. I know people who uses Linux and iPhones, I know people who runs OpenBSD on Mac Minis (which is not that far philosophically from running Linux there) and actively promotes the use of Linux in general, most of the web devs running Macs technically emulate Linux to use Docker (not really by choice tho), and certainly the people from Asahi is interested in running Linux on Mac because otherwise why on Earth would they put that much effort?
              Hardware is hardware. Most hardware is quite closed. Intel is quite closed at that level, with the ME and the FSP and all that bullshit. Apple is not better nor worse in that regard. In terms of software, there are valid reasons to want Linux on your computers but to use an iPhone as smartphone, namely privacy: Android is terribly invasive and some important apps (at least in my country this includes home banking and some State apps, one of them needed for free transit certificates during quarantine) will refuse to run on custom ROMs, making iPhone the only option with decent privacy policies that can actually be used for those tasks.
              Besides, they did help the Asahi team get to the point where something other than Mac is bootable and are actually friendlier to Linux than nvidia for a start. They don't seem to have any issue with people running Linux there.

              Originally posted by schmidtbag View Post
              From what I understand, Apple doesn't see much profit in their hardware sales. Most of their profits come from iTunes and the App Store. So, by allowing people to run Linux software without leaving MacOS, Apple gets to keep users within their ecosystem.

              iPhones clearly lead, services (which probably includes the App Store) is greater than any other individual hardware product but less than double each, so Mac sales are far from irrelevant unless we consider the App Store to also be irrelevant.

              Originally posted by schmidtbag View Post
              Also, with the recent trends of right-to-repair, Apple might have to deal with people bricking their devices in attempts at dual-booting. If they can incentivize people to not dual boot, it decreases the chances of such issues.
              On the contrary, with right to repair they would be compelled legally to make it feasible to dual boot. If they can prevent the bricking without violating that right, they save themselves some liabilities. And not in practice they did help the Asahi team boot IIRC. They certainly didn't put any blockers.

              I'm curious how stable that would be tho. The memory ordering stuff that can be safely assumed for code generation for Apple is not present in non-Apple platforms. Wouldn't that risk hazards and data races on multithreaded code?

              Comment


              • #17
                Originally posted by sinepgib View Post
                I'm curious how stable that would be tho. The memory ordering stuff that can be safely assumed for code generation for Apple is not present in non-Apple platforms. Wouldn't that risk hazards and data races on multithreaded code?
                It's explained in that thread. It can't turn on the strong memory model required by x86, thus runs in the relaxed model of ARM, means sooner or later you'll find a program, which fails. They mention even a workaround - run it only one CPU core. The program will see just one CPU core and the emulation won't need to care about CPU cores synchronizations.

                Comment


                • #18
                  Originally posted by Ladis View Post
                  It's explained in that thread. It can't turn on the strong memory model required by x86, thus runs in the relaxed model of ARM, means sooner or later you'll find a program, which fails. They mention even a workaround - run it only one CPU core. The program will see just one CPU core and the emulation won't need to care about CPU cores synchronizations.
                  Good enough for many cases I guess.

                  Comment


                  • #19
                    Originally posted by sinepgib View Post

                    Good enough for many cases I guess.
                    Unfortunately you won't know the good enough cases. Latent race conditions can take time to show up, and can have all kinds of effects (think of transactions that aren't atomic anymore, suddenly one part is missing or duplicate)

                    Comment


                    • #20
                      Originally posted by discordian View Post

                      Unfortunately you won't know the good enough cases. Latent race conditions can take time to show up, and can have all kinds of effects (think of transactions that aren't atomic anymore, suddenly one part is missing or duplicate)
                      But race condition is only when you use more than one CPU core. And given how fast Rosetta 2 is and how slow is the generic emulation in Windows for ARM and Linux, it can be the same speed as using 2 cores, sometimes even like 4 cores using a generic emulation.

                      Fan fact: What if Windows and Linux had an option to use only one CPU core and thus disabling inserting the memory barriers heavily slowing the code?
                      Last edited by Ladis; 08 June 2022, 05:32 AM.

                      Comment

                      Working...
                      X