On the technical side, the ARM chip has much to recommend it to the programmer. The whole point of a RISC architecture was to produce an instruction set, all of whose members execute in one clock cycle. Which in turn makes the instruction set fast. Though this is usually achieved at the expense of the convenience of complex addressing modes found on processors such as the Motorola 68000 family (which performed sterling service in Atari STs and Amigas in the 1990).

The original designers of the ARM included some neat tricks to get around this problem. First, they made every instruction in the instruction set capable of conditional execution, which meant that you could eliminate branch instructions and speed things up enormously if you took suitably sophisticated advantage of this feature. Second, they included a barrel shifter as part of the CPU hardware, and made its tricks available by allowing shifts and rotates to be performed simultaneously with other instructions, again adding to the speed of the CPU.

For those used to the instruction set of, say, an Intel 80x06 type CPU, the instruction set takes some getting used to. But once you have acquired familiarity with the ARM way of doing things, you can write code that runs at ridiculous speeds. When the ARM was first offered to the public, back in the early 1990s, via the Acorn Archimedes desktop computer, it blew other CPUs out of the water with its blisteringly fast execution, and that was at a time when the CPU was clocked at a measly 8 MHz clock speed. Modern ARMs are clocked at 480 MHz and beyond, and at 480 MHz, well-written ARM code will outperform Intel x86 code on a 2 GHz chip.

One early problem that surfaced in the 1990s, was that compiler writers were caught on the hop by the unique nature of the ARM instruction set, and it took time for properly constructed optimising compilers for C or C++ to emerge for the ARM architecture. That hurdle is now overcome, of course, and the software developement around the ARM architecture is now mature and solid - boosted by the fact that the ARM was the go-to processor for many tablets and mobile phones even before Apple got in on the game.

Another nice feature of the ARM architecture, is that it's one of the more open architectures in existence. Over time, the ARM instruction set has had some nice extensions added to it, such as Jazelle, for direct execution of Java bytecodes, and more recently, extesions facilitating the speeding up of JavaScript in browsers (and by exension, speeding up of the node.js runtime).

As an example of what the ARM is capable of, take a peek at this: a "neo-retro" computer called the Maximite 2, that runs BASIC, but which achieves execution speeds in BASIC that were only achievable in assembly language just 20 years ago:



However, now that I've covered the good stuff, it's time to look at the not to good stuff. Almost all of which centres upon Apple's well-deserved reputation for egregious abuse of monopoly power. Those old enough to remember Microsoft's obsession with vertical control and vendor lock-in in the 1990s, will recognise the territory in question immediately, but Apple has taken this, in some areas, up to Spinal Tap 11. An independent computer servicing shop that has had numerous run-ins with Apple is this one:



and he has an entire series of videos covering the requisite issues, including abuse of monopoly position for the purpose of egregious price gouging. Indeed, so pernicious has been Apple's pursuit of vertical control, that its activities spawned a "right to repair" movement in the USA. Though, in the interests of fairness, the above individual also notes how Apple ended up being the good guy in a spat with Farcebook's Mark Zuckerberg, who claimed (falsely) that Apple's promise to deliver enhanced privacy protection on its devices in future would be "anticompetitive" and "harm Facebook's business". Well, if your business is data-raping Farcebook users and selling their data to the highest bidders with no scruples at all, perhaps it deserves to be harmed ... but I digress.

Part of the problem here is that the days of Apple being the rebel alternative to the Microsoft empire (to break out the overworn and clichéd analogy that might have held in the early 1990s) are long gone. Apple has now become the replacement $2 trillion corporate empire, the financial Imperial Star Destroyer that even some banks tread in fear of. And it's acting true to type. Which might lead to some friction with the people at ARM if they trying being too proprietary with the CPU architecture, which wasn't Apple's intellectual property to begin with.

Another part of the problem, is that Apple attracted a fan base, back in the days when it was the rebel alternative to the Microsoft empire, by providing original and technically challenging solutions to certain niche problems that actually worked at the time. Back in the 1990s, Apple hardware made Adobe PhotoShop possible, and Adobe had to bust a gut to deliver similar results on Windows platforms in the days of 75 MHz Pentiums. But now that even cheap laptops can feature a dual core Intel CPU running at 2.4 GHz, the list of tasks that are beyond the reach of such machines in reasonable time has dwindled accordingly. The sort of tasks requiring ingenious solutions to be manageable on a laptop, are now in the realm of high end research conducted by teams with budgets allowing them to book supercomputer time (or in some cases, buy their own supercomputer exclusively for the purpose), but occasionally, one sees episodes of brilliance such as this, which may even bring the dreaded Navier-Stokes Equations within laptop reach in the future.

So, in summary:

[1] The ARM CPU architecture was a stroke of genius when it first appeared, and is still a force to be reckoned with by those in the know, even if it didn't have the same mountains of cash thrown at it as Intel's x86;

[2] Apple choosing ARM for laptops may be the endorsement the architecture finally needs to supplant x86;

[3] But Apple has a less than happy history with respect to corporate practice, which could spoil the mix badly.

However, if Apple delivers on the privacy front on its devices, and succeeds in wiping the smirk off Zuckerberg's face (see more on this in the following video clip):



then I'll be happy to cheer Apple on in this matter. But I won't cheer them on if they leverage the ARM for more price gouging.

Sent from my iPad using Tapatalk

I did get an M1 MacBook Pro with the 16GB option and 512GB to replace my 2016 one. It is definitely snappier compared to the old one but the immediate practical observation was that this new one runs a lot cooler than the old one. Just having 10 or so Firefox tabs open appeared to drive up the temperatures such that the case was rather hot near the display, the case portion to the rear of the keyboard.

Is it the new native Firefox or is it the older one using Rosetta?


Sent from my iPad using Tapatalk

I've got 18 tabs open on Chrome at the moment, and it's basically room temperature (but that's a Malaysian room). The Air version with no fan and 8GB. Might be Firefox that's the problem.

Haven’t used Firefox for a while myself. Later versions ground my system to a halt.


Sent from my iPad using Tapatalk

On my Windows laptop, the issue with Firefox isn't speed per se, but if you're using the debugger to test JavaScript code, the debugger in Firefox runs like a snail on Mogadon. On the other hand, the Chrome debugger operates at a respectable speed.

Haven't had the chance to try Safari on an Apple platform yet, so don't know what that's like from a developer standpoint.

felltoearth wrote:Is it the new native Firefox or is it the older one using Rosetta?


Sent from my iPad using Tapatalk

Good question, I'll need to check that when I'm home.
I've been doing a fair bit of 2D graphics work on it using Krita and it's behaving ok [non-native I think], not the most strenuous tests to date I'd say but no issues have come up yet.

Interesting video in light of AlanC’s experience




Sent from my iPad using Tapatalk

So I'm running version 86 of Firefox at home. Couldn't really see anything in the About but apparently starting with 84 Mozilla is accomodating the M1. It doesn't appear that Krita has native support yet but as I said I haven't really noticed any issues there.
Oh there was one possible hiccup and that was Virtual DJ, I think after a while [or coming back to it after leaving in the background for a while] it would hang up or not respond to the inputs from my cheapo deck.

I haven't been running much else at the moment.

Several of the items shown in that video don't surprise me.

Back in the old 1990s Archimedes days, Acorn demonstrated an emulator for the 80286 running on their version of the ARM, that actually executed faster than a native 80286 chip. You can guess how Intel reacted to that.

The ARM has always been capable of unleashing tricks of this sort onto an unsuspecting audience, and in the hands of skilled developers who know how to take advantage of its unique architecture, it can embarrass competitors with higher clock speeds while hardly drawing breath.

The unique architecture of the ARM lends itself to some interesting code optimisations, that either a skilled assembly language developer or a suitably written optimising compiler can make use of to devastating effect, if of course you exercise a little savvy deploying the requisite options. Like any CPU, it will be hampered by incompetent coding, but if you exercise diligence learning about its features, you can utilise them to make your code run at warp speed. Judicious use of both conditional execution in non-branch instructions, and proper consideration of where to bring the barrel shifter into play, lets you pull off tricks that can easily double or triple the execution speed of your code compared to code using more traditional instruction sets.

By the way, if you want to sample the fun that the ARM architecture offers, albeit at slower speeds, but without the expense of buying a brand new M1 Mac, you can always try out this ARM emulator written in JavaScript, and see its features in operation for yourself.