Okay, this is *EXCEEDINGLY* odd.
Got the new "Apple Silicon" Mac Mini. It is ridiculously fast.
My other Mac is a 1-year-old 16" MacBook Pro. A system with a 45 Watt, 8-core CPU, 32 GB RAM, and 50 Watt GPU with 8 GB RAM all to itself.
The new Mac Mini has a 20 Watt CPU+GPU with 8 GB total RAM. 8 Cores, but only 4 are "high performance."
Did a video transcode using HandBrake. 4K, 60 fps Apple ProRes, 30 seconds long.
When using the OS API transcoding (VideoToolbox), they're about the same to transcode to H.265/HVEC. (Understandable, the MacBook Pro contains Apple's "T2" chip which has an H.265 encoder that is probably the same as in the M1 chip.)
Using CPU-only x265 encoder, on the other hand...
MacBook Pro: 2:21
Mac Mini in "native code" mode: 7:32.
Okay, that seems about right. But let's try the Mac Mini in "Rosetta" mode, where it runs the x86 code translated to ARM.: 2:56.
Whaaaaa?
Yes, running the Intel code translated to ARM runs multiple times faster than running the native ARM code.
Obviously the x265 codec hasn't been optimized for ARM, and Apple's own "Intel to ARM translator" does a FAR better job optimizing than whatever compiler it was using.
Although, super strangely, even though the encoder settings were identical for the "native ARM" and "Rosetta translate" runs, the ARM-coded file is 3x larger.
Wut?
It is impressive that the "translated Intel code" runs only BARELY slower, on a *MUCH* lower power CPU!
And the "native Intel CPU" export and the "translated Intel-to-ARM" export are identical in size. So the translated code is running absolutely the same code as on a real Intel CPU.
Time to open a ticket on why the ARM-native code isn't obeying the encoder settings and producing such a much larger file.