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."

Comments

Well... he has a point on all fronts.

[Anonymous Coward]

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

3) He get's a whole lot of news for being an ass. And that may help /. because I always come here to see the comments after news of a Linus blowup. It's awesome, coming from a multi-disciplinary background where job A's culture is nothing like job B... but oh, would it be great to combine the two! Billion-dollar sovereign debt deals and computer science. I wanna be able to yell at these geniuses like those assholes yell at those assholes. Uh... makes me get all warm down there.

Re:Well... he has a point on all fronts.

[AmiMoJo]

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.

Re:Well... he has a point on all fronts.

[Guy Harris]

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.

Re:Well... he has a point on all fronts.

[Anonymous Coward]

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.

Re:Well... he has a point on all fronts.

[ruir]

Your first point is spot on. x86 has been always backward idiocy has a big part of the chip is dedicated to compatibility with the past. Similarly a big part of the ARM processors is dedicated to video instructions.
The Intel architecture has a horrific trend in what touches security. You cannot do away with firmware signed by Intel. Similarly in some ARM architectures, namely raspberry PI, you are suffering from the same exact problem.
It is virtually impossible at the moment to design a product based in an Intel chip that respects your privacy.
You also have problems in lot of ARM boards where the code is sloppy hacked by the vendors, and you are limited to the kernel version they hacked, having a dead-end product.
MIPS has had always had an interesting architecture design, pity it has lot a lot of traction, and the Chinese seems to have abandoned the Longsoon project, at least for selling abroad.
At the moment, you have too spectrums of the market gaining momentum, ARM machines for low cost servers and private computing, and Intel for virtualization farms. So pick up your poison carefully...

Re:Well... he has a point on all fronts.

[Anonymous Coward]

That is it right there. The BSP issue is huge. Everyone wants to be 'the one everyone else follows'. PC already had that moment in the mid 80s. If you want to be a PC you have to expose particular things. If you want to use ARM everything is slightly different all over the place.

It is one of my big problems I have with IoT in its current state. No one wants to follow everyone wants to lead. So you end up with hundreds of fragmented systems. Systems that fall by the wayside once interest from the company is lost. So we will end up with millions of slightly powerful computers that are all out of date and insecure. Unless someone steps up and fixes that particular item. But it does not flow across the whole eco system just for that one board. Many times it does not even move between a 'family' of boards.

With a 'PC' sort of system you have a shot at replacing it in place and the new one 'just working'. With ARM they are wildly cheaper up front. But have little after the sale maintenance.

In some cases with ARM people are building up that eco system (PI, etc). It will be slow going. It is basically the early 80s with hundreds of slightly different computers all over again with no clear winner at this point. For hobbyists its great. For those who just want to use stuff for a long time not so much.

Re: Well... he has a point on all fronts.

[Anonymous Coward]

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.

Re:Well... he has a point on all fronts.

[Shane_Optima]

You can get low end ARM parts for less than a Euro.

But how indicative is this of the way things must be? The 386 is over 30 years old. 686 procs are 20 years old. All we need is one company who can envision a market segment for low cost x86 (something like Raspberry Pi x86?) so that someone will put in the legwork required to develop a royalty-free or low-royalty product.

Re:Well... he has a point on all fronts.

[SumDog]

I'm struggling with Arbian and ArchArm on a ClearFog Pro right now. Wi-Fi drivers like to have all kinds of weird problems. I can't just cross compile a newer kernel to see if the problem is fixed, because the kernel for the Clearfog has a lot of specific kernel patches. Even though ARM boards support the standard PCIE and USB buses.

If I had to do this again, I would have tried to find a small x86/Atom style board. That way I could use Grub/EFI and the tools I'm familiar with.

Re:Well... he has a point on all fronts.

[Guy Harris]

It wouldn't surprise me to find out any lack of backwards compatibility in the ARM arena is due to Google's desire to cram the latest spyware down our throats:

It would surprise me a lot, because Google doesn't design the SoCs that go into Android machines other than maybe those with "Nexus" or "Pixel" in the name, so they're not the ones responsible for the lack of backwards compatibility between Zombo's ZomboFone F1 and their ZomboFone F2.

Re:Well... he has a point on all fronts.

[Bengie]

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.

Re:Well... he has a point on all fronts.

[Shane_Optima]

That baggage existed a few years ago, but unless someone managed to somehow get an extension on some key patents (I'm fuzzy on how that works) we should fast be approaching the point where the fundamental technology are royalty-free. It's true that the SoCs will still be patent-encumbered but the 'support chips' of 20-30 years ago should also be exiting patent status. Trademark issues are easily bypassed, though they can sometimes make the marketing a little trickier.

Re:Well... he has a point on all fronts.

[Shane_Optima]

An x86-based Pi won't be any easier than an ARM based Pi because it won't have the full BIOS, PCI bus, keyboard controller, A20 gate control, southbridge, northbridge etc that the x86 Linux kernel de-facto targets.

Those technologies should be exiting patent alongside the x86 processors themselves. It's a pity that we won't have a SoC exit patent anytime soon (unless there's something I'm not aware of), but it should still be possible to produce a very cheap board that's capable of running arbitrary Linux distros (and also a few non-Linux OSes) basically right out of the box.

Re:Well... he has a point on all fronts.

[ruir]

And that is exactly I have not bought a Clear Fog/Omnia Router. I also bough a Lamobo R1, that nowadays compiles a generic kernel, and I ended up cutting physically the wifi chip because realtek sucks bigtime, and use it as my home server. For Wifi, an archer C2 with OpenWRT is doing a great job for much, much less than a ClearFog Pro.

Re:Well... he has a point on all fronts.

[Kjella]

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.

Re: Well... he has a point on all fronts.

[dunkelfalke]

Heh, i am glad i am not the only one thinking that way, also in regard to Windows Mobile 6.

Re:Well... he has a point on all fronts.

[tlhIngan]

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.

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

Re:Well... he has a point on all fronts.

[Lennie]

of course it's a pain for an open OS like Linux to deal with

Microsoft has the exact same problem.

Re:Well... he has a point on all fronts.

[John Allsup]

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.)

Re:Well... he has a point on all fronts.

[TheRaven64]

Pretty much all vaguely modern ARM SoCs have FDT in the firmware (some of the server-oriented ARMv8 ones use ACPI instead). This provides the default memory maps, the locations of devices, the names of the drivers needed to use those devices, and so on. They also all typically now use an ARM GIC (earlier ARM SoCs often used incompatible vendor-provided interrupt controllers, which made life a bit more painful) or, if not the ARM implementation, something that exposes the same interfaces.

ARM has done a huge amount in terms of ecosystem standardisation over the last decade. Linus sounds like he hasn't looked at ARM since 2005.

Re: Well... he has a point on all fronts.

[the_humeister]

That's not really true. All my PCs (laptop and desktops) that run Debian all boot using 64-bit UEFI. That means no need for real-mode shenanigans to finally get into 64-bit mode from 16-bit mode. ARM systems could have standardized on UEFI, but most of them don't use it. About the only ARM devices that do use UEFI are the server oriented devices and Microsoft's phone and tablet.

Re:Well... he has a point on all fronts.

[unixisc]

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

3) He get's a whole lot of news for being an ass. And that may help /. because I always come here to see the comments after news of a Linus blowup. It's awesome, coming from a multi-disciplinary background where job A's culture is nothing like job B... but oh, would it be great to combine the two! Billion-dollar sovereign debt deals and computer science. I wanna be able to yell at these geniuses like those assholes yell at those assholes. Uh... makes me get all warm down there.

1. Some of the bugs were sidestepped or avoided when AMD first moved the ISA from 32-bit to 64. A lot of the CPU efficiencies that were learned from the CISC vs RISC era were implemented on the 64-bit only side of instructions, so that if at any point in future, a CPU drops 32-bit support and becomes 64-bit only, it will either be a down and out RISC CPU, or something real close.

2. The issue is more that every ARM vendor is at liberty to implement a CPU any way they see fit. Which is great in terms of autonomy and individual creativity of each vendor - be it Apple, Qualcomm, Allwinner, et al, but it also makes it hard to support ARM as a general platform. If you get an x86 based subsystem, you know that it'll work w/ anything written for the x86 - from Windows to Linux to BSD to Minix, and the only limitation would be configurations, such as amount of RAM, storage, et al. With ARM, you'd have to look at the actual manufacturer to see whether their specific implementation of the instruction set is supported by the software

3. The 2 job cultures may be different but they are closely related: if one is making a CPU, one does have to be mindful of what existing or new software will support it. Not doing so gives us fiascos like the Itanium, which was originally conceived of as a VLIW CPU. Something that in its purest form would break software compatibility with every generation. None of the geniuses at either Intel or HP stopped to wonder what would happen if ISVs had to recompile their software every time a new die was out. Today's Itanium is more RISC than VLIW, but the damage has already been done. If any CPU architecture or platform wants to be successful, they'd do well to formulate the software forces behind their marketing strategy

Re:Well... he has a point on all fronts.

[unixisc]

This is fantastic news. MIPS is a nice sweet spot b/w the performance of x86 and the power consumption of ARM, yet gets no attention from either Apple nor Google nor Microsoft. Let the Russians adapt it and make it the basis of their current and future computing platforms. Also, if they can get something like ReactOS running on it, it will be a full home grown equivalent of the erstwhile NT on MIPS that Silicon Graphics and NeTpower once contemplated.

Re:Well... he has a point on all fronts.

[unixisc]

Wondering another thing - does Baikal Electronics mean it's located somewhere in Siberia, or is it a Moscow based company?

Re:Well... he has a point on all fronts.

[david_thornley]

Microsoft had nothing to do with the beginning of PC BIOS. That was introduced by IBM with the original IBM PC, which was around for about five years before the first really crappy version of MS Windows appeared. Wintel was a considerably later development.

I don't know much about the design decisions for the original IBM PC, except that it was a quick design with as many off-the-shelf components as possible, so it may well be that Intel was behind the original BIOS.

Re:Linus should be laid off, right now.

[Anonymous Coward]

What you are saying here is the rock equivalent Van Halen should fire Eddie Van Halen. Things that just cannot happen. It just wouldn't be right, you know?

Re:Linus should be laid off, right now.

[amiga3D]

You can't fire the dictator.

Fitting

[GrahamJ]

I guess it's fitting that he doesn't realize patting someone on the head is a condescending gesture.

Re:Fitting

[ShanghaiBill]

I guess it's fitting that he doesn't realize patting someone on the head is a condescending gesture.

That is culture dependent. In some cultures patting, or even touching, someone's head is offensive. In other cultures, it means nothing.

I have met Linus a few times on a person-to-person level, and he was always friendly and considerate. Tove is also a very nice person.

Re:Fitting

[Shane_Optima]

I guess it's fitting that he doesn't realize patting someone on the head is a condescending gesture.

There, there. You know you're special, right? That's all that matters.

Re:Fitting

[wjcofkc]

Try giving the a-okay sign in Argentina. That is a sure fire way to kill a deal.

Re:Fitting

[Blaskowicz]

I'm not even Argentinian but that looks like drawing a butt hole with your fingers and that's not a very good idea. Though in France, it might mean a derogatory "zero", which is slightly better than a butt hole but still sucks.

Re: Fitting

[ph1ll]

He is European so he probably understands irony.

Re:Fitting

[Anonymous Coward]

I guess it's fitting that he doesn't realize patting someone on the head is a condescending gesture.

It's even more fitting that people who have decided to hate Linus, regardless of what he does or says, will indeed find fault in anything he does or says, even actively misconstruing good things to make them look bad.

Re:Fitting

[Anonymous Coward]

> Tove is also a very nice person.

You're just saying that because she is a six-time Finish Karate champion.

ARM driver vendor code is atrocious

[nyet]

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.

Re:ARM driver vendor code is atrocious

[Anonymous Coward]

There's a lot of truth in that statement. To make matters worse, I've seen an appreciable number of cases where perhaps 75% of the code for something is either okay or actually pretty nice, but there are also really shitty chunks that appear to have been written by people under the influence of a random assortment of hard drugs sprinkled across the whole codebase. This can make further work quite "challenging" sometimes. -PCP

Captcha: simplify

Re:ARM driver vendor code is atrocious

[arglebargle_xiv]

It's not just the code, it's the hardware environment as a whole. Every single freaking ARM SoC is a custom special-snowflake device with its own special-case add-on IP cores, Chinese-menu instruction set (we'll do this extension, and that one, but not that one over there, and the config register read that tells you whether it's available is privileged to it'll trigger an exception if you try and read it), undocumented memory-mapped crap, or a 1,000-page manual with partial documentation which in any case changes completely if you order an XYZb rather than an XYZa even though it's the same family from the same manufacturer. Just the perfect environment for vendor lock-in, but terrible for devs.

Re:ARM driver vendor code is atrocious

[arglebargle_xiv]

I've seen an appreciable number of cases where perhaps 75% of the code for something is either okay or actually pretty nice, but there are also really shitty chunks that appear to have been written by people under the influence of a random assortment of hard drugs sprinkled across the whole codebase.

See my other comment, the Arm environment more or less drives that, you've got 75% that's common and the remaining 25% is semi-documented special-snowflake crap that you have to reverse-engineer from partial docs in order to get it to work.

Re:ARM driver vendor code is atrocious

[TheRaven64]

Your post is still entirely true if you delete all occurrences of the word 'ARM'.

He is dead right for PCs, Dead wrong for embedded.

[thesupraman]

As usual Linus is talking 'general' but thinking focused.
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 :embedded.
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?

Re:Grumpy Old Man

[Anonymous Coward]

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".

He is right though

[Lisandro]

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.

Re:He is right though

[Alomex]

Dalvik is last generation. Latest iteration is the Android Run Time (ART) which compiles once at installation time, according to the specific device.

Re:He is right though

[Lisandro]

Same deal. The problem is deeper than just applications though - this is also the reason why you can't have a generic Android installer for multiple platforms.

Re:He is right though

[Guy Harris]

Android suffers this very issue, where you end up needing a bytecode VM (Dalvik) just to ensure compatibility across devices.

There's no need for a VM to isolate differences between 32-bit ARM CPUs; if you want to support both 32-bit and 64-bit ARM with the same binary, or support ARM and x86 with the same binary, a bytecode interpreter/JIT is one way to do that, but you don't need it to support two machines using the same CPU or using compatible CPUs, and it's not the only way to handle it (you could do fat binaries, as Apple does in iOS, for example).

The issue in question is not with the ARM CPU cores, it's with the stuff around it in the SoC, and the OS (kernel, graphics layer) deal with that - applications don't have to.

Re:He is right though

[Lisandro]

Or, you can get a x86 platform with offers backwards compatible instruction sets and relatively standardized architectures.

The problem with ARM goes way beyond CPU compatibility, which is the point made by Linus in the video: there's just too many CPU+hardware combinations out there, all (mostly) incompatible with each other. Apple gets away with multi-platform (fat) binaries simply because their ecosystem is way more constrained.

Re:He is right though

[ShakaUVM]

>This doesn't mean that the ARM instruction set isn't a joy to work on though.

Yes, I'm glad somebody here said this. I have programmed assembly for x86, 68k, MIPS, SPARC, etc., and ARM is my favorite by far to program in. It's very sane and sensible. The ISA's documentation is... ok, there could be better documentation on ARM's part, but it's good enough I suppose.

I was able to take an image manipulation library function call written in C++ from 6 seconds to .03s using assembly in about an hour's work. (A 4K image file held in memory, processed by a RPi 2.) That would be good enough to do sepia toning in real time on a 4K video stream if the RPi 2 was actually capable of doing I/O fast enough to feed the function.

Re:He is right though

[Lisandro]

I remember having a "whoa" moment the first time i found out ARM supported free bitshifts witihin a MOV.

Re:He is right though

[Guy Harris]

The problem with ARM goes way beyond CPU compatibility, which is the point made by Linus

And by me in the last paragraph of the posting to which you responded.

There are the CPU issues, such as "what version of VFP does the processor have, if any?" and "does the processor have Advanced SIMD?". The NDK has an API that can be used to get the answer to those questions (and to similar questions for x86 and MIPS), and there are the "rest of the platform" issues. The former may affect applications, but the latter don't, so the VM isn't needed to handle the latter, nor are fat binaries.

Apple gets away with multi-platform (fat) binaries simply because their ecosystem is way more constrained.

Again, the "rest of the platform" issues aren't relevant here, other than perhaps screen size (iPhone vs. iPad). I'm not sure what processors Apple's used have in the way of floating-point or SIMD support, so I'm not sure what flavors of "fat" are needed other than "ARMv6 vs. ARMv7 vs. ARMv8-A 64-bit".

Re:He is right though

[Lisandro]

There are the CPU issues, such as "what version of VFP does the processor have, if any?" [...]

Which is also tackled in the x86 world...

Again, the "rest of the platform" issues aren't relevant here, other than perhaps screen size (iPhone vs. iPad). I'm not sure what processors Apple's used have in the way of floating-point or SIMD support, so I'm not sure what flavors of "fat" are needed other than "ARMv6 vs. ARMv7 vs. ARMv8-A 64-bit".

ARM11 (iPhone 1 to 3), A4 (iPhone 4), A5 (iPhone 4S), A7 (iPhone 5), A8 (iPhone 6), A10 Fusion (iPhone 7). And that's just for their phones.

Re:He is right though

[TheRaven64]

If an algorithm is I/O-bound, running it on a faster processor with slower I/O will likely not make it faster.

Re:He is right though

[AmiMoJo]

Wow, that must either be a seriously crap compiler or some very badly optimized C code. Perhaps the compiler couldn't vectorize it? We had a similar issue with older versions of GCC that was fixed by using in-line assembler Neon instructions, but newer versions and some carefully written C allow the compiler to get the same result in a more maintainable, portable way.

Re:He is right though

[Anonymous Coward]

ARM is a "joy" when you are writing bog-simple single-threaded code.

For anything else (say, like a *kernel*), it is an utter pain in the ass due to the need for explicit synchronization everywhere. If you don't even know what I am talking about, you are not entitled to judge anything related to low-level multi-threaded programming.

X86 is quite a hideous ISA, but it gets *one* thing right: it is easy to write correct multi-threaded programs in it, as it is fully coherent. ARM doesn't have even that much.

Granted, you can just add full barriers everywhere (and you can have the compiler or assembler do it for you), but that will bring down performance to a crawl if you need to do it in any hot paths.

Re:He is right though

[Anonymous Coward]

I doubt anybody ever /needed/ yet another shitty java VM.

The big heads decided to repeat that mistake based because of their groupthink and incompetence, and then the code monkeys simply had to love and accept it.

Many applications that matter have their core written in C or C++ (which is the way to write something actually portable) and have it packed in separate ndk .so libraries for the different architectures (if they bother to support anything other than arm).

What is quite remarkable about Android is how fast it has degenerated -- it's not even 10 years old and it's already just as quirky, stupid, ugly and difficult, and unix-unlike as windows.

Re:He is right though

[lars_stefan_axelsson]

Word! I remember working (way back when) with a crypto co-processor that was fast. However, the bus(es) were so slow that we outperformed it by doing the crypto in SW on the main CPU instead... :)

Granted, the co-processor wasn't helped by not having enough storage/state to amortise the cost of key setup over multiple packets, we had to re-schedule the key with every bit of data sent to it. But hey in marketing I changed that to "Perfect key agility! Our competitors don't have that!" No, but that's because we were always "slow", i.e. we didn't reap any benefits from encrypting several packets with the same key... :)

Even so. It drove home the old truth that general programmable hardware is often faster than specialised. Even though that's slowly changing, there are still pitfalls in "GPU everything".

Re:He is right though

[ShakaUVM]

It was not vectorizing properly. I rewrote the library call in C++ and got it to vectorize correctly, which took it from 6 seconds to about 0.06 seconds, but with assembly I was able to beat it by a factor of 2. Again, without much work on my part.

Actually, the most time consuming thing was implementing the whole thing a fourth way using C++ intrinsics, which are supposed to compile down to assembly in an optimal fashion, but are sparsely documented and didn't end up being any faster than what the optimizer was able to do.

Re:He is dead right for PCs, Dead wrong for embedd

[Lisandro]

He's indeed talking about desktop and mobile devices though, where this is an issue.

Re:Transmeta

[Lisandro]

Can we also light a candle for Cyrix?

Emigrate to *BSD

[tepples]

You can't fire the dictator.

But you can emigrate. "Of course it runs NetBSD!"

Re:Emigrate to *BSD

[drinkypoo]

But you can emigrate. "Of course it runs NetBSD!"

Except that the number of architectures supported by Debian surpassed NetBSD quite some time ago... partly because NetBSD has dropped more architectures. Some port may support them, but it's not supported.

Angel Dust (phencyclidine)

[tepples]

there are also really shitty chunks that appear to have been written by people under the influence of [...] -PCP

Indeed.

Re:DUH

[Lisandro]

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.

Re:Grumpy Old Man

[Anonymous Coward]

That's because you're too soft and your ego writes checks your intellect can't cash.

Re:He is dead right for PCs, Dead wrong for embedd

[ArylAkamov]

Though I'm sure he is talking about PCs exclusively, you're right. I think ARM is absolutely dominating in the microcontroller department.

I see very little reason to go back to 8-bit AVRs.

Different origins

[AHuxley]

One chip was designed to be very powerful and work well.
Another chip was designed to be new, better, cheaper. The option is to have other closed hardware do graphics, sound and other tasks.
Years later the different design ideas are back on the desktop again.
Do applications want one good chip that is well understood or a cheap chip that locks in a generation to other deeper hardware to get the same performance.
Nice if you have a closed OS, online shop, can alter app code standards and can command developers to accept for profit changes.

Re:He is dead right for PCs, Dead wrong for embedd

[ttucker]

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...

Got a drawer full of ARM devices and SOCs

[caseih]

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.

Re:Got a drawer full of ARM devices and SOCs

[kangsterizer]

Yeah I think that's what Linus means though.
Also why I'm using a NUC as well. Eventually gave up no the countless garbage ARM boards with proprietary boot loaders and incompatible things of all kinds. The NUC let me focus on what matters, basically, the ARM boards all get in the way.
If x86 would get as cheap as ARM, I suspect there would be no more ARM.

Re:Got a drawer full of ARM devices and SOCs

[gtall]

That wouldn't make ARM go away. Intel tells you how to construct your computing, ARM allows you to construct it yourself with their licensing schemes. Until that changes, no one who doesn't have a fairly, large uniform market is going to trust Intel.

Re:Linus should be laid off, right now.

[kangsterizer]

Anyone can fork Linux.
That said I think a lot of people agree with, and trust Linus: He's not a politician. He's a good engineer.

Re:Grumpy Old Man

[KozmoStevnNaut]

A lot of people have a hard time accepting that fact.

It's not about what you know. It's all about what you realize that you don't know.

Re:Grumpy Old Man

[AC-x]

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.

Re:He is dead right for PCs, Dead wrong for embedd

[Anonymous Coward]

"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.

Re:Grumpy Old Man

[TheRaven64]

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.

Re:Grumpy Old Man

[Big Hairy Ian]

Basically the various ARM Eco system now is pretty much the same as the personal computer Eco system back before the IBM Contemptible came along with tones of people going hey buy my proprietary box!

Re:Where is my grub menu?

[ledow]

Surely the problem is the whole architecture then?

x86 etc. is an architecture - a standard chip, a standard instruction set (even if it evolves), and a standard set of interfaces, memory locations, hardware and functions.

ARM is just a chip.

x86 has common platforms like UEFI and even BIOS, as well as standard buses and standard interfaces.

ARM doesn't. At least not enough to guarantee.

It's like saying you've released Linux for Z80. Cool. What's the Z80 plugged into because that's by no means a given in any way.

Nobody really puts x86 chips into embedded hardware without replicating the entire x86 architecture (e.g. XBox). But ARM chips can be joined in all kinds of ways and all kinds of free-for-all designs.

It's not a problem you can solve with just a boot menu and a USB.

Re: Grumpy Old Man

[Type44Q]

God DAMN; mod the hell up!

Re: Grumpy Old Man

[Type44Q]

Your point is entirely orthogonal to the matter at hand: we engineers and "techie types" are discussing Linus' thoughts on the viability of Android as a platform; what the [fucking ignorant] consumer thinks is certainly relevant to some discussions... but not this one.

Re:Grumpy Old Man

[JoeMerchant]

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.

What will likely eventually happen (hopefully) is that designers will tire of re-inventing the wheel every time a new product cycle comes around and eventually move to the more open/supported architectures, not because they're technically superior in power consumption or whatever, but because they're good enough and they're easier to develop on.

Re:Linus should be laid off, right now.

[unixisc]

Just get emacs to run on top of it, and you'll have a full OS, neatly sidestepping the controversy over Linux vs BSD vs Minix

Re:Linus should be laid off, right now.

[unixisc]

He was guillotined, not fired. Big difference!

Re:Linus should be laid off, right now.

[unixisc]

So he is the Trump of software?

Re:Transmeta

[unixisc]

Don't forget Winchip

Re:Grumpy Old Man

[luis_a_espinal]

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.

Non sequitur. What matters is not what the customers want (or know), but the costs associated with developing in a platform. Someone has to build shit, and if the platform is fragmented, well, then that adds up to the cost, doesn't?

Management Engine

[emil]

Both Intel and [most of the] ARM [community] are guilty of bundling opaque processor controls, and the i386/ARM architectures cannot be trusted as the opaque components have unrestricted access to networking, memory, and i/o.

It appears that the best "open" CPU architecture is the decade-old SPARC T2 - the full Verilog source for the CPU is provided, and there is no "management engine."

Unfortunately, no "Raspberry Pi" or otherwise reduced form-factor board is available on the market at this time. If you want to run a SPARC T2, you will likely have to purchase a used Netra server.

Re:Grumpy Old Man

[DamnOregonian]

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.

Re:He is dead right for PCs, Dead wrong for embedd

[ttucker]

There are like... 10 devices on the supported hardware list of those projects. Most of them are painfully obsolete. None of them are open hardware, and they probably run on reverse engineered firmware, and not actual clean open implementations.

Debin will run on almost any normal x86 PC from the past 20 years, and function quite adequately as a router with two NICs.

Re:He is dead right for PCs, Dead wrong for embedd

[ttucker]

And the maintainers...