News
2026-05-23
[ ↑ ]Examining 7-zip performance on ia64
There are lots of different benchmarks, examining different aspects of hardware. One of them is the compression/decompression benchmark integrated in the 7-zip file archiver which we will cover in the following. 7-zip is readily available for lots of architectures and operating systems, which allows to compare performance of different hardware (and also hardware running different operating systems if desired). We will look into single and multiprocessing benchmarking and hardware multithreading effects on ia64 and finish up by comparing different ia64 processors and also explore how ia64 compares to modern x86_64 in 7-zip performance - which is quite astounding considering the age difference.
This article will be later expanded with an observation of the variance in SP and MP results. So stay tuned for that, but for now have a read...
2026-04-26
[ ↑ ]
Linux v7.0, Altix support, glibc improvements and Ruby on ia64
There are lots of things happening in parallel nowaydays - also in regard to ia64. Like in computing this gets a lot of things done at the same time, leading to a speedup in developments. So lots of news this time.
Linux v7.0
The final release of v7.0 is out, and of course it also runs on ia64. See the 7.0-epic2 release with highlights like (1) the fixed ia64 glass console for Integrity hardware, (2) the recently added system calls (everything but clone3) for ia64 that were missing so far and not to forget (3) another ia64 assembly language optimization that makes strnlen_user() in the kernel using a software pipelined loop enabling around twice (!) the performance in the best case compared to the original implementation. Also see the fork for continuous release (candidate) testing for details. This testing usually happens weekly and tries to test-run every release (candidate) compiled with the latest GCC snapshot and current binutils version on the supported hardware, which so far (1) mainly consists of machines produced by HP, namely Integrities and several generations there, and (2) the Ski ia64 instruction set simulator (also originally created by HP, but open source since a while). Thanks to a great patch set created more than a decade ago but never upstreamed until recently, Ski became really useful. The patch set retrofits Ski with a sort of emulated hardware clock, support for TUN/TAP networking and host idling. With all this included you can use Ski with confidence and even build a full Linux kernel (for Ski) with it. All this natively on a cluster of Ski instances with a modified version of distcc running under EPIC Slack and some preparation work. More on that maybe later.
Now the list of supported ia64 hardware is about to change with...
Altix support
You might want to rub your eyes reading this - "Altix support? Wasn't it removed from Linux long ago?". Well, yes, it was removed with 5.4-rc1 in 2019 already, actually at the same time as support for running a Linux kernel in Ski was removed - not that there was any other free alternative to Ski available back then or today. Well, this problem could be solved already in early 2024 with Ski support - aka the hpsim platform - restored for Linux mainline and stable versions. For the other removed platform - Altix aka SN2 - this was not so easy. The involved machine vector mechanism that enabled to use the same kernel image and modules for different ia64 hardware (HP Integrity, SGI Altix, BULL NovaScale, NEC AsAmA, etc.) really didn't make it sound like an easy restoration process. On top there was no Altix hardware available in our group. So for the time being Altix support in Linux stayed a feat from the past. But this was about to change, in the end rather quickly actually.
In early 2025 someone who actually had Altix hardware (Altix 350 and 3000 series hardware, both NUMAlinked) thought it would be nice to have more modern Linux kernels running on these. This first effort quickly lead to results and culminated in Linux 4.19.325 running on a NUMAlinked 32 processor Altix 3700. Based on linux.4.19.y this is still supported to this day by the CIP project.
Now earlier this year, this was brought to the next level by the same person. By applying the help of an LLM to the mix - Claude Opus in this case - things could be simplified and sped up radically. Starting with the existing Altix patches for pre 5.4 kernels and the revert of its removal in 5.4-rc1, the needed changes for restoring Altix support for 5.10 could be simplified after an analysis by the LLM. Even further in additional discussions between human and LLM, tackling specific questions like if it could be possible to restore Altix support without reintroducing the whole machine vector infrastructure. Over the course of muliple weeks this approach made short work out of forward-porting the Altix restoration patches to newer kernel versions. Culiminating in v7.0(-rc1) running on Altixen just days ago. To the best of our knowlegde this is a novel approach to use an LLM duing the restoration process of some old piece of software, see additional details on the restorer's website. Also this approach might become the archetype for restoring long gone architecture support in Linux or any other OS with sources available. Well at least it could speed things up considerably for such an endeavour and also widen access to people that in the past were maybe scared away by the extent of such a restoration. Anything in mind already? Maybe restoring POWER4 support in Linux? Yes please!
But why stop there? Since then we've seen graphics support working again on Altix - and hopefully also on Prism machines in the future. Accelerated KDE Plasma, Minecraft and what not - all possible now on hardware that was broken in Linux since 2015 and support for it removed in 2019.
Glibc improvements
Also glibc improvements for ia64 code continue. One of the latest ones being the implementation of a pipelined loop for strncmp() leading to a massive speedup in the best case scenario. The original implementation always needs a minimum of 2 cycles per character, whereas the new implementation can bring that down to 1 cycle per character in the best case. Meaning an improvement in performance of 100 % (i.e. twice as fast as before). If you're interested in these kind of optimizations, please have a look into the Fine-tuning strcmp() performance article series (part 1, part 1.5, also linked from the pictures).
Ruby on ia64
As you might have noticed, the Distributions menu has gotten an additional entry since a while already: Afterglow, marking the third GNU/Linux distribution with support for ia64. Afterglow is a special edition of AOSC OS targetting retro hardware, sharing the same source tree with AOSC OS. While Afterglow is currently bootstrapped for ia64, a developer also had a look into Ruby support for ia64. Though ia64 support was removed from upstream Ruby long ago, already before version 3.x, there were initial efforts to restore ia64 support for 3.x in T2. And this was now taken as basis to restore ia64 support for Ruby 4.0.2! Building something successfully is one thing, testing it is another, but here it also looks quite good for how long Ruby had no support for ia64, with only 4 out of 2038 tests failing (i.e. less than 0.2 %!). On top of that,
gem is working properly, Bundler as well. So it looks like there's not much in the way now, to try a few gems also on ia64.2026-03-15
[ ↑ ]Fine-tuning strcmp() performance, part 1.5
by Tomáš Glozar
What does it take to squeeze every last cycle out of a string comparison function? In this deep dive into glibc's strcmp() for the Itanium architecture, we build a pipelined loop that processes one character pair per cycle – a 2× improvement over Part 1, and 3× over the original baseline – by keeping the CPU's load and arithmetic units busy simultaneously rather than letting them take turns. But speed comes with complications. A pre-loading strategy that boosts performance turns out to cause segmentation faults on valid inputs, leading us to Itanium's elegant solution: speculative loads that defer memory exceptions rather than crashing immediately. Fixing that surfaces yet another subtle issue – NaT values silently leaking into return results when callers pass invalid pointers.
The final implementation threads all these needles at once: correct, fast, and well-behaved under invalid input. Along the way, it turns out that the very NaT-handling behavior of Itanium's
cmp..and instruction – an architectural quirk that might seem like a footgun – becomes the key to keeping the optimized loop at 1 cycle per character without bloating the loop body.Summary generated by Claude Sonnet 4.6 and verified by author
2026-02-24/27
[ ↑ ] Linux mainline testing for v7.0-rc1 successful
The merge window for v7.0-rc1 was quite the ride for ia64 and required a lot of pr-RC test candidates and also some bisecting to fix an issue with Ski (checkout the commit history for v7.0-rc1 after
8626451[9e8d702f6067dbca8b8697b3e43892652]).The first release candidate in this cycle is now ready and has been tested to work on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v7.0-rc1. Like always the latest available GCC snapshot (at this time gcc-16-20260222, based on
6e35a5d5b2974e200147c51735a3c83a86f223c6 was used to build the kernel image.
NOTICE: Testing of the first RC again went a little further than usual and also incorporated bootstrapping GCC 16.0.1 20260222 (experimental) (duration:
real 402m58.174s, user 2750m21.035s, sys 31m17.856s) and running the testsuite for C an C++ parts (duration: real 434m19.288s, user 3213m6.031s, sys 192m53.387s) on the rx2800 i2. Bootstrap and testsuite runtimes only increased mildly compared to the timings for GCC 16.0.1 20260125 (experimental). But both timings were a considerable increase compared to the timings for GCC 16.0.0 20251214 (experimental). But this might be attributed to the fact, that the bootstraps and testsuite runs since beginning of the year were made with LTO support enabled, which wasn't the case for prior runs.Also 7.0-rc1-epic1 is ready since 2026-02-27 and was successfully tested on another rx2620. This is also the machine where all the optmization work happens, where ia64 assembler routines are painstakingly fine-tuned to get the most out of this architecture. Stay tuned for a soonish update on this topic. For now have a look at web productivity and use with background compilations happening on the very same machine:
2026-02-11/12
[ ↑ ] Linux mainline testing for v6.19 successful
The final release in this cycle is now ready and has been successfully tested on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.19. Like always the latest available GCC snapshot (at this time gcc-16-20251130, based on
df7f52b3a4ca00b64baf31c57c506fe3afe51c9f was used to build the kernel image.Also 6.19-epic2 is ready since 2026-02-11 and was successfully tested on another rx2620, this time also with latest Plasma 6.6.
2025-12-17/20
[ ↑ ] Linux mainline testing for v6.19-rc1 successful
This time only two pre-RCs were needed during the merge window for v6.19-rc1 (checkout the commit history for v6.19-rc1 after
ca63b61[ecd0319e9586d9aef7b0c80eee295d8e6]).The first release candidate in this cycle is now ready and has been tested to work on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.19-rc1. Like always the latest available GCC snapshot (at this time gcc-16-20251214, based on
8e23a9982fa4b885a27608825cbe326d61f20498 was used to build the kernel image.NOTICE: This time testing of the first RC again went a little further than usual and also incorporated bootstrapping GCC 16.0.0 20251214 (experimental) (duration:real 375m14.588s, user 2621m34.352s, sys 30m38.349s) and running the testsuite for C an C++ parts (duration:real 400m57.482s, user 2907m2.725s, sys 156m12.341s) on the rx2800 i2. Bootstrap (+ 55 mins approx.) and testsuite runtimes (+ 35 mins approx.) increased considerably compared to the timings for GCC 15.2.0, see below.
Also 6.19-rc1-epic1 is ready since 2025-12-20 and was successfully tested on another rx2620 with Wayland and KDE Plasma on top. Check this out (more details and discussion on the corresponding post on reddit):
2025-12-06
[ ↑ ]Fine-tuning strcmp() performance
by Tomáš Glozar
The glibc contains several architecture-specific implementations of functions in assembly. One would assume those were carefully optimized and achieve close-to-optimal performance, to the extent possible without further assumptions of the inputs - especially for short and simple functions, like
strcmp(3). On Itanium, however, due to a strange mix of oversight in the assembly implementation and in the implemention of the assembler, it turns out that strcmp's performance is nowhere near optimal, even under conservative assumptions. This affects, among other things, the numbers reported by the Dhrystone benchmark.In this article, which will (hopefully) be the first of a series, I describe a detailed analysis of the glibc ia64 assembly implementation of strcmp and uncover its performance limitations.
2025-12-02
[ ↑ ] Linux mainline testing for v6.18 successful
The final release in this cycle is now ready and has been successfully tested on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.18. Like always the latest available GCC snapshot (at this time gcc-16-20251130, based on
e1f33d3890ddccca3a2c6c5bce08d68e313b1f3a was used to build the kernel image.2025-11-01/02
[ ↑ ]
Linux/ia64 - a two year retrospective
Maintenance of Linux/ia64 (specifically the ia64 port in the Linux kernel and later also the ia64 port in the glibc and even more) started about two years ago shortly after the release of Linux v6.6. Now nearly two years later it's time for a look back and to recall what has happened since then.
So let's have a look into our timeline and see what has been accomplished.
Also have a look into this talk by Tomáš:
2025-10-14
[ ↑ ] Linux mainline testing for v6.18-rc1 successful
This time again four pre-RCs were created and tested during the merge window for v6.18 (checkout the commit history for v6.18-rc1 after
ca63b61[ecd0319e9586d9aef7b0c80eee295d8e6]) all happening mostly in the first week, too.The first release candidate in this cycle is now ready and has been tested to work on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.18-rc1. Like always the latest available GCC snapshot (at this time gcc-16-20251012, based on
ac524299110838ed8eafb615d100a28649af7f18 was used to build the kernel image.2025-09-30
[ ↑ ] Linux mainline testing for v6.17 successful
The final release in this cycle is now ready and has been successfully tested on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.17. Like always the latest available GCC snapshot (at this time gcc-16-20250928, based on
143cec1646ae2e0cfdb1874defdc65e6d535e27c was used to build the kernel image.NOTICE: On top of what was done during the merge window (see the commits in the v6.17-rc1-w-ia64 branch, starting withff52bc4this release includes additional patches (1) from AOSC developers cleaning up lots of build issues that are fatal withCONFIG_WERRORenabled - see the corresponding pull request for details - and (2) from the original upstream repo which was recently updated - seea7192bc,e05a95dandf9bebc7.
On top of that a last minute patch was added that restores the ia64 related changes ofc4dd854that somehow got lost. Kernel builds for real machines were not affected by this, this only manifested for hp-sim builds for Ski. But as the hp-sim patches up until now included a part of these changes, this was not detected earlier, but just noticed yesterday due to erroneously trying to build an hp-sim kernel for Ski w/o applying the hp-sim patches first.The merge window for Linux v6.18 has already started by now, but so far our autobuilder for Linux mainline continues to build kernel images successfully. We'll see what will be needed extra for ia64 until the end of the merge window. If all goes well, we will be running v6.18-rc1 successfully on all machines in two weeks from now.
2025-08-15
[ ↑ ] Linux mainline testing for v6.17-rc1 successful
This time four pre-RCs were created and tested during the merge window for v6.17 (checkout the commit history for v6.17-rc1 after
cce3a2d[450435f13e6a92f7b2b95b292ba22f361]) all happening mostly in the first week.The first release candidate in this cycle is now ready and has been tested on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.17-rc1. Like always the latest available GCC snapshot (at this time gcc-16-20250810, based on
767f65cf82b516656dda95802a83bf905550f0b3 was used to build the kernel image.NOTICE: This time testing of the first RC went a little further than usual (i.e. short compile tests on every machine but rx2800 i2 and Ski/hp-sim and building EPIC-Slack packages on the rx2800 i2) and also incorporated bootstrapping GCC 15.2.0 (duration:real 319m54.690s, user 2240m28.957s, sys 26m59.556s) and running the testsuite for C an C++ parts (duration:real 366m24.859s, user 2644m10.715s, sys 150m52.751s) on the rx2800 i2. Actually with temperatures falling the rx2800 i2 just now also bootstraps GCC 15.1.0 to better see progress between testsuite results for gcc-15-20240528 w/LRA enabled and GCC 15.2.0.
2025-06-10
[ ↑ ] Linux mainline testing for v6.16-rc1 successful
This time one more pre-RC was needed during the merge window for v6.16 compared to the last one (checkout the commit history for v6.16-rc1 after
0d3e2c0[4e67d64fc3521eea235da00be02c1e158]). Fortunately the required more complex change was available in the history, see 0656aff for detailsThe first release candidate in this cycle is now ready and has been tested on all machines:
- rx4640 (GOOD)
- rx2620 (GOOD)
- rx2660 (GOOD)
- rx2800 i2 (GOOD)
- rx6600 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.16-rc1. Like always the latest available GCC snapshot (at this time gcc-16-20250608, based on
fd04219) was used to build the kernel image.2025-04-09
[ ↑ ] Linux mainline testing for v6.15-rc1 only partially successful
This time we had a quite extensive merge window for v6.15 (checkout the commit history for v6.15-rc1 after
c8ef75c[6061b55d43d5ff04e52c83a51bf676151]) that required a considerable amount of work to follow.The first release candidate in this cycle is now ready and has been tested on all machines - unfortunately with mixed results:
- rx4640
(BAD)=> (GOOD, since 2025-04-13) - rx2620
(BAD)=> (GOOD, since 2025-04-11) - rx2660
(BAD)=> (GOOD, since 2025-04-13) - BL860c
(BAD)=> (GOOD, since 2025-04-13) - rx6600
(BAD)=> (GOOD, since 2025-04-13) - rx2800 i2 (GOOD)
- hp-sim (GOOD)
..., see testing-effort/tested-kernels-table.md#v6.15-rc1. Like always the latest available GCC snapshot (at this time gcc-15-20250406, based on
b39d5fa) was used to build the kernel image.HINT: For now the branch v6.15-pre-rc-w-ia64 contains the last code state that worked on all machines.
UPDATE (2025-04-11): Good news! The reason for the breakages on the rx2620 (and most likely also the other zx1 and zx2 systems, but still needs to be checked on that hardware) was finally found yesterday and "fixed" this morning by not following through with the architecture changes of 8afa901 for ia64. Seems like earlier systems are sensitive in this regard, so a warning was placed in the ia64 code to take care about this in the future. See 5253aad. Hence a new branch was created for v6.15-rc1: v6.15-rc1-w-ia64-2.
2025-04-02
[ ↑ ]Ski - the undiscovered country
One of the main road blocks for getting more IA-64 machines in the hands of interested people, is both their scarcity and their nowadays very high prices. Sure, if you're lucky, you can get an IA-64 machine for cheap or even for free, but having observed the situation for over a year, those lucky events don't seem to happen to people actually interested in IA-64 - or at least not that often. But do people really need real machines for having a first look into IA-64? In the end people might just want to run a Linux distribution on IA-64 to see it in action and play around with it or to verify that it is not so different at all compared to other architectures (leaving internals aside) when using a common operating system on it.
Fortunately there is another way: Enter Ski - a fully working software implementation of an IA-64 processor - or "machine" if you like. But it seems like this soft machine and its features are not very well known, although existing since 30 years according to it's earliest copyright.
Let's change that and have a read.
2025-02-04
[ ↑ ] Linux mainline testing for v6.14-rc1 successful
This time only a few regressions (and only two pre-RCs needed!) during the merge window for v6.14 (checkout the commit history for v6.14-rc1 after
c15d28e[39fc37f5c2ada71af0a80f3b03f15ede9]).The first release candidate in this cycle is now ready and has been tested on all machines:
- rx4640
- rx2620
- rx2660
- rx2800 i2
- rx6600
- hp-sim
..., see testing-effort/tested-kernels-table.md#v6.14-rc1. Like always the latest available GCC snapshot (at this time gcc-15-20250202, based on
969c308) was used to build the kernel image. Also, since binutils had a new release, version 2.44 was used for this build, too.2025-01-14
[ ↑ ]Docs, docs, docs...
Over time quite some documentation about IA-64 has accumulated and the web is still full of it. There are loads of articles and papers, presentations, white papers and general documentation available. But most of it is unfortunately spread over the web and it's not so easy to get an overview. To make it easier for interested folks to learn about IA-64 and also for us to access the available documentation, a - so far still small - part of it was catalogued and links to it were curated here for easier access to the knowledge hidden in there.
As if to prove that this documentation is indeed useful, it was just recently put to use to extend the processor feature flags of Itanium processors in the kernel according to the SDM 2.3 and also to give Ski - the IA-64 instruction set simulator - its own processor type. The related kernel changes to the latter will be published at the usual place when v6.13 is released.