Posts
Rest in peace, Itanium
Firefox 90 on POWER (and a JIT progress report)
Firefox 90 is out, offering expanded and improved software WebRender (not really a problem if you've got a supported GPU as most of us in OpenPOWER land do, though), an enhanced SmartBlock which ups the arms race with Facebook, and private fields and methods in JavaScript among other platform updates. FTP is now officially and completely gone (and really should be part of registerProtocolHandler as Gopher is), but at least you can still use compact layout for tabs.
Unfortunately, a promising OpenPOWER-specific update for Fx90 bombed. Ordinarily I would have noticed this with my periodic smoke-test builds but I've been trying to continue work on the JavaScript JIT in my not-so-copious spare time (more on that in a moment), so I didn't notice this until I built Fx90 and no TLS connection would work (they all abort with SSL_ERROR_BAD_SERVER). I discussed this with Dan Horák and the official Fedora build of Firefox seemed to work just fine, including when I did a local fedpkg build. After a few test builds over the last several days I determined the difference was that the Fedora Firefox package is built with --use-system-nss to use the NSS included with Fedora, so it wasn't using whatever was included with Firefox.
Going to the NSS tree I found bug 1566124, an implementation of AES-GCM acceleration for Power ISA. (Interestingly, I tried to write an implementation of it last year for TenFourFox FPR22 but abandoned it since it would be riskier and not much faster with the more limited facilities on 32-bit PowerPC.) This was, to be blunt, poorly tested and Fedora's NSS maintainer indicated he would disable it in the shipping library. Thus, if you use Fedora's included NSS, it works, and if you use the included version in the Firefox tree (based on NSS 3.66), it won't. The fixes are in NSS 3.67, which is part of Firefox 91; they never landed on Fx90.
The two fixes are small (to security/nss/lib/freebl/ppc-gcm-wrap.c and security/nss/lib/freebl/ppc-gcm.s), so if you're building from source anyway the simplest and highest-performance option is just to include them. (And now that it's working, I do have to tip my hat to the author: the implementation is about 20 times faster.) Alternatively, Fedora 34 builders can still just add --with-system-nss to their .mozconfig as long as you have nspr-devel installed, or a third workaround is to set NSS_DISABLE_PPC_GHASH=1 before starting Firefox, which disables the faulty code at runtime. In Firefox 91 this whole issue should be fixed. I'm glad the patch is done and working, but it never should have been committed in its original state without passing the test suite.
Another issue we have a better workaround for is bug 1713968, which causes errors building JavaScript with gcc. The reason that Fedora wasn't having any problem doing so is its rather voluminous generated .mozconfig that, amongst other things, uses -fpermissive. This is a better workaround than minor hacks to the source, so that is now in the .mozconfigs I'm using. I also did a minor tweak to the PGO-LTO patch so that it applies cleanly. With that, here are my current configurations:
Debug
export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
mk_add_options MOZ_MAKE_FLAGS="-j24" # as you like
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-Og -mcpu=power9 -fpermissive"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd
export GN=/home/censored/bin/gn # if you have it
PGO-LTO Optimized
export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
mk_add_options MOZ_MAKE_FLAGS="-j24" # as you like
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-O3 -mcpu=power9 -fpermissive"
ac_add_options --enable-release
ac_add_options --enable-linker=bfd
ac_add_options --enable-lto=full
ac_add_options MOZ_PGO=1
export GN=/home/censored/bin/gn # if you have it
export RUSTC_OPT_LEVEL=2
So, JavaScript. Since our last progress report our current implementation of the Firefox JavaScript JIT (the minimum viable product of which will be Baseline Interpreter + Wasm) is now able to run scripts of significant complexity, but it's still mostly a one-man show and I'm currently struggling with an issue fixing certain optimized calls to self-hosted scripts (notably anything that calls RegExp.prototype.* functions: it goes into an infinite loop and hits the recursion limit). There hasn't been any activity the last week because I've preferred not to commit speculative work yet, plus the time I wasted tracking down the problem above with TLS. The MVP will be considered "V" when it can pass the JavaScript JIT and conformance test suites and it's probably a third of the way there. You can help. Ask in the comments if you're interested in contributing. We'll get this done sooner or later because it's something I'm motivated to finish, but it will go a lot faster if folks pitch in.
Intel might fab your next POWER chip
The Wall Street Journal is reporting that Intel is in talks to buy GlobalFoundries ("GloFo")' manufacturing assets for potentially as much as US$30b (via Reuters). Much of the amusement on the Internet tech sector side is because GloFo started life in 2008 as the divestiture of AMD's manufacturing arm, an admittedly entertaining historical irony, but GloFo is important to us in OpenPOWER-land too because they manufacture the POWER9.
GloFo's fabbing of POWER and OpenPOWER comes from a July 2015 deal with IBM where IBM basically paid GloFo US$1.5b to take and operate their U.S.-based chip manufacturing business unit. In return, GloFo would provide chips to IBM through 2025. The POWER9 in your servers and workstations was initially manufactured at IBM's former East Fishkill, NY plant, which became GlobalFoundries Fab 10 and was sold to ON Semiconductor in 2019, and are now produced at GloFo Fab 9, which was IBM's previous plant in Essex Junction, VT.
This arrangement was odd even at the time, and admittedly wouldn't have been IBM's first choice, but semiconductor production has obvious national security implications and regulators wouldn't let it just sell off or shut down its entire domestic manufacturing arm. Predictably the deal doesn't seem to have gone well. In a lawsuit last month, IBM alleged that by fall 2015 GlobalFoundaries told IBM they wouldn't proceed further on development of a 10nm process and instead would move to 7nm, jeopardizing the POWER9 which was originally supposed to be produced at 10nm. IBM claims that despite what it views as a contract breach, it nevertheless continued the payout to bring up a 7nm process instead by Q3 2018, which didn't happen either. At that point IBM says GloFo asked it for another $1.5b, which IBM refused, and GloFo suspended further development. The POWER9 was eventually manufactured with a 14nm node size using FinFET technology instead.
Intel's interest in GloFo is to secure a manufacturing pipeline for its silicon in the midst of the global chip shortage, and, as voiced earlier this year by CEO Pat Gelsinger, to get a piece of the chip manufacture business from companies other than itself. While GloFo is only about 7% of the market, they have a customer base and support infrastructure Intel completely lacks. While GloFo's current node size is still not highly competitive, there is still a lot of money to be made in larger process sizes for less performance-sensitive applications. Chipzilla certainly has its own fabs but their technology has not been nearly as advanced (certainly not as much as, say, TSMC), and they cater nearly exclusively to Intel in-house designs. However, AMD still relies on its former facilities at GloFo for its own chips, which would certainly attract regulator scrutiny if Intel were to control its supply chain. The deal does not seem to involve GloFo the company, but would have to involve its physical assets and operations to be at all worth the headache.
The POWER9 is still made at Fab 9, but IBM, chastened by its problems with GloFo, has turned to Samsung and its 7nm process for POWER10. However, Intel has a strong interest in improving its node size and although exact numbers have lately gotten more and more meaningless, Cannon Lake, Tigerlake and others are "still" at 10nm, whatever that means. Plus, Intel would presumably have control over IBM's old facilities which they would still know relatively well, and while IBM doesn't have the volume of other chip designers anymore, they're still considered a significant player and their parts are higher-end. AMD may not like their next chips being fabbed by Intel but IBM may not have a problem with it, and if Samsung can't deliver on POWER10 after all, stranger things have happened.
Chimera Linux: if you like BSD and Linux, why not both
A new Linux option for ppc64le popped up on my radar today, and this one's really interesting: if you like the way FreeBSD does business, but you want a Linux kernel, now you don't have to choose. Chimera Linux gives you a FreeBSD userland with no GNU components in the base system except make and ncurses (for some of the readership this will be a feature), plus the ability to bootstrap itself from any musl-based distro like Alpine or Adelie or Void PPC's musl variant. ppc64le, aarch64 and x86_64 are the three launch architectures, making OpenPOWER a first-class citizen from the very beginning, and they promise portability with any architecture that has LLVM/clang available.
There are some important questions yet to answer, however, and the distro is clearly not yet ready for prime time. There's no init system yet (let's hope it's not systemd, because that would really be an unholy union) and there's not even a kernel, so I can't tell you what it runs; presumably it uses the kernel of the distro you bootstrap it on. For that reason, don't even think about asking for a bootable ISO. The source package build system is also custom and it wouldn't be surprising to me if it manifested rough edges for awhile.
The other question mark is LLVM; Chimera relies on clang, not gcc. clang works for a lot of things on ppc64le but at least in my usage doesn't properly work for some large projects like Firefox, and its performance is marginally poorer. This is undoubtedly no problem on the other two architectures, but they are the primary focus of LLVM and clang, and OpenPOWER isn't.
Still, I think there's real potential for this project, quite possibly for people who would ordinarily be attracted to Slackware's philosophy but are more used to the way BSDs do business. (As a product of the University of California, I have great empathy for this viewpoint.) And there's already precedent: Mac OS X macOS is a Mach kernel, but with a BSD userland, and look at how successful that concept was. Sometimes the best choice is the one you don't have to end up making.
Bloody Friday at IBM?
But of course there is something to see here. Cutting through nonsense like "our hybrid cloud and AI strategy is strongly resonating" (remember, things break if they resonate too much), the biggest thing to see is IBM President Jim Whitehurst stepping down. Whitehurst was, of course, the former CEO of Red Hat prior to its merger with Big Blue, and he lasted just over a year as IBM President (but over twelve with Red Hat). He will now be working as a "Senior Advisor" to IBM CEO and chairman Arvind Krishna, which is a nice way of saying a paid sinecure until he finds another gig, and it's unclear if he will get any further payments on his US$6 million retention bonus. This is what it looks like when someone is pushed out, presumably over fax given the current IBM E-mail migration mess.
Whitehurst wasn't the only executive blood spilled: the senior VP of global markets is also out (not to be confused with Global Technology Services), now similarly moved to an executive sinecure for "special projects," and the former senior VP of IBM systems and hardware has either been laterally moved or outright demoted to senior VP of "cloud and cognitive software." Various other new names are coming on board, too. It really reads like Krishna is cleaning house.
Is this reshuffle part of the bootup of the cloud-focused IBM "NewCo", now called the vaguely unpronounceable Kyndryl? Technically NewCo-Kyndryl doesn't exist until the end of this year, and none of the officers Kyndryl announced yesterday include the names in IBM's announcement today. But it would be surprising for any of the cloud operations to remain at IBM "OldCo" which is supposed to have the legacy software and hardware operations ... unless the reasoning for the split was just a load of hooey and it was never the intention for either half of the company to retain exclusive control over its respective market interests. That probably bodes more ill for Kyndling, er, Kyndryl than it does for its parent corporation. Either way, it certainly looks like Red Hat proved the old joke is true: anything plus IBM ends up equalling IBM.