Apples new M1 microprocessor

[borjam]

The openness of the PC always opened companies up a little more to competition, Intel/Microsoft could take leads but especially for Microsoft there was always a relatively low cost path for competition (which Apple massively benefited from). An Apple lead will now start taking away investment from PC hardware development, if they get sufficient mass it's all over and it will be infinitely harder to dislodge. Boring.

Openness?

Do you mean Microsoft coercing manufacturers to sell only Windows, and Intel suing compatible processor manufacturers while "proprietary" (according to the Wintel Ministry of Truth) processors were in fact available from several manufacturers, in a similar fashion as ARM processors now?

Orwell would have a good laugh!

[magic]

They may be coercing and suing, but you can run a dozen operating systems on PC hardware and high performance x86 suppliers are "only" a duopoly. Add a few smaller players in embedded.
Alternative software for ARM Macs (or just about any ARM board for that matter) may or may not materialize. Alternative hardware to run those software binaries almost surely will not.
That's the difference. There is basically no "standard ARM platform" to speak of. It's all proprietary SoCs on propriety boards with proprietary builds of Linux or some proprietary OS.

[brucehoult]

Well it does really. It’s no secret what they did.

State of the art 8-way superscalar processors without running into a million patents are billion dollar endeavours, M1 does nothing to make this easier for ARM/RISC-V implementations from other companies ... it doesn't even help create a market for them, unlike how things happened on PCs. Boring.

There was a rush of superscalar Out-of-Order processors in the mid 90s.

The Pentium Pro did 3-wide decode (generating up to 6 uOps total), 5 wide execution (in 6 units) in 1995.
The DEC Alpha 21264 had 4-wide decode, 6-wide execute in 1996.

Patents for those, and others, have expired by now.

Decoding 8-wide instead of 4-wide on a simple fixed length 32 bit opcode instruction set such as Alpha or arm64 is just a parameter -- literally changing a "4" to an "8" in an RTL generator. Exactly the same (expired) patents will cover it.

The hard part about it -- and more to the point having 600 reorder buffer entries as M1 does (192 or 224 are popular numbers on modern x86) -- is something I haven't seen *anyone* mention in any thread on any forum or media report. It's not that hard to change the parameters to do that, if you have enough transistors available on a die (i.e. a small process). The hard part is that most code has, on average, a branch instruction every five or six instructions. If you are going to have 600 instructions in flight at the same time then you have to be reasonably sure they are the RIGHT 600 instructions.

That means you have to accurately predict up to about 100 conditional branches in sequence. If you get any one of them wrong then you have to throw away all the work you did on following instructions, wasting both time and energy.

You can build as wide and deep a machine as you want -- it's straightforward -- but if you can't predict the branches accurately then it's totally wasted.

Apple must have done something quite amazing and absolutely unpublicized about branch prediction.

Branch prediction was also the most secret thing about the Pentium Pro back in 1995 -- and Pentium MMX got the same branch prediction technology and was what made it a big jump over earlier Pentiums (not the MMX).

These days, microcontroller cores such as the SiFive FE310 (and probably ARM M3/M4, certainly M7) have the same branch prediction technology the Pentium Pro pioneered -- not because they're out of order, but just to eliminate pipeline bubbles most of the time.


Building an 8-wide decoder for x86 is exponentially harder. The instruction lengths from 1 to 15 bytes mean those instructions could occupy anywhere from 8 bytes to 120 bytes. And you have no idea where later instructions start until you've already done most of the decode on earlier instructions. It's just intractable on cold code. On hot code you can add marker bits for the start of each instruction in the L1 cache, and have a uOp cache, and so forth. But that's all extra complexity and transistors and energy use that arm64 or RISC-V don't need.

[brucehoult]

There is basically no "standard ARM platform" to speak of. It's all proprietary SoCs on propriety boards with proprietary builds of Linux or some proprietary OS.

That's true in the ARM world.

RISC-V is trying hard to head that kind of thing off before it starts. Each SoC/board may need a custom 1st stage bootloader to initialize DRAM and various other things, but then it presents a standardized "SBI" ECALL interface and even the 2nd stage bootloader (e.g. Das U-Boot or similar) sees a completely standardized system and the same uboot binary can run on every system, as does Linux once you get that far.

[magic]

For the record, recent Cortex cores use µop caches and ARM claims that it actually improves efficiency by using less power than their Aarch64 decoder. Their cache is also wider than the decoder - more speed on highly looping code.

Are you sure of that branch prediction thing? I suppose it could be that they increased the ROB depth opportunistically, to speed up easily predicted loops.

[brucehoult]

For the record, recent Cortex cores use µop caches and ARM claims that it actually improves efficiency by using less power than their Aarch64 decoder. Their cache is also wider than the decoder - more speed on highly looping code.

Interesting. Aarch64 does have quite a few instructions that could benefit from splitting into uOps -- though nowhere near x86 level, of course. RISC-V doesn't currently have anything that would warrant splitting -- the instructions are their own uOps. Hmm, except maybe the atomic ops. But they need to avoid reordering. Some optional extensions may introduce uOps -- the Vector extension, for example.

And the code size reduction work has people wanting to introduce things such as push/pop multiple to complete better with ARM in microcontrollers (where RISC-V is doing quite well already without it). People such as Huawei and Andes have implemented these things as custom extensions already in shipping chips, so it makes sense to at least standardize the opcodes so software is more portable across vendors, and gcc can target just one flavour.

Are you sure of that branch prediction thing? I suppose it could be that they increased the ROB depth opportunistically, to speed up easily predicted loops.

It's mathematically certain that you can't use a 600 entry ROB / rename registers without correctly predicting all necessary branches -- which in some cases *may* come down to very large basic blocks, and in many others just relatively simple loops that execute a lot of times.

Economically, they wouldn't do it unless it was giving benefit on a fair bit of important code.

How much of the time it gets used .... anyone's guess...


One thing I've never seen anyone mention is whether there is a mechanism to *not* race too far ahead if you encounter a few branches where the prediction is too uncertain.

That's where conditional select is *really* useful. It might or might not be faster in isolation, but it often lets you totally get rid of branches are relatively unpredictable (at a small cost in doing unnecessary work on the result that isn't selected) and successfully speculate much further ahead.

[Marco]

Do you mean Microsoft coercing manufacturers to sell only Windows, and Intel suing compatible processor manufacturers while "proprietary" (according to the Wintel Ministry of Truth) processors were in fact available from several manufacturers, in a similar fashion as ARM processors now?

Yes, even with all that at its worst the PC was far more open than Macs will ever be ... that's how bad having a dominant Mac is. Yet somehow some people who can recognize those evils on PC are blind to the much greater evil of a dominant Apple. It's utterly bizarre.

[bd139]

But platforms don’t matter. Apple has just proven that by pulling the tablecloth out from under a full set again.

Kernels, compilers and programming interfaces do matter. They deliver the benefits to the end users which is where the entire purpose of computing is.

[Cerebus]

Yes, even with all that at its worst the PC was far more open than Macs will ever be ... that's how bad having a dominant Mac is. Yet somehow some people who can recognize those evils on PC are blind to the much greater evil of a dominant Apple. It's utterly bizarre.

Why don't we address that problem if and when Macs look like they might become market dominating. As they are nowhere even close to market dominating at the moment or in the foreseeable future your point is completely moot.

[magic]

An underdog company churns out decent products for a small clique of dedicated fanboys.
The company grows and erodes former monopolies, the fanboys go wild.
The fanboys don't see what's coming when their company becomes the next monopoly.

Many such cases

As far as I'm concerned, if it can't boot Loonix, it doesn't exist.
And by the way, I don't mean a five years old fork of then-bleeding-edge LTS release, thank you ARM.

RISC-V is trying hard to head that kind of thing off before it starts. Each SoC/board may need a custom 1st stage bootloader to initialize DRAM and various other things, but then it presents a standardized "SBI" ECALL interface and even the 2nd stage bootloader (e.g. Das U-Boot or similar) sees a completely standardized system and the same uboot binary can run on every system, as does Linux once you get that far.

Like PC BIOS and its IRQ calls? Not too bad (if it doesn't run in 16 bit mode, that is ).
But there is another part of the ARM disaster which is peripherals. IRQ controllers, PCI bridges, stuff.
Any plans to make them register compatible? A firmware API behemoth like ACPI coming?

[bd139]

There’s a difference between booting Linux and it actually working properly, a problem I regularly find. My T495s runs Fedora and after the last kernel update when you shut the lid it shits the kernel out. There was also a bug which I whined about loudly a few weeks back where the I2C / HDMI shit show (have you ever looked at the vile freedesktop code?) in a certain kernel decided to spin up a kernel task with 100% CPU on one core when running headless. Oh and don’t even get me started on trying to sort out a hosed systemd boot on LVM.

I am dying for some vendor lock in and half decent well tested platform integration. Never had any of this shit on Solaris, HP/UX or macOS. And they came with manuals!

I think we need to go back to the workstation model myself. I know that’s unpopular but the time cost for me when things go wrong is higher than any other cost.

[magic]

Well, I do admittedly tend to run LTS kernels and jump major releases once a few years for new features.
Also thinking about building myself a known good GTK2 desktop environment from source and forever forget about upgrade drama here. It will likely run future applications for many years, until X is completely displaced by that Wayland thing.

What I hate most is change for the sake of change. I used to actually like WinDOS back in the day. I hate what it is today. I have a permanent proprietary software PTSD, sorry

[bd139]

The LTS kernel on CentOS 7 was what was throwing the HDMI shit show  . There was a sweet spot where the development of Linux needed to hold up and do a proper QA run and that was around CentOS 6 with the old Gnome desktop. If they literally fixed all the odd bugs, edge cases etc then progressively added improvements rather than blow the entire universe away they'd be good. But the main failure of open source software is that if it's not interesting, like fixing bugs, it is rarely done. Only via attrition some core packages have become stable (GNU I'm looking at you). I notable exclude FreeBSD from this which is actually really a corporation run product and not an ecosystem (which is a good thing).

Same trouble with software PTSD. I actually just spent the last 30 minutes shitposting on a microsoft ticket about what a fucked up pile of shit I have to deal with at the moment. Wasting my time but it's cathartic. I also liked MS's historical platforms. My first paid dev work was on MS PDS 7 on MSDOS, followed by 16 bit Visual Basic. Both talking to Unixes behind the scenes but it was a nice time where things mostly just worked and fit in your head.

Anyway rant over.

I did a count up today on ARM CPUs in my house. I counted 22. I count 6 x86 cores. ARM has more than won.

[brucehoult]

I did a count up today on ARM CPUs in my house. I counted 22. I count 6 x86 cores. ARM has more than won.

I expect i could make a pretty good count of the x86 cores in this house. 32 in my Linux PC, 6 in the AMD 4500U laptop, 4 in the 2017 NUC, 4 in the 2011 MacBook Pro, 2 in the 2011 MacBook Air, 4 in the i7 4790K Linux machine I haven't turned on in five years. That's probably all.

ARM .. I wouldn't even know how to make an estimate.

Sure, I maybe know how many cores are in the M1 Mac, iPhone SE, iPhone 7, Apple Watch, Pi4, Pi3, Pi2, Pi1, Pi Zero, Odroid C3, Odroid XU4, Arty Z7 (ARM cores embedded in an FPGA), Blue Pill, Nucleo.

At least I know the main cores. But there can be others doing auxiliary tasks.  I've heard on good authority that x86 chips have an ARM core or two inside.

But what about my multimeter? Oscilliscope? Pulse Oximeter? Amplified speakers? 4K monitor? Ethernet switch? Wifi router? MIcrowave oven? Dishwasher? And I'm sure a host of things I've not thought of right now. They might have ARM cores in them -- or maybe PIC or AVR or MIPS.

I have over 40 RISC-V cores in my house. By mid January it will be over 50 as the Icicle FPGA board and HiFive Unmatched will bring 5 each.


I think it was Horace Dediu who said that in the 1950s people knew exactly how many electric motors they had in their house, but by the late 1970s or 1980s no one had any idea how many they had. And in the 1970s and 1980s people kew exactly how many CPU cores they had in their house.

[magic]

But what about my multimeter? Oscilliscope? Pulse Oximeter? Amplified speakers? 4K monitor? Ethernet switch? Wifi router? MIcrowave oven? Dishwasher? And I'm sure a host of things I've not thought of right now. They might have ARM cores in them -- or maybe PIC or AVR or MIPS.

Consumer network gear was almost exclusively MIPS, though ARM is making some inroads this decade.

[borjam]

There’s a difference between booting Linux and it actually working properly, a problem I regularly find. My T495s runs Fedora and after the last kernel update when you shut the lid it shits the kernel out. There was also a bug which I whined about loudly a few weeks back where the I2C / HDMI shit show (have you ever looked at the vile freedesktop code?) in a certain kernel decided to spin up a kernel task with 100% CPU on one core when running headless. Oh and don’t even get me started on trying to sort out a hosed systemd boot on LVM.

Several years ago I gave some FreeBSD advocacy talks on Linux conferences in Spain. Quite a risky prospect when, for example, I criticized the stupid tendency to make "ls" a package, diff another package... I compared it to SCO Unix which sold separate packages for "Text processing", "Development", "TCP/IP *runtime*", "TCP/IP Development" (necessary for compiling any sockets based application) etc.

And yes, most of the penguin fanboys at least at the time were just bonsai enthusiasts. They kept installing packages and "hey, this works!" but they used Windows even for web browsing.

I think we need to go back to the workstation model myself. I know that’s unpopular but the time cost for me when things go wrong is higher than any other cost.

The closest thing now is Macos. At least I can compile and run stuff in C and Python without any troubles.

[bd139]

If you think that's bad you want to see it taken to the extreme. NodeJS is the outcome of years of working out how to fuck up completely. I imported one small package and it imported 100 dependencies in a massive tree 

This is why I like Go. Productive out of the box, no frigging dependency hell.

[borjam]

This is why I like Go. Productive out of the box, no frigging dependency hell.

Yep, I agree. I got the book last month and I'm really impressed. I guess it's going to become my next goto language. Pun intended

[bd139]

It has become mine. Basically all I wanted was C with Unicode, some object orientation, without as many footguns, some concurrency primitives and a decent standard library and I got it!

[brucehoult]

It has become mine. Basically all I wanted was C with Unicode, some object orientation, without as many footguns, some concurrency primitives and a decent standard library and I got it!

Have you looked at D? It's along similar lines, has been around since 2001, and is mature.

[bd139]

I did for a month or so. It didn't stick. The standard library that shipped with it wasn't particularly mature and there were some gaping holes in it. It never felt it had momentum behind it either.

I think one of the attractive thing about Go is it's actually really easy, especially when it comes to concurrency matters. It is reminiscent (invoking tggzzz here) of Hoare's CSP paper. One of the things I tend to end up building is high performance messaging, filtering and routing engines and the abstractions allow you to compose your software using functional elements connected by channels. While the last one I built was a monster .Net / CLR thing that used async, Task APIs and the concurrent collections API, they were really a poor abstraction model for highly concurrent systems. Unfortunately necessity was that I used the tools available. I rebuilt a chunk of the platform in Go in a few days, a surprise in itself, and found out a couple of even more surprising things. Firstly it used 15x less RAM using the same workload test harness. When your memory ceiling on a single .Net process hits 1TB due to GC it gets interesting in the cost and reliability department. When inevitably one of the spinlock and interlock implementations inside CLR decides to give out, because quite frankly they were written by morons, there's no chance you're ever going to be able to debug that dump. Go, no problems. It never went wrong even chunking through 70Gb of RAM. Secondly I added prometheus metrics wrappers around the channel delivery parts which allowed me to do dynamic analysis of the bottlenecks and optimise worker pools etc. The final surprise is the reduction from about 100kloc of C# to just over 12kloc of Go.

I tried to sell it back to them. They didn't want to know 

Anyway I'm waiting for them to release a proper darwin/arm64 port at the moment. I'll be using Linux x86 for now.

Edit: actually I didn't check before but it does work via Rosetta fine by the looks. I was a little worried about signing issues...

[Marco]

A benchmark I'd like to see ... the pigz test arstechnica did, running repeatedly for about 5-10 minutes, showing how performance evolves and if possible some power measurements near start and finish (from mains socket). Both with 4 and 8 threads.

I'd like to know just how little the little cores contribute, especially in temperature constrained situations.

[brucehoult]

My experience so far is the little cores contribute pretty much the same as HyperThreading does on Intel. All four little cores together add maybe a little more processing power as one more big core would.

I haven't seen any throttling at all so far. The thing is always a cold chunk of aluminium.

[bd139]

Yep same experience with the temperature.

I managed to get Rosetta to puke earlier though on a Go binary. Opcode translation error when I hit Ctrl C. Not sure exactly what happened there to be honest. Couldn’t reproduce it a second time. Bogons!

I am seriously impressed though as it has been daily driver machine. Flawless so far.

[brucehoult]

I demo'd mine at a small meeting last night.

Someone asked about Handbrake so I installed that and we tested against a recent thin and light high end Dell laptop (I didn't get the exact model), same video source same presets. The Mac in Rosetta did 180 FPS, the PC 38 FPS.

Interestingly, the beta native ARM version [1] of Handbrake got only 120 FPS. I guess Apple has done more ARM SIMD optimization than Handbrake / ffmpeg have, so far.

[1] actually the same app download, just testing with and without "Open in Rosetta" checkbox.