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

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 pessimistically say there's a 1% failure rate, I'll be stuck doing that forever! Nah, I'll just go back to my comfy x86 instance, life's short and there's much code to write :)

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. If the developers don't run the same platform, it's not going to happen, no matter how great the cross platform story is in theory. Even if it's as simple as checking a box during upload that "yes, this game can run on X86", a huge chunk of the developers will simply never do that.

> It's friendly but it's not space efficient.

User studies from the dawn of the GUI continue to harp that user efficiency is inversely correlated to space efficiency. It doesn't matter if an application can show a million details to the individual pixel level if the user can't process a million details or even recognize individual pixels.

> Touch screens don't have right click, so you can't get context menus.

You don't need "right click" for context menus.

Touch applications have supported long-press for years as context menu. Not to mention that macOS has always been that way traditionally because Apple never liked two+ button mice.

Then there's touch applications that have explored more interesting variations of context menus such as slide gestures and something of a return to relevance of Pie Menus (which it is dumb that those never took dominance in the mouse world and probably proof again that mice are too accurate for their own good when it comes to real efficiency over easy inefficiency).

> I'd much rather have a true multiwindow, multitasking operating system

Those have never been mutually exclusive from touch friendly. It's not touch friendliness that keeps touch/mobile OSes from being "true multiwindow/multitasking", it's other factors in play such as hardware limitations and the fact that tiling window managers and "one thing at a time" are better user experiences more often than not, and iOS if anything in particular wants to be an "easy user experience" more than an OS.

(I use touch all the time on Windows in true multiwindow/multitasking scenarios. It absolutely isn't mutually exclusive.)

I have to agree with LT, but not on technical issues. This is a question of business issues. You can look at many facets of different cases, but they are all distilled into "Path Dependant Behavior". Sometimes it is called "Baby Duckling Syndrome", but it is that the leader in a market segment is much better equipped to respond, and outpace competitors.

> Isn't turbo boost an issue when comparing/profiling?

No. In HPC world, profiling is not always done over "timing". Instead, tools like perf are used to see CPU saturation, instruction hit/retire/miss ratios. Same for cache hits and misses. For more detailed analysis, tools like Intel Parallel Studio or its open source equivalents are used. Timings are also used, but for scaling and "feasibility" tests to test whether the runtime is acceptable for that kind of job.

OTOH, In a healthy system room environment, server's cooling system and system room temperature should keep the server's temperature stable. This means your timings shouldn't deviate too much. If lots of cores are idle, you can expect a lot of turbo boost. For higher core utilization, you should expect no turbo boost, but no throttling. If timings start to deviate too much, Intel's powertop can help.

> my experience with video generation/encoding run of about 30 sec was that my macbook outperformed the server xeons...

If the CPUs are from the same family, and speed are comparable, your servers may have turbo boost disabled.

> otherwise a testrun of 30 seconds would suddenly jump up to over a minute.

This seems like thermal throttling due to overheating.

> the xeons though always took about 40 seconds.. but were consistent in that runtime (and were able to do more of the same runs in parallel without loosing performance)

Servers' have many options for fine tuning CPU frequency response and limits. The servers may have turbo boost disabled, or if you saturate all the cores, turbo boost is also disabled due to in-package thermal budget.

If you have any more questions, I'd do my best to answer.

Linus is right that ARM won't win "as long as everybody does cross-development." And that's why ARM will win.

Apple will ship MacBooks on ARM in 2020, which will have comparable performance with superior battery life. Windows-based laptop vendors will switch to ARM to catch up; the desktop market will follow the laptop market, as it already does.

ARM's performance-per-watt advantages already make it a compelling cross-compile target today; when everybody's developing on ARM, it will be a no-brainer.