11 ms·

It's of course impossible not to respect Linus' opinion and first hand experience in this space, but doesn't this whole post completely ignore the 100 ton blue

by xoa 8y ago

It's of course impossible not to respect Linus' opinion and first hand experience in this space, but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones. That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. Smartphones also fit >"This isn't rocket science. This isn't some made up story. This is literally what happened" right? I mean, I can see arguing that going up into the cloud is different in some ways then going down to smartphones (although the high end ones are now going to outperform plenty of old dev machines in burst power). There are certainly differences in scaling and such. But the maturity of the tech for cross development of high level software isn't the same as it was in that era either. And if we're talking about bottom-to-top revolutions, embedded and smartphones seem to be at a lower level and much higher volume then PCs. Finally there is clearly an upcoming disruptive fusion event coming due to wearable displays. When "mobile" and "PC" gets merged, it certainly looks like ARM is in a strongly competitive position for some big players, and having more powerful stuff up the stack will matter to them as well. None of which is to say he won't be right at least in the short term, but it still is kind of odd to not even see it addressed at all, not even a handwave.

disiplus 8y ago
but with smartphones you don't have a choice. so it's different.
- deng 8y ago
  > but with smartphones you don't have a choice. so it's different. Exactly. Linus' point is that Arm has no real advantage in the server space to compensate for the problems with cross-development. That's completely different for smartphones, which is why Arm won that space.
  - pjc50 8y ago
    When Apple replace Intel with ARM in their laptops, that goes away too. (See my argument elsewhere in this thread)
    - pritambaral 8y ago
      The argument isn't "same instruction set". The argument is "same development & deployment environment", by the logic of which the Apple argument fails because not many people deploy to Apple servers.
      - comex 8y ago
        So you run a Linux VM, just as lots of Mac-using developers do today. But the instruction set of the VM has to match the instruction set of the host, unless you’re in the mood for slow emulation.
        pritambaral 8y ago
        > So you run a Linux VM, just as lots of Mac-using developers do today I hear far more make do with just homebrew. > unless you’re in the mood for slow emulation I run an embedded OS (made for a quad-core ARM Cortex-A53 board) on both Real Hardware and on my ThinkPad (via systemd-nspawn & qemu-arm). I found (and confirmed via benchmarks) the latter to be much faster than the former — across all three of compute, memory, and disk access.
    - mattnewport 8y ago
      Apple is a small percentage of the laptop market.
      - MBCook 8y ago
        But their market share with developers is much higher than in the general consumer market.
        mattnewport 8y ago
        Possibly, it does seem that way for web dev at least. There's plenty of programmers out there (the majority?) not doing web dev and never touching Macs however. In a 20 year game development career I've never had cause to use a Mac for work purposes. Perhaps the share of developers using Macs as their primary development machines exceeds their 10% market share of laptops but I doubt it's a majority.
- Tehnix 8y ago
  I’m not sure if this is what you were implying, but I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio. Take e.g. Apple’s A12, which compete with their MacBooks in performance, and assuredly draw much less power.
  - deng 8y ago
    > I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio Not anymore, but there was a time when x86 was (barely) able to compete in that area and there were some x86-based smartphones and tablets. But it was too little too late: x86 already was a niche. Developers absolute had to support ARM, but x86 was optional, so many apps were not available for x86, and that was pretty much it for those devices.
  - bryanlarsen 8y ago
    "assuredly draw much less power." The Macbook uses a 14nm 4.5W m3 with 1.5 billion transistors. The iPad uses a 7nm 12W A12X with 10 billion transistors.
  - kllrnohj 8y ago
    You haven't been paying attention. In order to go faster ARM started using more power. A lot more power. Turns out power usage was never an ARM vs. x86 thing, it was purely a "how fast do you want to go" thing. ARM started at the "very slow" end of the spectrum which made it a good fit for mobile initially since x86 didn't have anything on the "very slow" end of things. By being very slow it was very low power. But then the push to make ARM fast happened, and now ARM is every bit as power hungry as x86 at comparable performance levels. The power cost is for performance. The actual instruction set is a rounding error.
- xoa 8y ago
  >but with smartphones you don't have a choice. You don't have much choice now sure, but it's not as if there weren't any efforts at x86 smartphones (like the ZenPhone). Nor is it as if there wasn't a long run up of phones leading to the modern smartphone either. And even in this how is not directly relevant to the case of x86? I mean, we're directly doing a comparison to the RISC/MIPS/etc era yeah? Couldn't back then someone say "well but with PC you don't have a choice, so it's different"? x86 got heavy traction on the back of WinTel, then moved up to bigger iron, which didn't really fight hard in the lower end lower margin space. Does there really seem to be no deja vu with that vs ARM gaining heavy traction in iOS/Android/embedded then moving up to PCs and servers, where Intel/AMD didn't really play in the lower end lower margin space? There was a period with plenty of choice in servers, but then x86 won. And again it's not as if someone can't come up with compelling arguments, x86 has some real moats even beyond pure performance. There is enormously more legacy software for x86 for example, and the ISA for it will be under legal protection for a long time to come which complicates running it on ARM. But it's hard to say how much that matters in much of the cloud space, particularly if we're imagining 5-10 years further down the line. x86 takeover didn't happen overnight either, and the first efforts were certainly haphazard. But momentum and sheer volume matter. It just seems like something that needs to be addressed at any rate, more deeply then you have and certainly more then Linus did.
  - AstralStorm 8y ago
    Most legacy software needs an emulator anyway. X86-64 and OS libraries are not sufficiently similar. Try running a Windows 95 era application on Windows 10. You can even have problems with Windows XP era stuff. And server space in general does not do legacy without keeping everything intact. The only real issue is lack of ARM developer PCs.
    - smush 8y ago
      Windows does make a huge attempt to make stuff backwards compatible, however. I run a copy of Cardfile copied from Windows NT4 on Windows 10 just fine.
sitkack 8y ago
Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables. The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc. And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks. These truths are true for Linus, but not for the majority of devs. Even those creating native binaries, this is done through ci/cd pipelines. I have worked in multi arch envs, Windows NT 4 on mips/alpha/x86, iOS, Linux on arm. The issues are overblown.
- rkangel 8y ago
  He calls that out though "even if you're only running perl scripts". It's not the cross-compilation that's a factor, it's wanting the environment to be as similar as possible. Even if your code is Java bytecode, that's still running on a different build of the JVM, on a different build of the OS (possibly a different OS). There is opportunity for different errors to crop up. They might be rare, but they'll be surprising and costly when they happen exactly because of that.
  - MaxBarraclough 8y ago
    The question then is how successful the JVM is. I think you're underestimating it. Torvalds' attitude is certainly justified regarding plenty of other types of software though -- just building a C++ project on a different distro can be a pain. Someone else [0] points out that Java (in the right context at least) is so successful in isolating the developer from the underlying platform, that it isn't a problem if the developer isn't even permitted to know what OS/hardware their code will run on. Could they accidentally write code that depends on some quirk of the underlying platform? I think it's not that likely. Nowhere near as likely as in C/C++, where portability is a considerable uphill battle that takes skill and attention on the part of the developer. > They might be rare, but they'll be surprising and costly when they happen exactly because of that. Ok, but you can say the same for routine software updates. It's a question of degree. [0] https://news.ycombinator.com/item?id=19229224 https://news.ycombinator.com/item?id=19229224
- disiplus 8y ago
deleted 8y ago
[deleted]
flohofwoe 8y ago
Smartphones are a good argument for both views IMHO. Native development (as in native machine code executables) on Android is still a terrible experience even though they had a decade to fix it. It's much better on Apple platforms, maybe because they actually cared about developer-experience and native code is a "first class citizen" there. It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO. I wouldn't mind an ARM-based Mac though ;)
- dkarl 8y ago
  I bet Apple's experience moving from PowerPC to X86 gave them a leg up as well, and in both cases (PowerPC/X86, MacOS/iOS) they had the power to force developers to cross-develop to maintain access to their platform. Nobody is in a position to force server-side developers to switch to ARM.
  - geerlingguy 8y ago
    Don’t forget 680X0 to PowerPC.
  - WorldMaker 8y ago
    From the other perspective too, Google clearly seemed to want the flexibility to change the details of Android architecture on a "whim", seeming to settle on the Linux kernel at the last minute and expecting to support both ARM and x86 and whatever else they felt they wanted. Google's focus on the JVM/Dalvik and making Native hard in Android seems quite intentional, forcing developers to cross-develop in a different way by obfuscating as much code as possible into a virtual machine that they could 100% control abstracted from underlying architecture and even kernel.
- swiley 8y ago
  Native development sucking on android is mostly an android problem (and to some extent a Qualcomm problem since their smartphone SOCs don’t support anything else.)
scraft 8y ago
Not disagreeing, but answering the question of are all phones ARM: no, there Intel too. Source: had to add Intel build support for our Android SKUs to run on said phones. Some Unity stats from about 6 months ago indicated: ARMv7: 98.1% Intel x86: 1.7% I think a lot of the Intel stuff has been discontinued, not sure what is actively being developed outside of ARM right now.
- _underfl0w_ 8y ago
  This is strange. Maybe like a Windows phone? Where does it get those device metrics? < 2% makes me think it might just be that Androidx86 emulator project.
  - lagadu 8y ago
    I remember some android phones using intel atom cpus, IIRC made by asus.
  - robterrell 8y ago
    There really are android phones running Intel atom CPUs. Can’t recall models off the top of my head but adding x86 support was a thing we had to do.
  - jsight 8y ago
    There have been a few Intel Android phones. For example, this one: https://www.androidpolice.com/2018/03/28/possibly-last-intel-x86-powered-phone-displayed-mwc/ https://www.androidpolice.com/2018/03/28/possibly-last-intel... Tablet list: https://www.intel.com/content/www/us/en/products/devices-systems/tablets/android-tablets.html https://www.intel.com/content/www/us/en/products/devices-sys... (and there were a lot of small brands that used to make them, that I don't believe get represented in that list) Having said that, for it to reach >1%, it was more likely a combination of Intel Android tablets (which were fairly common for a while) and Chromebooks.
  - pjc50 8y ago
    I have an Asus Zenfone 2, complete with its "Intel Inside" logo. Not particularly special but when I bought it met the critera of "gorilla glass + pokemon go for below $150". Nice case too.
vesinisa 8y ago
He did address the so-called 100-ton blue whale at the end: > End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.
- justaaron 8y ago
  except that developing for ARM SBC's natively is normal these days. Even the lowly Raspberry Pi encourages you to plug-in an HDMI monitor, a USB mouse and keyboard, and boot into Raspbian, where things like Wiring-Pi further extend your cross-development reach (LOL), while you develop the code for your peripheral directly on the computer that's going to run it. It's a bit of a Matryushka doll in that I have both Propeller chip and FPGA "Hat's" for my Pi and use both propeller IDE and the Icestorm toolchain to natively cross-develop for ACTUALLY embedded devices, as the ARM device is the main computer already and not the embedded device anymore lol
seanalltogether 8y ago
> That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. I'm not sure I agree with. My coding environment is on x86, and I build on x86, but my Run/Debug cycle is on ARM. No one is really encouraged to test on the simulator even though it's available, you are almost entirely asked to test on your actual arm device and run it and see the results of your work. Linus is making the argument that people want their release builds to run in the same environment as their daily test builds, and I don't see smartphone development as an exception to that rule.
derefr 8y ago
> nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM There may be people somewhere doing Android/ChromeOS/Fuchsia development on ARM Chromebooks, following the Google model of using a mostly cloud-based toolchain together with a local IDE. There’s none of this happening inside Google itself, though, yet—but that’s just because Google issues devs Pixelbooks, and they’re x86 (for now.) But, since Pixelbooks (and ChromeOS devices in general) just run web and Android software (plus a few system-level virtualization programs like Crouton) there’s nothing stopping them from spontaneously switching any given Chromebook to ARM in a model revision. So, as soon as there’s an ARM chip worth putting in a laptop, expect the Pixelbook to have it, and therefore expect instant adoption of “native development on ARM” by a decent chunk of Googlers. It could happen Real Soon Now (hint hint.)
geezerjay 8y ago
> but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones. This is patently false. Mobile developers do test their apps on smartphones, eventhough google and apple offer VMs. You'd be hard pressed to find a mobile app software house that doesn't have a dozen or so smartphones available to their developers to test and deploy on the real thing.
- nicoburns 8y ago
  Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too. But that wouldn't stop you developing on x86 if that was what was convenient.
  - geezerjay 8y ago
    > Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too. CI/CD is already too far ahead in the pipeline to be useful. CI is only a stage where you ensure that whatever you've developed will pass the tests that you already devised, but it's already a stage where you already tested and are convinced that nothing breaks. The type of testing that Linus Torvalds referred to is much back in the pipeline. He is referring to the ability to ramp up a debugger and check if/when something is not working as expected. Developers do not want to deal with bugs that are only triggered somewhere in a CI/CD pipeline, and can't reproduce in their target machines.
- kalleboo 8y ago
  So you're saying there are already plenty of ARM devices out there to do testing on?
  - geezerjay 8y ago
    No, I'm saying that mobile development is also a clear example that developers do want to develop for platforms that they actually can test, which was the point that Linus Torvalds made.
chongli 8y ago
When "mobile" and "PC" gets merged I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices. I like to fall back on this Steve Jobs quote, employing a car/truck metaphor for computers: When we were an agrarian nation, all cars were trucks, because that's what you needed on the farm. But as vehicles started to be used in the urban centers, cars got more popular … PCs are going to be like trucks. They're still going to be around, they're still going to have a lot of value, but they're going to be used by one out of X people.
- wil421 8y ago
  I’ve always thought PCs will become business workstations. Meaning you use them for office work but everything else will be “cars” as your quote put it. Meaning internet browsing, social media, view/edit photos, and the like will be done on some mobile device. Windows is alresdy the de facto business workstation and I don’t see it going away. There’s already a whole generation or two who will likely have little to no experience with PCs.
  - pjmlp 8y ago
    Yep. I mostly use laptops since 2000 and went full laptop around 2006. With 2-1 and tablet docking stations, the desktop case will be fully covered. Surface, Samsung DeX, ...
- pjc50 8y ago
  > Mobiles are mostly communication Communication is also work, especially as you go up the management value chain. I think maybe people should refer to the thing that PCs do and mobiles don't as "typing".
  - swiley 8y ago
    It’s definitely a different kind of work. In general, smartphone software is built to discourage creative work and focus on either reading or communicating.
pjmlp 8y ago
Mainframes, have been the pioneers of using bytecode as distribution format, with the CPUs being microcoded for the specific bytecode set (e.g. Xerox PARC / Burroughs), or having JIT/AOT compilation at deployment time like IBM i and IBM z (aka OS/400, OS/300). So while Linus opinion is to be respected, mainframes, and the increase in smartphones, smartwatches and GPS devices use of bytecode distribution formats with compilation to native code at deployment time, shows another trend.
Fnoord 8y ago
Good point, from Linus' opinion it can still happen after ARM is king of the client market. Well, they're well on their way doing that with every client except for desktop being ARM, while Intel is having trouble with 7 nm.
lunchables 8y ago
I don't think that in any way contradicts his position >And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on". Sure, as soon as these merge and you have a development platform as productive as a desktop computer that allows you to natively build for ARM, then absolutely, it could displace x86. And maybe when (if) the two platforms really merge that could be a real possibility.
rst 8y ago
He's also apparently assuming that ARM-based Chromebooks will never be a useful developer environment. I wouldn't take that bet -- a lot of the newer ones will support Linux VMs out of the box well enough to support at least a half-decent development environment (via Crostini). (You can get a Pixelbook with 8GB RAM and a 512GB SSD, if you're wondering about storage space. And while Crostini still has issues with in-VM driver support for things like the Chromebook's own audio and camera, that's stuff that server software wouldn't use much anyway.) Between that and the much-rumored ARM Macs, this could turn pretty quickly...
- bryanlarsen 8y ago
  I don't think he's assuming any such thing. His argument is simply that ARM can't win until it has a reasonable dev box. He makes no speculation about if/when such a box is coming.
- tbyehl 8y ago
  Pixelbook is i5 / i7 tho. I have an Acer R13 w/ MediaTek ARM SoC. It's alright, better than the comparables with Intel N-series CPUs, but it ain't no i5.
- softshellack 8y ago
  Pixelbook is not ARM. There are lesser-powered, arm-based, crostini-enabled chromebooks. But nothing a developer would want to use yet.
NicoJuicy 8y ago
Java should work in everything and iOS only needs to support their own hardware. I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware)
NicoJuicy 8y ago
Java should work in everything and iOS only needs to support their own hardware. I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware).
robot 8y ago
power matters a lot on a phone but not that much on the server
- pjmlp 8y ago
  Sure it does, someone has to pay the heating bill.
snowwrestler 8y ago
Maybe the interesting part of the smartphone ARM story is the degree to which Apple has used custom silicon to optimize speed and power for their own specific workloads and software. Why couldn't ARM-based servers do the same thing? I understand why a generic ARM-based CPU might not win against a generic ARM-based x86 CPU at running cross-compiled code in Linux. But what if the server has a custom ARM-based chip that is a component of a toolchain that is optimized for that code, all the way down to the processor? Imagine a cloud service where instead of selecting a Linux distro for your application servers, you select cloud server images based on what type of code you're running--which, behind the scenes, are handing off (all or part of) the workload to optimized silicon. I don't have the technical chops to detail how this would work. But I think my understanding of Apple's chip success is correct: that they customize their silicon for the specific hardware and software they plan to sell. They can do that because they own the entire stack. I think if any company is going to do that in the server space, it would have to be the big cloud owners. No one else would have the scale to afford the investment and realize the gains, and control of the full stack from hardware to software to networking. And sure, enough, that is who are embarking on custom chip projects: https://www.thestreet.com/opinion/why-tech-giants-are-designing-their-own-chips-14807638 https://www.thestreet.com/opinion/why-tech-giants-are-design... So, maybe the result won't be simply "ARM beats x86," but rather "a forest of custom-purpose silicon designs collectively beat x86, and ARM helped grow the forest."
CoolGuySteve 8y ago
Ya it's kind of weird he talks about how stuffing a beige box PC in the corner was the impetus for X86 servers. But the modern day equivalent of that is either a cheap $5/month VPS, a RaspberryPi, or an OpenWRT router, any of which could compile/run ARM code. I think fundamentally, the error he's making is comparing the current market to the late 90s/early 2000s market. Back then a RISC Unix machine cost thousands of dollars. It was cost prohibitive to give one to each dev/admin. Nowadays a RISC Linux PC is $5.
- syn0byte 8y ago
  Actually, you make the best case for ARM servers of anyone else in this thread. The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range... That doesn't invalidate his point. He's just saying that is basically what needs to happen for ARM servers to start taking off. The next step is for companies to start deploying ARM workstations. That part still seems to be a good way off, MS abandoning their Windows ARM port didn't help the cause.
  - einr 8y ago
    The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range... 35 dollars will buy you an oldish x86 beige box that will absolutely flat out murder a Raspberry Pi performance-wise. Cheap, fast hardware is not a problem anymore.
  - nly 8y ago
    > MS abandoning their Windows ARM port didn't help the cause. Doesn't look like this is the case now https://blogs.windows.com/buildingapps/2018/11/15/official-support-for-windows-10-on-arm-development/ https://blogs.windows.com/buildingapps/2018/11/15/official-s...
gwbas1c 8y ago
And, most importantly: Many server-side languages don't compile to x86 / x64! They are either interpreted, or compile to bytecode! And speaking of x64... > It's why x86 won. Do you really think the world has changed radically? No, x86 is loosing to x64. And at some point another instruction set will supplant x64.
- nly 8y ago
  x86 didn't "lose" to x86-64, it just extended the 20 year compatibility story that goes all the way back to the 386. Intel tried "another instruction set" (Itanium) and nearly lost the market to AMD (AMD64)
  - wmu 8y ago
    Intel also had KNC instruction set (AVX512-like) on Xeon Phi (these CPUs available on PCI cards). They abandoned it in favour of good old x86. One of important factors was the difficulties related to tooling, especially necessity of cross-compilation.
vbezhenar 8y ago
You don’t have a choice with smartphones. So it’s not very relevant. I will write for Itanium if necessary. But given a choice, x86 wins.
syrrim 8y ago
He's shuffling smartphones in under embedded I believe. His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.
pkphilip 8y ago
Actually, Linus does not ignore the smartphone space at all. In fact he refers to it by pointing out that people are likely to ONLY use cross compiling if the deployment is to a embedded device (which a smartphone is) because the native development on the embedded device may not be possible. <quote>End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.</quote>

by xoa 8y ago

disiplus 8y ago

but with smartphones you don't have a choice. so it's different.

deng 8y ago
> but with smartphones you don't have a choice. so it's different. Exactly. Linus' point is that Arm has no real advantage in the server space to compensate for the problems with cross-development. That's completely different for smartphones, which is why Arm won that space.
- pjc50 8y ago
  When Apple replace Intel with ARM in their laptops, that goes away too. (See my argument elsewhere in this thread)
  - pritambaral 8y ago
    The argument isn't "same instruction set". The argument is "same development & deployment environment", by the logic of which the Apple argument fails because not many people deploy to Apple servers.
    - comex 8y ago
      So you run a Linux VM, just as lots of Mac-using developers do today. But the instruction set of the VM has to match the instruction set of the host, unless you’re in the mood for slow emulation.
      - pritambaral 8y ago
        > So you run a Linux VM, just as lots of Mac-using developers do today I hear far more make do with just homebrew. > unless you’re in the mood for slow emulation I run an embedded OS (made for a quad-core ARM Cortex-A53 board) on both Real Hardware and on my ThinkPad (via systemd-nspawn & qemu-arm). I found (and confirmed via benchmarks) the latter to be much faster than the former — across all three of compute, memory, and disk access.
  - mattnewport 8y ago
    Apple is a small percentage of the laptop market.
    - MBCook 8y ago
      But their market share with developers is much higher than in the general consumer market.
      - mattnewport 8y ago
        Possibly, it does seem that way for web dev at least. There's plenty of programmers out there (the majority?) not doing web dev and never touching Macs however. In a 20 year game development career I've never had cause to use a Mac for work purposes. Perhaps the share of developers using Macs as their primary development machines exceeds their 10% market share of laptops but I doubt it's a majority.
Tehnix 8y ago
I’m not sure if this is what you were implying, but I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio. Take e.g. Apple’s A12, which compete with their MacBooks in performance, and assuredly draw much less power.
- deng 8y ago
  > I don’t know of any x86 processors that can compete with the Arm processors that are in use, on power consumption to performance ratio Not anymore, but there was a time when x86 was (barely) able to compete in that area and there were some x86-based smartphones and tablets. But it was too little too late: x86 already was a niche. Developers absolute had to support ARM, but x86 was optional, so many apps were not available for x86, and that was pretty much it for those devices.
- bryanlarsen 8y ago
  "assuredly draw much less power." The Macbook uses a 14nm 4.5W m3 with 1.5 billion transistors. The iPad uses a 7nm 12W A12X with 10 billion transistors.
- kllrnohj 8y ago
  You haven't been paying attention. In order to go faster ARM started using more power. A lot more power. Turns out power usage was never an ARM vs. x86 thing, it was purely a "how fast do you want to go" thing. ARM started at the "very slow" end of the spectrum which made it a good fit for mobile initially since x86 didn't have anything on the "very slow" end of things. By being very slow it was very low power. But then the push to make ARM fast happened, and now ARM is every bit as power hungry as x86 at comparable performance levels. The power cost is for performance. The actual instruction set is a rounding error.
xoa 8y ago
>but with smartphones you don't have a choice. You don't have much choice now sure, but it's not as if there weren't any efforts at x86 smartphones (like the ZenPhone). Nor is it as if there wasn't a long run up of phones leading to the modern smartphone either. And even in this how is not directly relevant to the case of x86? I mean, we're directly doing a comparison to the RISC/MIPS/etc era yeah? Couldn't back then someone say "well but with PC you don't have a choice, so it's different"? x86 got heavy traction on the back of WinTel, then moved up to bigger iron, which didn't really fight hard in the lower end lower margin space. Does there really seem to be no deja vu with that vs ARM gaining heavy traction in iOS/Android/embedded then moving up to PCs and servers, where Intel/AMD didn't really play in the lower end lower margin space? There was a period with plenty of choice in servers, but then x86 won. And again it's not as if someone can't come up with compelling arguments, x86 has some real moats even beyond pure performance. There is enormously more legacy software for x86 for example, and the ISA for it will be under legal protection for a long time to come which complicates running it on ARM. But it's hard to say how much that matters in much of the cloud space, particularly if we're imagining 5-10 years further down the line. x86 takeover didn't happen overnight either, and the first efforts were certainly haphazard. But momentum and sheer volume matter. It just seems like something that needs to be addressed at any rate, more deeply then you have and certainly more then Linus did.
- AstralStorm 8y ago
  Most legacy software needs an emulator anyway. X86-64 and OS libraries are not sufficiently similar. Try running a Windows 95 era application on Windows 10. You can even have problems with Windows XP era stuff. And server space in general does not do legacy without keeping everything intact. The only real issue is lack of ARM developer PCs.
  - smush 8y ago
    Windows does make a huge attempt to make stuff backwards compatible, however. I run a copy of Cardfile copied from Windows NT4 on Windows 10 just fine.

sitkack 8y ago

Linus is mostly wrong except for HPC. Very few dev pipelines for folks result in native executables. The vast majority of code is delivered as either source (python, ruby, etc) or bytcode, JVM, Scalia, etc. And the Xeon class machines folks deploy to in data center envs is a world apart from their MacBooks. These truths are true for Linus, but not for the majority of devs. Even those creating native binaries, this is done through ci/cd pipelines. I have worked in multi arch envs, Windows NT 4 on mips/alpha/x86, iOS, Linux on arm. The issues are overblown.

rkangel 8y ago
He calls that out though "even if you're only running perl scripts". It's not the cross-compilation that's a factor, it's wanting the environment to be as similar as possible. Even if your code is Java bytecode, that's still running on a different build of the JVM, on a different build of the OS (possibly a different OS). There is opportunity for different errors to crop up. They might be rare, but they'll be surprising and costly when they happen exactly because of that.
- MaxBarraclough 8y ago
  The question then is how successful the JVM is. I think you're underestimating it. Torvalds' attitude is certainly justified regarding plenty of other types of software though -- just building a C++ project on a different distro can be a pain. Someone else [0] points out that Java (in the right context at least) is so successful in isolating the developer from the underlying platform, that it isn't a problem if the developer isn't even permitted to know what OS/hardware their code will run on. Could they accidentally write code that depends on some quirk of the underlying platform? I think it's not that likely. Nowhere near as likely as in C/C++, where portability is a considerable uphill battle that takes skill and attention on the part of the developer. > They might be rare, but they'll be surprising and costly when they happen exactly because of that. Ok, but you can say the same for routine software updates. It's a question of degree. [0] https://news.ycombinator.com/item?id=19229224 https://news.ycombinator.com/item?id=19229224
disiplus 8y ago

deleted 8y ago

[deleted]

flohofwoe 8y ago

Smartphones are a good argument for both views IMHO. Native development (as in native machine code executables) on Android is still a terrible experience even though they had a decade to fix it. It's much better on Apple platforms, maybe because they actually cared about developer-experience and native code is a "first class citizen" there. It goes beyond the different instruction set of course and most of the time this is indeed mostly irrelevant (unless you've arrived at processor-specific optimizations), but the "develop on the same platform you are running on" still has the least painful workflow IMHO. I wouldn't mind an ARM-based Mac though ;)

dkarl 8y ago
I bet Apple's experience moving from PowerPC to X86 gave them a leg up as well, and in both cases (PowerPC/X86, MacOS/iOS) they had the power to force developers to cross-develop to maintain access to their platform. Nobody is in a position to force server-side developers to switch to ARM.
- geerlingguy 8y ago
  Don’t forget 680X0 to PowerPC.
- WorldMaker 8y ago
  From the other perspective too, Google clearly seemed to want the flexibility to change the details of Android architecture on a "whim", seeming to settle on the Linux kernel at the last minute and expecting to support both ARM and x86 and whatever else they felt they wanted. Google's focus on the JVM/Dalvik and making Native hard in Android seems quite intentional, forcing developers to cross-develop in a different way by obfuscating as much code as possible into a virtual machine that they could 100% control abstracted from underlying architecture and even kernel.
swiley 8y ago
Native development sucking on android is mostly an android problem (and to some extent a Qualcomm problem since their smartphone SOCs don’t support anything else.)

scraft 8y ago

Not disagreeing, but answering the question of are all phones ARM: no, there Intel too. Source: had to add Intel build support for our Android SKUs to run on said phones. Some Unity stats from about 6 months ago indicated: ARMv7: 98.1% Intel x86: 1.7% I think a lot of the Intel stuff has been discontinued, not sure what is actively being developed outside of ARM right now.

_underfl0w_ 8y ago
This is strange. Maybe like a Windows phone? Where does it get those device metrics? < 2% makes me think it might just be that Androidx86 emulator project.
- lagadu 8y ago
  I remember some android phones using intel atom cpus, IIRC made by asus.
- robterrell 8y ago
  There really are android phones running Intel atom CPUs. Can’t recall models off the top of my head but adding x86 support was a thing we had to do.
- jsight 8y ago
  There have been a few Intel Android phones. For example, this one: https://www.androidpolice.com/2018/03/28/possibly-last-intel-x86-powered-phone-displayed-mwc/ https://www.androidpolice.com/2018/03/28/possibly-last-intel... Tablet list: https://www.intel.com/content/www/us/en/products/devices-systems/tablets/android-tablets.html https://www.intel.com/content/www/us/en/products/devices-sys... (and there were a lot of small brands that used to make them, that I don't believe get represented in that list) Having said that, for it to reach >1%, it was more likely a combination of Intel Android tablets (which were fairly common for a while) and Chromebooks.
- pjc50 8y ago
  I have an Asus Zenfone 2, complete with its "Intel Inside" logo. Not particularly special but when I bought it met the critera of "gorilla glass + pokemon go for below $150". Nice case too.

vesinisa 8y ago

He did address the so-called 100-ton blue whale at the end: > End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.

justaaron 8y ago
except that developing for ARM SBC's natively is normal these days. Even the lowly Raspberry Pi encourages you to plug-in an HDMI monitor, a USB mouse and keyboard, and boot into Raspbian, where things like Wiring-Pi further extend your cross-development reach (LOL), while you develop the code for your peripheral directly on the computer that's going to run it. It's a bit of a Matryushka doll in that I have both Propeller chip and FPGA "Hat's" for my Pi and use both propeller IDE and the Icestorm toolchain to natively cross-develop for ACTUALLY embedded devices, as the ARM device is the main computer already and not the embedded device anymore lol

seanalltogether 8y ago

> That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. I'm not sure I agree with. My coding environment is on x86, and I build on x86, but my Run/Debug cycle is on ARM. No one is really encouraged to test on the simulator even though it's available, you are almost entirely asked to test on your actual arm device and run it and see the results of your work. Linus is making the argument that people want their release builds to run in the same environment as their daily test builds, and I don't see smartphone development as an exception to that rule.

derefr 8y ago

> nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM There may be people somewhere doing Android/ChromeOS/Fuchsia development on ARM Chromebooks, following the Google model of using a mostly cloud-based toolchain together with a local IDE. There’s none of this happening inside Google itself, though, yet—but that’s just because Google issues devs Pixelbooks, and they’re x86 (for now.) But, since Pixelbooks (and ChromeOS devices in general) just run web and Android software (plus a few system-level virtualization programs like Crouton) there’s nothing stopping them from spontaneously switching any given Chromebook to ARM in a model revision. So, as soon as there’s an ARM chip worth putting in a laptop, expect the Pixelbook to have it, and therefore expect instant adoption of “native development on ARM” by a decent chunk of Googlers. It could happen Real Soon Now (hint hint.)

geezerjay 8y ago

> but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones. This is patently false. Mobile developers do test their apps on smartphones, eventhough google and apple offer VMs. You'd be hard pressed to find a mobile app software house that doesn't have a dozen or so smartphones available to their developers to test and deploy on the real thing.

nicoburns 8y ago
Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too. But that wouldn't stop you developing on x86 if that was what was convenient.
- geezerjay 8y ago
  > Surely this would be the same for server software: If prod was running on ARM, then you'd probably have your CI server running ARM too. CI/CD is already too far ahead in the pipeline to be useful. CI is only a stage where you ensure that whatever you've developed will pass the tests that you already devised, but it's already a stage where you already tested and are convinced that nothing breaks. The type of testing that Linus Torvalds referred to is much back in the pipeline. He is referring to the ability to ramp up a debugger and check if/when something is not working as expected. Developers do not want to deal with bugs that are only triggered somewhere in a CI/CD pipeline, and can't reproduce in their target machines.
kalleboo 8y ago
So you're saying there are already plenty of ARM devices out there to do testing on?
- geezerjay 8y ago
  No, I'm saying that mobile development is also a clear example that developers do want to develop for platforms that they actually can test, which was the point that Linus Torvalds made.

chongli 8y ago

When "mobile" and "PC" gets merged I don't see this happening. PCs are tools for getting real work done. Mobiles are mostly communication and entertainment devices. I like to fall back on this Steve Jobs quote, employing a car/truck metaphor for computers: When we were an agrarian nation, all cars were trucks, because that's what you needed on the farm. But as vehicles started to be used in the urban centers, cars got more popular … PCs are going to be like trucks. They're still going to be around, they're still going to have a lot of value, but they're going to be used by one out of X people.

wil421 8y ago
I’ve always thought PCs will become business workstations. Meaning you use them for office work but everything else will be “cars” as your quote put it. Meaning internet browsing, social media, view/edit photos, and the like will be done on some mobile device. Windows is alresdy the de facto business workstation and I don’t see it going away. There’s already a whole generation or two who will likely have little to no experience with PCs.
- pjmlp 8y ago
  Yep. I mostly use laptops since 2000 and went full laptop around 2006. With 2-1 and tablet docking stations, the desktop case will be fully covered. Surface, Samsung DeX, ...
pjc50 8y ago
> Mobiles are mostly communication Communication is also work, especially as you go up the management value chain. I think maybe people should refer to the thing that PCs do and mobiles don't as "typing".
- swiley 8y ago
  It’s definitely a different kind of work. In general, smartphone software is built to discourage creative work and focus on either reading or communicating.

pjmlp 8y ago

Mainframes, have been the pioneers of using bytecode as distribution format, with the CPUs being microcoded for the specific bytecode set (e.g. Xerox PARC / Burroughs), or having JIT/AOT compilation at deployment time like IBM i and IBM z (aka OS/400, OS/300). So while Linus opinion is to be respected, mainframes, and the increase in smartphones, smartwatches and GPS devices use of bytecode distribution formats with compilation to native code at deployment time, shows another trend.

Fnoord 8y ago

Good point, from Linus' opinion it can still happen after ARM is king of the client market. Well, they're well on their way doing that with every client except for desktop being ARM, while Intel is having trouble with 7 nm.

lunchables 8y ago

I don't think that in any way contradicts his position >And the only way that changes is if you end up saying "look, you can deploy more cheaply on an ARM box, and here's the development box you can do your work on". Sure, as soon as these merge and you have a development platform as productive as a desktop computer that allows you to natively build for ARM, then absolutely, it could displace x86. And maybe when (if) the two platforms really merge that could be a real possibility.

rst 8y ago

He's also apparently assuming that ARM-based Chromebooks will never be a useful developer environment. I wouldn't take that bet -- a lot of the newer ones will support Linux VMs out of the box well enough to support at least a half-decent development environment (via Crostini). (You can get a Pixelbook with 8GB RAM and a 512GB SSD, if you're wondering about storage space. And while Crostini still has issues with in-VM driver support for things like the Chromebook's own audio and camera, that's stuff that server software wouldn't use much anyway.) Between that and the much-rumored ARM Macs, this could turn pretty quickly...

bryanlarsen 8y ago
I don't think he's assuming any such thing. His argument is simply that ARM can't win until it has a reasonable dev box. He makes no speculation about if/when such a box is coming.
tbyehl 8y ago
Pixelbook is i5 / i7 tho. I have an Acer R13 w/ MediaTek ARM SoC. It's alright, better than the comparables with Intel N-series CPUs, but it ain't no i5.
softshellack 8y ago
Pixelbook is not ARM. There are lesser-powered, arm-based, crostini-enabled chromebooks. But nothing a developer would want to use yet.

NicoJuicy 8y ago

Java should work in everything and iOS only needs to support their own hardware. I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware)

NicoJuicy 8y ago

Java should work in everything and iOS only needs to support their own hardware. I don't think ARM can rule with Java ( that already supports it) and Swift/c ( limited hardware).

robot 8y ago

power matters a lot on a phone but not that much on the server

pjmlp 8y ago
Sure it does, someone has to pay the heating bill.

snowwrestler 8y ago

Maybe the interesting part of the smartphone ARM story is the degree to which Apple has used custom silicon to optimize speed and power for their own specific workloads and software. Why couldn't ARM-based servers do the same thing? I understand why a generic ARM-based CPU might not win against a generic ARM-based x86 CPU at running cross-compiled code in Linux. But what if the server has a custom ARM-based chip that is a component of a toolchain that is optimized for that code, all the way down to the processor? Imagine a cloud service where instead of selecting a Linux distro for your application servers, you select cloud server images based on what type of code you're running--which, behind the scenes, are handing off (all or part of) the workload to optimized silicon. I don't have the technical chops to detail how this would work. But I think my understanding of Apple's chip success is correct: that they customize their silicon for the specific hardware and software they plan to sell. They can do that because they own the entire stack. I think if any company is going to do that in the server space, it would have to be the big cloud owners. No one else would have the scale to afford the investment and realize the gains, and control of the full stack from hardware to software to networking. And sure, enough, that is who are embarking on custom chip projects: https://www.thestreet.com/opinion/why-tech-giants-are-designing-their-own-chips-14807638 https://www.thestreet.com/opinion/why-tech-giants-are-design... So, maybe the result won't be simply "ARM beats x86," but rather "a forest of custom-purpose silicon designs collectively beat x86, and ARM helped grow the forest."

CoolGuySteve 8y ago

Ya it's kind of weird he talks about how stuffing a beige box PC in the corner was the impetus for X86 servers. But the modern day equivalent of that is either a cheap $5/month VPS, a RaspberryPi, or an OpenWRT router, any of which could compile/run ARM code. I think fundamentally, the error he's making is comparing the current market to the late 90s/early 2000s market. Back then a RISC Unix machine cost thousands of dollars. It was cost prohibitive to give one to each dev/admin. Nowadays a RISC Linux PC is $5.

syn0byte 8y ago
Actually, you make the best case for ARM servers of anyone else in this thread. The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range... That doesn't invalidate his point. He's just saying that is basically what needs to happen for ARM servers to start taking off. The next step is for companies to start deploying ARM workstations. That part still seems to be a good way off, MS abandoning their Windows ARM port didn't help the cause.
- einr 8y ago
  The starving college kid in a Helsinki dorm working on his EE degree can't afford 600-1000 dollars for another Laptop/Desktop to experiment with. A 35 dollar ARM SBC and a monitor that doubles as his TV is right in his price range... 35 dollars will buy you an oldish x86 beige box that will absolutely flat out murder a Raspberry Pi performance-wise. Cheap, fast hardware is not a problem anymore.
- nly 8y ago
  > MS abandoning their Windows ARM port didn't help the cause. Doesn't look like this is the case now https://blogs.windows.com/buildingapps/2018/11/15/official-support-for-windows-10-on-arm-development/ https://blogs.windows.com/buildingapps/2018/11/15/official-s...

gwbas1c 8y ago

And, most importantly: Many server-side languages don't compile to x86 / x64! They are either interpreted, or compile to bytecode! And speaking of x64... > It's why x86 won. Do you really think the world has changed radically? No, x86 is loosing to x64. And at some point another instruction set will supplant x64.

nly 8y ago
x86 didn't "lose" to x86-64, it just extended the 20 year compatibility story that goes all the way back to the 386. Intel tried "another instruction set" (Itanium) and nearly lost the market to AMD (AMD64)
- wmu 8y ago
  Intel also had KNC instruction set (AVX512-like) on Xeon Phi (these CPUs available on PCI cards). They abandoned it in favour of good old x86. One of important factors was the difficulties related to tooling, especially necessity of cross-compilation.

vbezhenar 8y ago

You don’t have a choice with smartphones. So it’s not very relevant. I will write for Itanium if necessary. But given a choice, x86 wins.

syrrim 8y ago

He's shuffling smartphones in under embedded I believe. His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.

pkphilip 8y ago

Actually, Linus does not ignore the smartphone space at all. In fact he refers to it by pointing out that people are likely to ONLY use cross compiling if the deployment is to a embedded device (which a smartphone is) because the native development on the embedded device may not be possible. <quote>End result: cross-development is mainly done for platforms that are so weak as to make it pointless to develop on them. Nobody does native development in the embedded space. But whenever the target is powerful enough to support native development, there's a huge pressure to do it that way, because the cross-development model is so relatively painful.</quote>