Slashdot Mirror
Why Linus Torvalds Prefers x86 Over ARM (pcworld.com)
Linus Torvalds answered a question about his favorite chip architecture at the Linaro Connect conference. An anonymous Slashdot reader quotes PCWorld:
People are too fixated with the instruction set and the CPU core, Torvalds said. But ultimately "what matters is all the infrastructure around the instruction set, and x86 has all that infrastructure... at a lot of different levels. It's open in a way that no other architecture is... Being compatible just wasn't as big of a deal for the ARM ecosystem as it has been traditionally for the x86 ecosystem... I've been personally pretty disappointed with ARM as a hardware platform, not as an instruction set, though I've had my issues there, too. As a hardware platform, it is still not very pleasant to deal with."
You can watch the whole half-hour conversation on YouTube. My favorite part is where Linus candidly acknowledges that "sometimes my grumpiness makes more news than my being nice... 99% of the time I'm a very happy manager, and I mentally pat people on the head all the time. That maybe then highlights the times when things don't work so well a bit more."
You can watch the whole half-hour conversation on YouTube. My favorite part is where Linus candidly acknowledges that "sometimes my grumpiness makes more news than my being nice... 99% of the time I'm a very happy manager, and I mentally pat people on the head all the time. That maybe then highlights the times when things don't work so well a bit more."
I guess it's fitting that he doesn't realize patting someone on the head is a condescending gesture.
As Linus says, the main issue with ARM is not the CPU core but all the other stuff you need to make a computer. On x86 most of it has become standardized, even if the standards are terrible. On ARM manufacturers do their own thing and produce a "board support package" (BSP) that provides semi-standard interfaces to it, but of course it's a pain for an open OS like Linux to deal with and many of them are not interested in providing enough documentation for native drivers to be written.
ARM is kind of a pain in the arse to do low level development for due to the BSP stuff, but on the other hand in the low power/low cost segments x86 isn't even a player. You can get low end ARM parts for less than a Euro. If they were not such a bugger to work with they would be displacing 8 bit parts at a much greater rate, but 8 bit's simplicity keeps it popular.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
There is no reason to coddle developers who write shit code.
And make no mistake, ARM driver developers employed by ARM vendors are truly horrifyingly bad programmers.
Well... he has a point on all fronts.
1) x86 is so backward compatible it's... grand. Except for legacy bugs to push forward
2) ARM is, or rather, was, not afraid to put efficiency above complete and total backward compatibility
Except what he was really talking about was x86-based "IBM-compatible personal computers", which have, in at least some layers other than the instruction set, a lot of similarity, vs. ARM-based {smartphones, tablets, embedded systems, etc.}, where everything other than the CPU may be significantly different from system to system.
That has nothing to do with the instruction sets, it has to do with the fact that x86 got its big boost from the IBM PC and the clones of it, which were all pretty similar machines so that MS-DOS and its successors would Just Work on them, while ARM got its big boost from phones/tablets/embedded boxes, where the vendor supplied some or all of the OS, and they didn't care much about having to tweak the OS for the next machine.
If ARM had a BIOS with PnP it'd be most of the way to solving this.
That little HAL we all ignore goes a long way.
As usual Linus is talking 'general' but thinking focused. :embedded.
What he is actually talking about is high level computers (which these days includes smartphones, tablets, etc however there is a little
more crossover there).
Where he has no knowledge, understanding, or consideration is lower level applications - ie
Arms flexibility, and tendency to closely integrate hardware at the low level makes it is fantastic micro CONTROLLER implementation in general.
The STM32 series are a great example of this, and it is an area that Intel seems to have lost the plot on. Despite Intels gushing money from time
to time into such areas, very very few would touch them with a barge pole. Their IO infrastructure is just TOO complex and unnecessary for such
applications (no one there uses PCIe, etc. Even USB tends to emulate a serial device).
In the mid range - ie: cellphone, tablet, etc ARM Chip sellers integration is great, however their documentation is TERRIBLE, and they do not seem to understand that open hardware specifications are gold (I am looking at you allwinner, rockchip, amlogic, himedia, mediatek, etal) and who dont seem to realise that sharing that knowledge gets a LOT more developers on side (or possibly hide it because of IP fears... who can be sure). There are vendors without
such problems however (generally but not exclusively the non-chinese chip makers).
In the high end - PCs, Servers, etc. well, thats a mess right now. Perhaps AMD etc will help sort it out, or perhaps not.
In the end, ARM makes sense in a whole lot of niches, however not really those Linux focuses on - his primary focus has always been large server and workstation hardware, an area ARM is only just starting to overlap into in a small way.
So, what he says is factual in one area, but that area is a niche to arm, and a stronghold of Intel, so is it really a surprise?
Grumpy dude is grumpy for a reason, and the ARM world not being a platform but a collection of one-of devices is part of that reason. Have you never wondered why there isn't an installer for Android which you can use to install a fresh OS on any ARM phone? That's what Linus is talking about: There is no ARM platform which would enable this. That's why Android is a firmware construction kit, not an installable OS, a fact that I have been preaching for several years. If ARM wastes more time, Intel will eventually usurp the mobile market by being more "compatible".
Android suffers this very issue, where you end up needing a bytecode VM (Dalvik) just to ensure compatibility across devices. This doesn't mean that the ARM instruction set isn't a joy to work on though.
Plug and play along with BIOS are not the words you want to use. Standard firmware interfaces and IO/memory maps would be more appropriate. We don't want a repeat of the bad old days.
You can't fire the dictator.
But you can emigrate. "Of course it runs NetBSD!"
He is talking about THE LINUX KERNEL which runs on more than desktops and mobile devices. how can you comment on things like this with your deficient ability to comprehend basic information?
Chill down son. Like it or not, mobile device are by far the largest Linux install base in the world, with roughly 80% of all phones sold each year running Android (meaning Linux on ARM). This is orders of magnitude above desktops, let alone embedded devices. As the head kernel maintainer rest assured, the guy is plenty aware of the shortcomings of that platform.
2) ARM is, or rather, was, not afraid to put efficiency above complete and total backward compatibility
They were only "highly efficient" because they were not high performance. They've tried to make CPUs as powerful as x86 cores, but they consumed much more power and still quite weaker. This has been their weakness in the datacenter. All of the power savings is lost to needing more cores and systems. Great embedded type systems, or possibly low end desktops, but horrible for most workloads for high-end servers.
That's because you're too soft and your ego writes checks your intellect can't cash.
That has nothing to do with the instruction sets, it has to do with the fact that x86 got its big boost from the IBM PC and the clones of it, which were all pretty similar machines so that MS-DOS and its successors would Just Work on them, while ARM got its big boost from phones/tablets/embedded boxes, where the vendor supplied some or all of the OS, and they didn't care much about having to tweak the OS for the next machine.
Not to mention the fact that computers have always had all sorts of expansion cards and peripherals so you needed a general system to discover what you have installed right now and what it's capable of, as well as a layer of OEMs mixing and matching. A phone comes as one fixed hardware package, often a complete system on a chip. You can get away with a blob that assumes that's the way everything is and unlike PCs it seems acceptable that they go out of support after a few years.
Live today, because you never know what tomorrow brings
It is actually also a major problem for many embedded devices. Have you really looked at the DD-WRT project lately? It is completely dead, largely due to the lack of a common platform. My embedded router is in the rubbish heap now, we have switched to an x86 device running normal Linux...
I am probably not the only one that has a drawer full of devices and SOCs with ARM processors on them that I thought would be more useful than they turned out to be. There's nothing wrong with the ARM processor itself, it's just the funky bootloaders and proprietary peripherals with proprietary firmware, and custom kernels that make them a lot less useful to me than if someone made a little x86 SOC with a full complement of I/O pins (including a ADC) with a normal EFI/BIOS.
For some things like my router/firewall, I thought a little ARM-based device would be perfect, but it turned out that a Intel NUC with an micro SD card ended up being easier to deal with (though an order of magnitude more expensive). Easier to keep updated, and can run a stock distro.
I just saw that GlobalScale is producing a new ARM board aimed at networking, which looks interesting, but it's the nearly the same hardware as their old Plug computer products (only 1.2 GHz but with a lot more RAM), married to a 3-port gigabit switch fabric. Still means dealing with a custom/proprietary uboot loader, flashing kernels, etc. Not something I care to deal with anymore.
Of course other devices are different and easy to boot off an SD card. But that's the problem, isn't it. There's no such thing as an ARM version of Debian that runs on all ARM devices. We have to have custom spins for each board. They may as well be their own complete platform, which is impossible for Linus and crew to deal with. So we have to rely on vendors to supply custom versions of the kernel and matching distro.
The thing is, a PC is really just one hardware design. Memory is in one fixed spot in the memory map. I/O is in the same spot (in the IO bus, since it's x86... but even so..).
It's at the point where you could take any x86 based PC and program it because you know where all the components are. If you need to talk to the VGA adapter, well, the framebuffer is always in the same location.
And we have to admit, what we call "x86" really is "IBM PC Compatible" because there were many x86 designs in the early days that were not compatible. We just happened to base our modern PC design off of what is now a 30+ year old PC design. Heck, I think Intel emulates the A20 Gate functionality on the CPU (a design leftover from the move from 8086 to the 80286) - there is a pin that basically states the value of the gate.
Add in the other peripherals that are basically identical like keyboard controllers, DMA controllers (not used anymore), etc, and you have what is effectively just a single hardware platform. It doesn't matter if you have Intel or AMD or nVidia graphics - at a basic level, VGA mode works identically on all of them.
ARM, on the other hand, isn't a monolithic design - it's a CPU core and people attach peripherals to it to meet the design requirements. There is no universal keyboard controller for ARM, because one doesn't exist - some devices have no keyboards and don't need it, others have a full PC keyboard, and yet others still have a basic one able to scan 16 keys in a 4x4 matrix.
The biggest difference is that most x86 designs are not SoC based - so your options aren't as fixed. If you want a different graphics chip, it's usually external, etc. But for ARM, they are SoCs and thus everything is combined to form an almost complete system in a single chip - no CPU, northbridge, IO controller(south bridge), etc type PC design.
And lest we forget, x86 can be incompatible - Intel made a few SoCs that run fine on Linux, but cannot run Windows at all because Windows requires things a certain way, which was not provided. Even today, Intel SoCs often have a "Windows compatibility" block that contains peripherals and other things required for Windows support.
In the end, a PC is like a car - it has 4 wheels, a steering wheel, a transmission, etc, and they all basically drive the same - you need a key, you need to start the engine or activate the card via the ignition (for EVs or hybrids), apply brakes, release the parking brake, shift transmission into reverse, then back out of your spot. Then put the transmission into drive, press down on the accelerator and off you go.
ARM would be more like Caterpillar or Briggs and Stratton - they sell the engine, which forms the core of whatever, but the final vehicle may not be a car. It may have treads instead of tires, use a differential control mechanism, etc. Or the vehicle's movement may not be related to the engine at all
If ARM wastes more time, Intel will eventually usurp the mobile market by being more "compatible".
Um, what percentage of phone buyers do you think are interested in their phone being a fully open hardware platform? Don't get me wrong I'd love it to exist, but people aren't going to abandon closed-source SoC based phones because of it.
Seeing a computer as a mini-network is a change that needs to happen. Having mini ARM cores doing things like coordinating I/O and graphics, so that all the main processor sees is somewhere to send instructions in a standard language (kind of like Vulkan is doing with graphics, and kind of like Postscript in some ways), so all that 'board support' stuff can be moved away from the main CPU, and all the complex compatibility and driver code isolated to a separate, low-power core. That could be down with both ARM and x86 machines very easily, and to my mind would enable massive increases in efficiency, shifting a lot of the menial work currently done by an OS running on CPUs which are often way overpowered for these menial tasks, and which have to timeslice between user programs and housework. In the old days, coprocessors were a necessity in many things, and I think going forward, seeing a computer as network of coprocessors, with the main CPUs being essentially there _only_ for high-level user computation tasks (deciding what to write in a window, rather than how to put the window onscreen, or move it about). The funny thing about X-terminals is that with the hindsight of 3 decades, and the kind of graphics languages we have in things like PDF and Postscript (and how Apple used this model in Quartz), doing X-terminal type things, but over the PCIe bus, rather than 10Mb ethernet, would work wonders. (This would in no way get in the way of efficiency, since you could still throw textures and command buffers, or software-rendered windows, across the PCIe bus as we do with current architectures, but simpler things like window-drawing, and rendering PDF-type documents to the screen, as Quartz does, could easily be done with lightweight CPU cores on the GPU, and a better integration between the two: imagine being able to create a texture buffer in GPU memory, and write to it by the CPU sending postscript drawing commands, or creating a dialog window and sending content to it as AJAX does over the net, but with the network being the PCIe bus, and so on. Then do similar with sound and DSP. Economies of scale is where the major step forward would happen.)
John_Chalisque
"Have you really looked at the DD-WRT project lately? It is completely dead, largely due to the lack of a common platform."
That's a tiny part of it. The _other_ part of it is that (fancy management GUI aside) OpenWRT kicked the everloving shit out of DD-WRT in terms of capabilities and code quality for _years_. DD-WRT was _dead_ eight years ago... it just couldn't compete with OpenWRT.
That was certainly true in the ARMv4-5 time. It's somewhat true for ARMv6. For ARMv7 and ARMv8, it's far less true. There's a lot of standardisation of bootloaders, interrupt controllers, and so on, to the extent that FreeBSD is now able to ship a single kernel for relatively modern (RPi and newer) ARM devices that selects drivers based on the FDT or ACPI in the same way that the x86 kernel does with ACPI.
I am TheRaven on Soylent News
Agreed- today in ARMv8 land, it's actually not too bad to work with at all at low-level.
Before ARMv7, it will still common to find vendor-specific MMU implementations (fucking kill me)
Linus' argument will wash anyone who's worked with ARM since the early days with nostalgia and nausea. They know what he's talking about.
But it just really isn't the case these days.