RandomX on Apple Silicon: what an M1 Mac can do

Apple's M-series chips meet what the RandomX README asks of a processor: a 64-bit architecture, an IEEE 754 floating-point unit and hardware AES through the ARMv8 cryptography extensions. RandomX has a JIT compiler for ARM64 that turns its programs into native code, and XMRig publishes an official build for macOS on arm64. So a Mac mines RandomX. What it does not get is the help that a Linux machine gets from its memory system.

No huge pages

On Linux, a miner puts the 2080 MiB dataset in 2 MiB huge pages, or even 1 GiB ones, so that a random read of it rarely misses the processor's table of page addresses. On macOS on Apple Silicon we found none to be had. Our test program asked for a 2 MiB superpage with both mmap and vm_allocate, and both refused it with EINVAL: the page size is always 16 KiB. That is better than the 4 KiB pages of an x86 machine without huge pages, but the dataset still spans more than 130,000 of them, and nearly every dataset read misses that table on its way to memory.

Hardware AES counts

RandomX fills and hashes each thread's 2 MiB scratchpad with AES, and does it for every hash. On our Mac mini M1, tevador's reference RandomX with hardware AES made 614 hashes a second against 537 with software AES on the same machine, 14% more, with the same result hash. Any build of a RandomX miner for Apple Silicon should use it; the official ones do.

The machine matters more than the code

The biggest variable we found was not in the miner. The same build gave anywhere from 110 to 880 hashes a second on the same Mac mini, depending on what else the machine was doing — load averages from 17 to 210, and up to 25 GB of swap in use. Even the processor time for one hash moved with it: 4.24 ms at a load average of about 87 and 2.78 ms at 15 to 27, 34% less, with no change to the code. Other programs share the chip's caches and its memory with the miner, and RandomX is built to need both.

So a figure for an M1 means little without the state of the machine it came from. Ours were taken on 25 October 2026 with three mining threads at low priority, on a Mac mini doing other work; they describe that machine on that day, not the chip.

The ARM fix

On 10 May 2026 the RandomX reference code put out 1.2.2 and 2.0.1 as recommended updates: earlier versions could produce an invalid hash about once in 268 million on ARM and RISC-V systems, through a bug in the JIT's ISUB_R instruction. An invalid hash is a share the pool rejects, so the cost is small, but it is a reason to keep a Mac's miner current. XMRig carries its own copy of the RandomX code; its newest release, 6.26.0 of 28 March 2026, came out before the fix, so whether a given build has it is a question for XMRig's own changes. An earlier release, 1.2.1 of October 2023, had already fixed how RandomX clears the instruction cache on Apple Silicon.

The memory guide has the rest of what RandomX asks of a machine.