Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds on Why ARM Won't Win the Server Space

realworldtech.com

Post reply on HN
Print view View original

351–360 of 545 posts

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#351

Post by asveikau »

mehrdadn wrote: post #278
kstrauser wrote: post #268

Earlier quoted context omitted.

The NetBSD people vehemently disagree. By ensuring your software works on various architectures, you expose subtle bugs in the ones you actually care about. Lots of 32-bit x86 code was improved during the migration to 64-bit, not because the move created new bugs, as because existing ones (i.e. code that relied on undefined behavior) couldn't get away with it anymore.

I wouldn't call their bugs. If the binaries worked correctly on x86 due to compiler specific guarantees then the code wasn't buggy. It just wasn't written for a generic C or C++ compiler.

In my experience with porting stuff, sometimes the bugs exposed by ports are not along the lines of "always works on x86, always fails on ARM". In a lot of cases it fails on both, with different frequencies, but maybe the assumptions are broken sooner or more often on another platform.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#352

Post by anfilt »

steveklabnik wrote: post #312
anfilt wrote: post #302

Earlier quoted context omitted.

This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. A few will also be the same across compilers if your compiling for the same architecture. However, I do agree that cross compiling is good for finding bugs like this. And really if we are letting the compiler or architecture define undefined behavior, I find it better to break…

> This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. That is implementation defined, not undefined, behavior.

Undefined as per the spec.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#353

Post by jzl »

bunnycorn wrote: post #290

This will be Linus "640kb ought to be enough for everyone", except that Gates didn't actually said that, and Linus actually wrote this. Someone please tell him what LLVM bytecode is, probably he doesn't know because he uses GCC, Apple showed recently how that can leveredged in scale, with Apple Watch's architecture change overnight. ARM and RISCV are here.

LLVM bytecode is very cool, and arguably evidence that a more generic system could be successful, but it is not considered to be instruction-set agnostic. Yes, it allowed Apple to tweak the cpu in new Apple Watches without requiring updated app submissions, which is great. But it would not support a transition from, for example, x86 to ARM. I've seen this topic discussed multiple times, best summary I could find is from a quora post:

Everyone's first thought (including the other two answerers here!) was that this would allow Apple to change processors entirely: if they wanted to make an Intel iPhone, for instance, they could just tell the App Store to start converting apps' bitcode to Intel machine code instead of ARM machine code for the new phones, and every app would instantly be "updated" for the new processor.

But in practice, this doesn't seem likely. Even with LLVM's unusually clean separation between frontend and backend, the frontend actually does know certain things about the processor it's targeting (mainly details about its memory layout, or special processor features it can use to make certain code faster). These things get baked into the bitcode, and in practice ensure you can't really mix-and-match frontends and backends as freely as you would like. So suddenly switching processors entirely probably isn't in the cards.

What's more likely is that it will allow Apple to make smaller improvements to their processors and then roll them out to existing apps. ...

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#355

Post by wtracy »

supermatt wrote: post #316
admax88q wrote: post #310

Earlier quoted context omitted.

Well nobody uses NetBSD so... Sure portability increases code quality, but at what cost to time to market which seems to be the primary concern for most developers these days?

NetBSD (and NetBSD code) is used pretty much everywhere. The internet pretty much runs on it.

I couldn't name a major corporation that uses NetBSD on their servers or routers. (Yahoo used to use FreeBSD servers, but even they migrated to Linux.)

Is there a major router vendor or something else that uses NetBSD in a big way?

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#356

Post by anfilt »

steveklabnik wrote: post #312
anfilt wrote: post #302

Earlier quoted context omitted.

This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. A few will also be the same across compilers if your compiling for the same architecture. However, I do agree that cross compiling is good for finding bugs like this. And really if we are letting the compiler or architecture define undefined behavior, I find it better to break…

> This honestly depends on what undefined behavior we are talking about. Sometimes it will be guaranteed to behave a certain way on a compiler. That is implementation defined, not undefined, behavior.

Undefined as per the spec. Does not mean it does not have a certain behavior on a given implementation.

The spec also does mention implemtation defined behavior. However, undefined things still need to be handled.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#357

Post by ekiwi »

tlb wrote: post #301
Androider wrote: post #252

Earlier quoted context omitted.

Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. Do I really want to be debugging why node-gyp fails to compile scrypt on the ARM distro on the new Amazon A1 ARM instance (which it did in my case)? And if I solve that, what about the other 2451 dependencies? Let's pessimistic…

I'm suffering through this now -- I have a custom C++ Node exception that needs to run on both x64 and ARM. The ARM cpu is onboard a mobile robot, where I care about power draw. The good news is that Clang can cross-compile fairly easily. Much better than gcc. The bad news is that there are a surprising number of missing libraries on Ubuntu/ARM64. For example, Eigen3. And although the code is fairly compatible, there…

Have you tried compiling with address sanitizer? https://clang.llvm.org/docs/AddressSanitizer.html

Unfortunately C++ code is only portable if it is free from undefined behavior. Fortunately there are many tools now to debug these kinds of errors: https://blog.regehr.org/archives/1520

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#358

Post by wtracy »

mehrdadn wrote: post #278
kstrauser wrote: post #268

Earlier quoted context omitted.

The NetBSD people vehemently disagree. By ensuring your software works on various architectures, you expose subtle bugs in the ones you actually care about. Lots of 32-bit x86 code was improved during the migration to 64-bit, not because the move created new bugs, as because existing ones (i.e. code that relied on undefined behavior) couldn't get away with it anymore.

I wouldn't call their bugs. If the binaries worked correctly on x86 due to compiler specific guarantees then the code wasn't buggy. It just wasn't written for a generic C or C++ compiler.

There's a world of difference between working correctly on x86 and appearing to work correctly on x86. Sometimes the difference has serious security implications.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#359

Post by lrem »

mullingitover wrote: post #341
Androider wrote: post #257

Earlier quoted context omitted.

On a related note, if Apple does switch to ARM chips for their laptops, that will make mainstream ARM server-side development more viable than any cross-platform story ever can. Or kill the Mac desktop. One or the other :)

I consider myself a pretty average Mac user, and I've already been turned off by the last couple rounds of Macs that Apple has shipped. Messing up the one remaining upside, x86 compatibility, would be be the straw that broke the camel's back. They still only have single digit market share in desktop computing, this could be the death blow for their platform.

I'm on a 2013 retina, because nothing in the meantime offered incentive to switch. I'm wondering how a switch to ARM would affect that.

Re: Linus Torvalds on Why ARM Won't Win the Server Space

#360

Post by pjmlp »

admax88q wrote: post #309
pcwalton wrote: post #307

Earlier quoted context omitted.

> I think I'll side with Linus on this one. I saw first-hand how non-existent the x86 Android market was, despite Intel pouring megabucks into the project. Doesn't that refute Linus' argument, not strengthen it? Almost all Android developers develop on x86. Intel thought, as Linus apparently does, that this would drive adoption of x86 on phones. It didn't. Intel even got competitive in power efficiency and it wasn't…

Phones are different than servers though. The primary customer of a phone is Joe Somebody who doesn't know or care about architectures, only battery life and cost. Well ARM wins there. The primary customer of servers is developers who care less about cost and more about time to market.

When I deploy to PaaS or servless cloud instances, I couldn't care less if they are running on OS xyz, hypervisor or bare metal.
Post reply on HN