23
$\begingroup$

Considering how GPUs in matter modeling was first recognized in gaming devices like PlayStation, it is also interesting to consider whether ARM64 chips, which are the type of chips in modern smart phones, will play a similarly revolutionary role in matter modeling.

Now it is no secret that ARM64 is something that should be considered seriously. For example, Apple's recent announcement that all MACs will come with the ARM64 processor, and the Microsoft Surface X Pro, which runs on ARM64 with a full Windows 10 build. Furthermore, Windows Subsystem for Linux2 (WSL2) is also compatible with ARM64.

The benefits of ARM64 are the "small form factors" which allow it to be more power efficient, smaller, thinner and lighter. Furthermore, they have instant on capability, and long standby times. These are particularly promising from a consumer standpoint but could also be beneficial for high-performance computing as well.

However, the serious drawbacks of ARM64 is the software compatibility.

Notably I found this link which lists ARM + NVIDIA HPC Software that are currently compatible:

  • CoMet
  • LAMMPS
  • NAMD
  • VMD
  • DCA++
  • Gromacs
  • LSMS

What other popular matter modeling software are compatible with ARM64 or what software are notoriously not currently compatible? (e.g. Adobe creative cloud is apparently not yet completely supported by ARM64)

Improve this question
$\endgroup$
4
  • 7
    $\begingroup$ Another reason to take ARM seriously is the recently debuted (June 2020) Japanese supercomputer Fugaku, which took spot 1 on the Top500 list. It was, however, very expensive, at least in part due to the development costs involved. I think we'll find out in the next few years if the costs can come down, energy efficiency can improve, or if the other architectures can keep their technical lead. Certainly, places like OLCF are keeping an eye on the developments (as your link shows). $\endgroup$
    – Anyon
    Aug 28, 2020 at 3:00
  • $\begingroup$ you can use ARM with openMM as well. $\endgroup$
    – B. Kelly
    Aug 28, 2020 at 4:31
  • 4
    $\begingroup$ I know that the development of the open source codes related to the MaX project (max-centre.eu) also aims for portability and performance on ARM machines. Actually ARM is a partner of this project. The codes are Quantum Espresso, Siesta, Yambo, Fleur, CP2k, Big DFT, and the AiiDA framework. I don't know the current state of each of these codes with respect to this, but if this compatibility is not yet provided it will be there soon. $\endgroup$
    – Gregor Michalicek
    Aug 28, 2020 at 7:38
  • 5
    $\begingroup$ Apple are not migrating their desktops to ARM for performance reasons. In fact their first ARM-based desktops will be less powerful than their current products. They want a common code base for phones, tablets, and desktops, and given their small and declining share of the desktop market, they probably wouldn't mind ditching it completely - except that a few fanboys in the creative industries will buy the next Apple generation simply because "it's not Windows". $\endgroup$
    – alephzero
    Aug 28, 2020 at 16:03

6 Answers 6

Reset to default
27
$\begingroup$

It depends on what chips datacenters are using. If large data centers switch over to ARM-based processors, scientific computing will follow. Since most of our software is open source (or not far from that), converting to ARM compatibility will not be too much of an issue once the demand is there.

Scientific computing is currently dominated by enterprise-grade Intel-compatible x86_64 processors. The reason for this is not because those are necessarily the best possible processors for scientific computing, but because they are available. Semiconductor manufacturing has massive economies of scale, and scientific computing is a relatively tiny market, so we end up buying whatever high performance chips are used by commercial data centers. So the real question is this: are commercial data centers going to switch over to ARM chips? Or are they going to stick to x86?

As far as that question goes, I have no idea. For now, I suspect that x86 maintains a performance edge in power-hungry data center processors, but that could change.

Update from Nov 2020: The initial reviews of the performance of Apple's new ARM-based Macs are very promising, even when they are translating binaries compiled for x86. I think this makes it much more likely that other firms were make big investments in desktop and possibly server-class ARM-based processors.

Improve this answer
$\endgroup$
7
  • 3
    $\begingroup$ Well, x86_64 has the highest bang per buck for now. Maybe that will change, who knows. $\endgroup$
    – Susi Lehtola
    Aug 28, 2020 at 7:51
  • $\begingroup$ "This is the whole point of having programming languages in the first place" I think usability is also a big reason for having higher level programming languages. $\endgroup$
    – Omroth
    Aug 28, 2020 at 13:53
  • 2
    $\begingroup$ @Omroth based on the quote, I believe this was meant to be a comment on Susi Lehtola's answer. $\endgroup$
    – Tyberius ♦
    Aug 28, 2020 at 14:59
  • 1
    $\begingroup$ 'converting to ARM compatibility will not be much of an issue' No, it quite simply won't be an issue in a vast majority of cases that are actually FOSS. It's very unusual for software these days that runs on commodity hardware to need special work to get it running on a particular CPU as long as the build environment exists for that CPU (and ARM64 is trivially covered for all major languages in that respect). $\endgroup$
    – Austin Hemmelgarn
    Aug 29, 2020 at 17:58
  • $\begingroup$ @AustinHemmelgarn it's not entirely true. Plenty of performance critical software requires on ISA-specific intrinsics to optimize some algorithms (i.e.SSE/AVX/FMA). The regular C fallback usually exists, but it usually many times (sometimes orders of magnitude) slower than the optimized one. So such software would require special work to be realistically usable on ARM. $\endgroup$
    – Dan M.
    Aug 30, 2020 at 1:10
17
$\begingroup$

I'd expect that x86_64 will remain the architecture of choice for computing throughput for quite a while, and that there might even be a way to deliberately re-enable the Spectre/Meltdown vulnerabilities because they give a nice speed boost and are irrelevant if you don't share the CPU with anyone else.

ARM shines in the datacenter because a lot of the work there is simple text processing with many conditional branches between long runs of waiting for I/O, and ARM is a lot more power-efficient there as they have a short pipeline and very little logic that remains active while the CPU is idle.

If you have a workload with fewer branches, Intel gets an edge, if you have almost no branches and the problem is massively parallel, GPUs win.

For any long-running computation, you probably want to run it for a few seconds on different architectures and compare speed and power requirements before you make a decision which one is optimal.

Improve this answer
$\endgroup$
1
  • $\begingroup$ That's quite different from what I've heard. Simon McIntosh-Smith pointed out in a presentation at SOS24 that despite being optimized for mobile, the firestorm cores in Apple's M1 are currently the fastest core designed for any market (including HPC) - period. In particular the Apple vs Intel chart on anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/4 is chilling. Finally, the current top spot on the Top500 is already occupied by an ARM64 machine. $\endgroup$
    – leopold.talirz
    May 28, 2021 at 14:51
13
$\begingroup$

Any code that does not have core parts written in machine level code (assembly) is going to be portable to arm64 straight away; you just have to recompile the program. This is the whole point of having programming languages in the first place: you need to be able to run your program on different architectures without rewriting the program from scratch, like in the early days of computing.

The main issue in portability is that there are some pitfalls in languages like C and Fortran that you have to be aware of, namely, intrinsic types / default types may have different defaults on different platforms. However, any adequate programmer can write code that cross-compiles. It's not so long ago that there was the switch from x86 to x86_64, where you already had to face similar issues with portability.

And if you go to the supercomputing world, you'll see that there's been quite a bit of heterogeneity for a long time: in addition to x86 and x86_64, you've also had other kinds of processor architectures like SPARC and Power. Since most codes are designed to run (also) on supercomputers, portability has been a key issue for a very long time.

Improve this answer
$\endgroup$
4
  • 8
    $\begingroup$ I agree, but at the same time, my experience is that scientific programming, as a field, is not populated by the most competent programmers, haha. $\endgroup$
    – taciteloquence
    Aug 28, 2020 at 7:48
  • 4
    $\begingroup$ "This is the whole point of having programming languages in the first place" I disagree. The primary reason to have programming languages is to have human readable programs. Portability is just a lucky side effect. $\endgroup$
    – SE - stop firing the good guys
    Aug 28, 2020 at 19:25
  • 1
    $\begingroup$ The bigger issues with porting from x86 to other architectures is that x86 is about the most forgiving architecture out there when it comes to things like unaligned accesses and cache coherency between threads. $\endgroup$
    – Peter Green
    Aug 29, 2020 at 1:05
  • $\begingroup$ @PeterGreen All ISAs have coherent caches between CPUs you run threads across, the difference between x86 and others is memory ordering between separate variables accessed from the same thread. See preshing.com/20120930/weak-vs-strong-memory-models and software.rajivprab.com/2018/04/29/…. (It's a somewhat widespread misunderstanding that actual cache, not just registers or store buffer, can have a stale or conflicting value for the same location. That's not true.) Non-coherent shared mem is used for message-passing, not atomic vars $\endgroup$
    – Peter Cordes
    Aug 29, 2020 at 19:41
8
$\begingroup$

The main difference between ARM64 and x86_64 architectures is their core design. The x86_64 uses NUMA when more cores are involved, whereas ARM64 has a more versatile design, and can have unified memory access. The ARM64 design is less complex than the x86_64, and for highly parallel computing, a simpler design may help the performance.

I see at least two reasons why ARM64 may be the "next big thing" for server processing.

Unified Memory Model

In practice, when working with highly parallel processing, you are likely to share data between threads/cores. A first set of threads (typically a modeling orchestrator) may e.g. prepare the various modeling parameters. Then another set of threads (typically the modelling engine) will process the actual data. Then another set of threads will join all previous computation into the output content.

Memory buffers are therefore likely to flow from one core to the other, and ARM64 simple memory design may have a very good impact. No need to deal with NUMA memory copies.

Higher Number of Cores

Thanks to its more simple design, ARM64 is likely to add more cores to the silicon, with less die consumption and lower power. I have used Intel Knight Landing (Xeon Phi) high-end CPUs, and their massively parallel process was with somewhat slow Atom cores, with a non uniform memory layout: you have on-chip fast memory, which needs to be addressed especially. I bought and read the reference book about this CPU and it needs to adapt the software. Custom software with AVX512 opcodes are needed to leverage the Intel HW platform, whereas with ARM64 the cores are running regular code.

The ARM64 design will probably make it easier to add more cores to the chip, without needing deed software change.

Don't Take My Word For It

A good read about the future of ARM64 is what AWS is offering as cloud solution:

https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd

In short: ARM64 may really be the next big thing for software using CPU...

Improve this answer
$\endgroup$
5
$\begingroup$

ARM64 may not have to be the next big thing to cause a positive change. Competition between two standards could result in extensions of either standard to improve them. We already see vendor specific extensions making a big difference with intel vs amd for example.

From what I have seen, as long as the software support is good (as others have pointed out, a lot of codes could just be recompiled against ARM), ARM will either be strong enough to become the dominant architecture or it will at least positively impact x86_64 indirectly via extensions.

Improve this answer
$\endgroup$
4
$\begingroup$

When I read your question I remembered a gitlab pages that list all the softwares ported to the arm architecture and their development progress. You can find it here: https://gitlab.com/arm-hpc/packages/-/wikis/categories/allPackages Hope this can help.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .