As mentioned in TFA... every time I've looked at ARM server offerings, it was always much more expensive than x86 options, and most of the time far less compute power.
Linus Torvalds on Why ARM Won't Win the Server Space
521–530 of 545 posts
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#522Earlier quoted context omitted.
It will most likely kill apple laptops as a developer platform. Unless you are deeply disconnected from the hardware, CPU architecture does matter. Most developers using macbooks I know have VMs for either Windows or Linux works. It might be conceivable to use the ARM port of , or the ARM version of Windows 10. But it would also require a good desktop virtualization solution for ARM. If Apple release its own solution…
I think kill is too strong. Certainly some developers will need to be on an Intel chip, but not all. How many developers use their laptops as a dumb SSH terminal? While some C extensions to scripting languages will need some love, the majority of major interpreted or VM driven languages work already. My feeling is it will be net zero as far as ARM servers are concerned until the hardware is made and is viable. Perhap…
Sorry, but in Windows, Mac and Linux x86 docker is a huge part of my workflow... I'm having enough trouble guiding people out of windows only as it stands, ARM is too big a pill to swallow in teh near future. There's still enough bad parts in scripting environments at the edges (I'm a heavy node user, scss and sqlite being a big two touch points).
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#523Earlier quoted context omitted.
Developers don't develop on Surface books, and Macbooks are in low percentages. The majority of people in the world writing code are using x86 PCs and Microsoft and Apple aren't about to change that with any *Book. Linus' premise that everyone will continue to use x86 for development is because they will. There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and…
> Macbooks are in low percentages For some reason Macbooks seem disproportionately represented amongst web developers. All the agencies I know in Sydney and Melbourne are full of macbooks. > There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and in racks with ARM alternatives which will offer them lower performance than their already slightly aged hardware at…
This is true, but a huge part of that is VMs with linux or windows, and for me x86 docker workflows that go to x86 servers. It'll be years for any real transition imho.
It took 4 years of concerted effort to get most node things working right in windows.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#524Earlier quoted context omitted.
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…
--- I accidentally deleted this comment, so, I've re-written it. --- Disclaimer: I'm a HPC system administrator in a relatively big academic supercomputer center. I also develop scientific applications to run on these clusters. > 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, J…
I am not sure we are disagreeing on much, but the 4 core i7 in my dev MacBook is a whole lot different than the dual socket, 56 core machines we run on.
Optimizations that need to happen, don’t happen locally, they get tuned on a node in the cluster. Look at all the work Goto has done on Goto Blas.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#525> By: Linus Torvalds February 21, _2019_
> This is true even if what you mostly do is something ostensibly cross-platform like just run perl scripts or whatever.
Please tell me this is irony.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#526I disagree with Linus here, in large part because modern system architectures are so distributed. There are so many parts of modern deployments which are not developed in-house anymore. Databases, organizational productivity software, monitoring systems... the list goes on. So let's say the developers of PostgreSQL or Prometheus or JIRA or Mattermost or any one of numerous others were to come to their audience and sa…
> Developers are using cheap Raspberry PIs as local desktop development platforms. IMHO this is still a problem, it is easy to get RPi-style devices but for development a more powerful device would be great, however this is much harder to get. Sure, cross-compilation works but is usually tedious to setup and work with. I've had the chance to work on one of these powerful ARM servers for some time. I was connected via…
BTW: Fedora switched back to 4k pages a while back. The 64k page thing is one of those areas where ARM should have an advantage over x86, but so much software fails to work with 64k pages that its not yet worth it.
So, give fedora a try on aarch64 again, with F29, its almost at 100% package parity with x86 once you remove packages specific to x86. ARM/linaro/etc have been hard at work for the past few years getting the long tail of compilers/libraries working enough that all the higher level stuff has a change to generally work.
The perf thing is a problem because there are a lot of microarch specific counters, but frequently they don't get published by any particular cpu vendor. So, your left in the dark about them. The best solution at the moment is call your vendor and demand a more complete list.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#527Earlier quoted context omitted.
> if ARM development machines become mainstream by way of Apple, then the calculation changes completely. That's the biggest chance for ARM: having the notebooks/desktops that are good or even better for most potential users.
Chance for ARM? How can you say that with a straight face when ARM is the undisputed winner in the greatest market of all.
The chance for ARM to really get to be used for all purposes (desktop, server) in the context of the OP. The context of the discussion matters.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#528Earlier quoted context omitted.
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 would expect them to pursue a dual processor strategy first. The bulk of the OS can run on ARM and power apps can remain on x86.
Sounds about right. They actually already have this setup, the T2 chip in recent macs contains an arm processor which handles some tasks like disk encryption. It could be possible that future OSX versions will leverage that processor for more general purposes.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#529Earlier quoted context omitted.
--- I accidentally deleted this comment, so, I've re-written it. --- Disclaimer: I'm a HPC system administrator in a relatively big academic supercomputer center. I also develop scientific applications to run on these clusters. > 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, J…
I am not sure we are disagreeing on much, but the 4 core i7 in my dev MacBook is a whole lot different than the dual socket, 56 core machines we run on. Optimizations that need to happen, don’t happen locally, they get tuned on a node in the cluster. Look at all the work Goto has done on Goto Blas.
We agree on HPC, however I also agree with Linus about non-HPC loads. Software and developers are always more expensive than hardware, but scaling beyond a certain point in hardware (number of servers, or the GPUs you need) drives the hardware and maintenance cost up, hence the difference becomes negligible, or the maintenance becomes unsustainable. This is why everyone is trying to run everything faster with the same power budget. At the end, after a certain point, everyone wants to run native code at the backend to reap the power of the hardware they help. This is why I think Linus is right about ARM. That's not I'm not supporting them, but they need to be able to run some desktops or "daily driver" computers which support development. Java's motto was write once, run everywhere, which was not enough to stop migration to x86. Behavioral uniformity is peace of mind, and is a very big peace TBH.
What I wanted to say is, unless the code you are writing consists of interdependent threads and the minimum thread count is higher than your laptop, you can do 99% of the optimization on your laptop. On the other hand, if the job is single threaded or the threads are independent, the performance you obtain in your laptop per core is very similar to the performance you get on the server.
For BLAS stuff I use Eigen, hence I don't have experience with xBLAS and libFLAME, sorry.
From a hardware perspective, a laptop and a server is not that different. Just some different controllers and resiliency features.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#530Earlier quoted context omitted.
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…
> The good news is that Clang can cross-compile fairly easily. Much better than gcc. How so? The complications in cross compiling come from setting up all the system libraries, not the compiler and linker.
by default it supports a variety of targets, you don't need to set it up.
setting up the system libraries is relatively easy, make a copy of the target you're building for, assuming it has a setup for compilation, and use --sysroot=/path/to/target.