[Feature] aarch64 build / macOS-arm64 ("Apple Silicon") releases

[majick]

Eventually, just as Rosetta 1 did (rest in peace), Rosetta 2 will go away. And while Rosetta 2 isn't slow, per se, it's certainly not necessary to take the performance hit / battery life hit to use it in the case of running Java code. GraalVM has aarch64 support, so hopefully it's a matter of creating a new target for it?

[badvision]

Thanks! I'll have access to an M3 machine soon, and hopefully can do some real testing on it then.

[majick]

I poked around it a bit and it needed

        <profile>
            <id>lwjgl-natives-macos-arm64</id>
            <activation>
                <os>
                    <family>mac</family>
                    <arch>aarch64</arch>
                </os>
            </activation>
            <properties>
                <lwjgl.natives>natives-macos-arm64</lwjgl.natives>
            </properties>
        </profile>

to build.

The arm natives are in a different jar.

(My resultant binary didn't run, but I think that's because I had a pathological build environment)

[badvision]

Confirmed. I have an M3 and was able to get Jace running with this as well (via mvn javafx:run) -- I'll continue testing and release an arm build for MacOS when 3.1 is ready. Thanks @majick!

From a general speed comparison on an M3 Max I ran Arctic Fox at max speed:

• Intel version: Caps out around 6x (a little slower than Core i9 which gets around 9x)
• Arm64 version: 13-14x, so over twice as fast, and way faster than the intel version on intel hardware!

The important thing is that on arm hardware, the emulator is capable of running faster at full speed, which means it also uses less juice at regular speed... a welcome benefit!

[badvision]

I don't expect that a native build will be any faster than running Jace as a java app -- generally GraalVM builds are known for faster startup but similar runtime. The convenience of folks not having to install Java is the main draw for native builds; and so this opens the program to a wider audience of folks who really are not interested in installing java, let alone fiddle with the command-line to get the emulator working.

[majick]

Honestly, I'm pretty surprised at the performance hit that Rosetta 2 was giving, but not at all surprised at the performance of raw aarch64. These things are beasts, I tell ya.

The convenience of the native build is pretty nice even for those of us who have a prompt sitting open most of the time; it's easier to pin to the dock! 😆

Note: as of last week, I closed our major touchpoint of commonality (yes, I know this is obtuse for those following along) but you're more than welcome to reach out by other means. I'll DM you via Infinitum.

[badvision]

Minor update; I'm trying to get "false" reads working on indexed 65c02 modes, but am trying to pin down a regression this caused on the floppy emulation (still not sure why) -- once I get past that I can get closer to a 3.1 release. For anyone wanting native aarch64 support, you will have to cherry-pick the changes mentioned in this thread for the time being (sorry)

[badvision]

I never updated this issue: I fixed the false reads issue a while back. It was caused by indirect access to the floppy drive; apparently false reads to I/O ports has to be handled carefully, and in this case disk access isn't technically cycle-accurate but rather advances the read pointer with each I/O access. So false reads were skipping every other byte when reading disks. Anyway, I'm working on other issues and deciding when to release the next version but this issue is effectively resolved.