Apple's ARM-based Macs

[RichardRussell]

Apple has unveiled its first Macs based on ARM technology. The amount of 'spin' in that announcement is off the scale, not surprisingly because they've somehow got to present a less powerful (than x86) CPU as though it was more powerful!

The emphasis throughout is on 'CPU performance-per-watt' and I've no doubt that in that respect it does indeed beat existing Macs. But if one is more interested in raw computing power than in energy consumption then there's precious little information other than "all eight cores can work together to provide incredible compute power for the most demanding tasks". Well, yes, if you can somehow subdivide your computing task into 8 concurrent processes it probably will outperform a machine with only two or four x86 cores, but that is rarely easy and isn't always possible.

And what if one wants to perform numeric computations with more precision than is offered by 64-bit ('double') floating-point numbers? All x86 CPUs support 80-bit extended-precision floating-point calculations in their FPUs (which BBC BASIC uses when available), but no modern ARM CPUs do. If you need higher precision on an ARM you're forced to use software-only libraries, with a fraction of the performance.

I won't be supporting BBC BASIC on ARM-based Macs any time soon, because I would need one on which to develop, build and test it, and I don't intend to buy one (and in any case I've no idea when SDL2 will be ported to that platform).

[RichardRussell]

More background on Apple's M1 chip here. Interestingly, whilst this runs the AArch64 instruction set it's apparently not based on an ARM-designed CPU.

[Soruk]

I wonder how long it'll take for the Hackintosh types to boot it on a RasPi 4? Just a whimsical thought...

[David Williams]

"Apple Silicon M1 Benchmarks Are Unbelievable"
https://youtu.be/PRtEQ4OapW4

I wonder if his enthusiasm will take a hit when he sees the performance of emulated x86 apps (via Rosetta 2)?

In any case, from what I've seen and read (YouTube videos & articles), the M1 is no slouch at least with native ARM (AArch64) apps.


David.
--

[RichardRussell]

from what I've seen and read (YouTube videos & articles), the M1 is no slouch at least with native ARM (AArch64) apps.

Nor should it be, with a 5nm process! But comparisons with x86 are more tricky, and it's noteworthy that Apple themselves are not making extravagant claims (apparently they referred to it being faster than the "most popular" PC, but the picture they briefly showed was of a low-end HP model).

Can we legitimately refer to the M1 as 'ARM' if it isn't based on a core designed by ARM Ltd? Terminology may be about to become even more confusing!

[Soruk]

Can we legitimately refer to the M1 as 'ARM' if it isn't based on a core designed by ARM Ltd? Terminology may be about to become even more confusing!

I'd be inclined to say no. Certainly an AArch64 CPU would make sense as that's its instruction set. but calling the M1 an ARM is like calling an AMD K6 or a Cyrix 6x86MX a Pentium, but the they are all x86 CPUs.

[RichardRussell]

Certainly an AArch64 CPU would make sense as that's its instruction set. but calling the M1 an ARM is like calling an AMD K6 or a Cyrix 6x86MX a Pentium, but the they are all x86 CPUs.

Unfortunately my file-naming conventions use "_x86_32", "_x86_64", "_arm_32" and "_arm_64" suffices to indicate the instruction set, in other words I use "arm" in the same way as "x86" to specify the generic CPU family (not least because there isn't any other suitable term). I'm not likely to change that, even if the M1 has made it imprecise; the vast majority of AArch64 CPUs are still "ARM".

[David Williams]

ExtremeTech: "The New Apple M1 Reviews Put AMD, Intel Officially on Notice"
https://www.extremetech.com/computing/3 ... -on-notice

"The M1 is a serious, serious contender for one of the all-time most efficient and highest-performing architectures we’ve ever seen deploy. That doesn’t mean it beats x86 in every single test, or that it’s going to sweep Intel or AMD from the market. It does mean that this is a competitive threat Intel and AMD absolutely must take seriously, ..."

Having watched over a dozen YouTube video reviews of Apple's 1st generation Apple Silicon machines, the fanboys enthusiasts seem both surprised and delighted by the M1's performance. It does seem astounding, and even the performance of native x86 apps running under emulation is impressive. I know there was a lot of scepticism and even fear and dread when Apple announced it was transitioning from x86 to ARM, but it looks like Apple has done it right.

I can imagine that there are some worried bigwigs at Intel Corp. right now.


David.
--

[RichardRussell]

I can imagine that there are some worried bigwigs at Intel Corp. right now.

I wouldn't worry if I was them, because the x86 architecture still has 'killer' advantages in some applications. First and foremost, as I've mentioned before, is the FPU: if your mathematical operations involve many chained steps, you want intermediate values to be held internally to a higher precision than the input and output values. This is how the x86 FPU has always worked: you (typically) load one or more 64-bit 'double' parameters into the FPU, perform as many calculations as you like on them using the internal 80-bit precision, and then convert back to double for the result. With luck, your result will approach an accuracy comparable with its precision.

Currently, no ARM or AArch64 CPU supports that, as far as I know (early Acorn co-processors did, but for some reason that capability was dropped when the FPU was integrated with the CPU). Intermediate values can be held only to 64-bit precision (unless you use a software library) so errors accumulate, probably by at least 0.5 LSB at each step. Of course there are many applications when this loss of accuracy won't matter, but there are plenty when it does. The 'scarab.bbc' example program supplied with BBCSDL demonstrates beautifully just how sensitive some computations can be; here are the patterns it produces when using 64-bits and 80-bits precision respectively. The calculations are otherwise identical:

scarab64.jpg

scarab80.jpg

[Flatlander]

Am I to assume then that BBCSDL ‘dies’ on Apple Silicon Macs when Rosetta 2 does?

(Assuming Rosetta 2 is somehow pulled from existing devices. But hopefully not for a good few years considering Mac Pro isn’t even ready yet.)

…

Separately, that lack of 80 bit internal FP precision is surprising! It sounds like something that would have been added back years ago.