Works on ARM news is written and edited by Ed Vielmetti at Packet. It comes out weekly on Fridays on Twitter's @worksonarm account and via Github and Gitbook. Subscription details are at the bottom of this issue.
- Go 1.9 RC 1
- Docker 17.07.0-rc1
- Naming things
- ARM64 support in the Guix package manager
The Go programming language has announced availability of Go 1.9 RC 1 to the community. This release reflects the stability of Go 1.9, and as part of the test process Google puts Go release candidates into production.
Like the earlier beta releases of Go, this version comes with ARM64 binaries, which are available for you to test. There are a small number of bugs still remaining, with at this writing 4 open and 609 closed on the Go 1.9 milestone.
Benchmarks of any complex system will depend heavily on your workload. One benchmark report provided on a single-core A57 platform shows speedups of anywhere from negligible to over 2x on a standardized workload. Your benchmark experience will differ.
Go 1.9 release notes are not finished, but a set of draft release notes for Go 1.9 includes this statement:
The release adds transparent monotonic time support, parallelizes compilation of functions within a package, better supports test helper functions, includes a new bit manipulation package, and has a new concurrent map type.
The parallel function compilation will be a substantial benefit on server-class ARM systems that have lots of cores.
Docker has made available a first release candidate of their 17.07 Community Edition software. For the first time, 17.07.0-rc1 includes ARM64 binaries, and it re-introduces support for Raspbian on 32-bit ARMv7 systems.
Rolf Neugebauer from Docker put together a set of LinuxKit ARM64 notes that allow for a boot of this version on Packet's ARMv8 Cavium ThunderX "Type 2A" 96-core servers.
Docker has a rolling release schedule, and 17.07-ce when it ships will be a monthly "edge" option. From the Docker documentation:
Docker CE and EE are released quarterly, and CE also has a monthly "Edge" option. Each Docker EE release is supported and maintained for one year and receives security and critical bug fixes during that period. We are also improving Docker CE maintainability by maintaining each quarterly CE release for 4 months. That gets Docker CE users a new 1-month window to update from one version to the next.
Like any beta and release candidate software, there are known issues
which have some expectation of being fixed before the release goes
official. In this particular case, 32-bit and 64-bit ARM systems
may experience difficulties with Docker Swarm mode, resulting from
inconsistencies in naming of various ARM variants. A suggested
workaround bypasses the machine check with the option --no-resolve-image.
The details can be found in this SwarmKit issue, and the blocking bug described in this moby issue. If one were to want to dive straight into the responsible code, it lives in the scheduler filter at
https://github.com/docker/swarmkit/blob/master/manager/scheduler/filter.go#L288
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick
The problem experienced by Docker is not unique to that project, or even to computer science in general. Sometimes, two different systems give different names for the same thing, and there's a need to normalize names to a single well-known form so that something like a scheduler can know that it's safe to execute code on this system.
For example, 64-bit ARM systems are variably known as arm64, armv8, arm64v8, and aarch64. For 32-bit ARM systems there are even more variants. Different systems may have different capabilities of running 32-bit codes on 64-bit systems, but there is not one single unifying name for that capacity.
To add to the confusion, cross-compilation may create an artifact that was built on one operating system and processor type, but that actually contains executable code for another system.
The State of aarch64 on Guix report from Efraim Flashner is a good roundup of the current status of building packages on the Guix package manager. Guix supports about 5200 packages for aarch64 in their distribution, which is designed as part of the GNU system for the GuixSD System Distribution. By comparison, x86_64 has about 5600 packages.
The differences in package count include:
- Guix uses SableVM as its Java implmentation. SableVM is not actively maintained anymore, according to the project homepage, and has not been ported to aarch64. (In other distributions, the role would be played by OpenJDK or the Oracle JDK.)
-
Guix provides Go 1.4, which is too early for aarch64 support. As noted above, the Go 1.9 release will ship with aarch64 binaries.
-
OCaml 4.01.0 is the release targeted by Guix, but the latest version of OCaml is 4.05.0. aarch64 support for OCaml appeared in release 4.02.
- ghc, a Haskell compiler, has no upstream support for aarch64. This alone accounts for nearly 300 of the missing packages.
It's always good to see a new software distribution tackle ARM64 support. Any commitment to compile and build 1000s of packages for ARM is worthy of interest, even if you don't have immediate plans to use the distribution yourself, because it flushes out pieces of the code path that might otherwise be rarely used.
It's a good thing I didn't try to put together a W29 version, because I didn't have cell phone service most of my vacation.
Works on ARM News is released weekly on Fridays. Follow @worksonarm on Twitter for the weekly link, or follow the worksonarm-news project on Github for notifications. Email to ed@packet.net if you'd like a direct email.
Back and current issues are available from the Works on ARM News archive on Github.