Okay, so hi, I am Afrayim.
I've been working on GNU Geeks for about eight years now.
So supporting the PSABI's with Geeks.
So the PSABI's are the, say, hey, it's been 20-ish years since we first got X8664.
It would be nice if we compiled for something a little newer.
So the PSABI's are a nice way to go and, let's see if I can see both screens, to go and see,
to support both the older machines and the newer machines at the same time.
So this is the output that I got from my computer running dash dash help on LD.so.
As you can see, my machine supports X8664 v3 and v2 and of course the original, just regular X8664.
So it's, you know, how we actually go and figure out what is supported and what isn't.
So something that I wasn't able to find looking through everything is, where are these directories?
I know the libraries go and slash lib and not really clear where the alternate ones go.
So I did what any normal person would do.
I went to my local checkout of G-Lib C and I searched for G-Lib C hardware caps.
So from the test suite, we got dollar L, G-Lib C hardware caps, our little string and our library.
And we also got that supported on three architectures.
So we can see that X8664 isn't the only one that is looking for faster libraries.
So that gives us on X8664 these four paths where LD.so will actually search for libraries that are supported, more or less.
So we have our slash lib and then the two that are after it.
For the sake of completeness, we also have for PowerPC64 little endian.
We have power nine and power 10 and for S390, we have these other ones.
And I've never seen an S390 machine. I just assume that they exist.
So that works well on a regular distribution where all of the libraries go into slash lib or slash user slash lib.
But in Geeks, everything has its own path that everything gets installed into.
And fancy word at the top there is directed acyclic graph.
So individually I know what all of those words mean, but in general it's like the arrows have.
I'm trying to remember if this one goes up or goes down depending on which part of the stack you're working on.
Sometimes we end up with arrows in different directions.
So I'm assuming we're going down on this one.
So for XPAT, it depends directly on get text minimal, which is different than our regular get text, which would have other inputs in it.
And just like for this case, so the acyclic part is what it sounds like.
There's no circles. There's no repetitions.
Once you build the package, that's it. It goes into its designated folder and nothing else gets installed into there.
So before when we had our library outputs, Geeks doesn't have a slash lib folder and it doesn't have these other folders either.
So we still need to convince Geolib C to actually look for all of these places so that we can find the libraries.
So it's before that one.
The other thing is that reading through the bits, it turns out that we're not just looking for, not just checking all of these directories.
We're looking specifically in slash lib.
And then if your hardware supports it, we will also check the other library locations.
So using, you know, to take your favorite library, Readline, you'd have lib slash lib slash readline dot s o.
And you could have it also in your Geolib C hardware caps directory.
But with Geeks, the first one is going to be in its full path slash gnu slash store slash big hash.
And the other ones will be in other paths.
So while you would have libraries in the other paths also, they don't actually end up in the same spot.
And it goes and says, okay, here's my regular Readline library.
I'm going to search for the Geolib C hardware cap along the same path.
It's not going to find anything even though you've already built them.
So question that I guess keeps on coming up when I was looking at this is, is it worth it?
Does this actually make a difference when you're running the programs?
Do you, how much difference do you really get from having a optimized libraries for your computer?
And answer a little bit is, does it matter?
I mean, the options are there.
They wouldn't be there if it wasn't going to do something.
And other part is people want it.
Users want it.
It might make a difference.
So whether or not it matters, we're still doing it.
And to some extent, wonder is it something like the, I always read that as fun roll loops.
Where it's, does unrolling the loops actually matter?
How much benefit are you getting from it?
So, yeah.
So one of the, oh, I got cut off a little bit.
One of the programs that we were experimenting with was the new NCDU written in Zig.
And so up here, I have a just transcribed output from Difascope.
I actually went and compared the two binaries.
Zig does, Zig inherits the optimizations from the underlying LLVM.
And so I compared NCDU built against standard X8664 and one built for X8664 v3, which would run on my desktop.
And other than seeing that more than 99% of the code was the same,
this part was actually the part that had the largest amount of difference in the generated assembly.
And so I don't know if, is it v0 upper is faster than other options here,
but I also noticed that it ends up with the same number of instructions.
So it's, you know, for a lot of this, we really are getting into very minimal benefits in here.
But anyway, like we said, we're doing it anyway. The options are there.
I'm not going to take no for an answer.
Okay, that didn't get cut off at the bottom.
So one of the libraries that we've already looked at and said this one actually benefits is GSL,
which is one of the math libraries.
So what you're looking at here is scheme code.
This is the actual, this inherits from the actual package definition for GSL.
An actual one has, you see this one's missing a version string.
It doesn't have the source location.
It's missing a couple of things where it's just inherited.
But basically package definition defines the name inversion.
It has the source where to get it.
It says what kind of build system to use.
If there are any arguments in the case of GSL, mostly we skip a bunch of tests.
And then some other metadata that goes with it, home page synopsis, description, license.
So for this one, we go and basically say, okay, so we're going to inherit from GSL.
I'm going to change the name so that we append the PSABI to it so we can actually keep them separate.
The make flags, we're going to actually pass to C flags and CXX flags that we're building for the specific PSABI.
We add the, tell it to use the library dir of output is our, is the output.
It's the per package directory where this library will get installed to.
So instead of installing it to output slash lib, we're going to add glibc hardware caps slash PSABI,
which is the directory we saw before.
And then after the installation, we're going to delete a couple of extra bits that we don't need.
We don't need the binary because we're just using the original GSL binary and the headers and include
and anything in the share directory and the package config.
We're just deleting all of that.
And in the properties, we're going to hide it from the CLI so that we people can't just go and install this one on its own.
And we're going to mark it as not tunable because we don't want to say, hey, build this, build this specific library for this specific sub architecture
but actually tune it for my machine because that's not going to help anybody.
So then when we go and we have the actual library similar to before, we go and we say, okay, go ahead and run through everything like normal
using all of the normal package arguments and build arguments and everything.
And then at the end, after install, we're just going to see here copy the actual libraries into their location
because we can't go and say, here's regular GSL and install the other libraries into its folder.
We say we've built a new one and we're going to copy the optimized libraries in.
So then, you know, same thing for PowerPC. I just didn't put it there.
So in the end, this is the regular one. This is the, you know, just a generic one.
I shortened some of the directories so that it would fit.
So we have the top, the full path, the output for GSL.
This was, no, this is the everything together.
We have the full path of the library, of the output for GSL with all of the hardware capability, all the optimized libraries.
You see we have the one set of binaries. We have the headers.
I've collapsed the libder so that doesn't take up all the space.
And then inside the libder, I actually have at the bottom there, we have the libgsl for, you know, just regular.
And then v2, v3, and v4 I closed so that it would all fit.
And we have just the one package config and through all the testing that I had on various machines,
it would go and using this as an input for everything else, it would go and link against the regular libgsl.
And then at runtime, it would go and actually use the optimized library depending on which machine it was running on.
So Geeks being a functional package manager, we end up with functions for things.
So here, some of the bioinformatics programs that I was working on, we have, so here the idea was PGBB, PGGB.
One of the common ways that it was distributed is as a docker image.
So instead of just compiling everything for the, for baseline or for saying, hey, we've made 500 different images based on what your actual machine you're running on,
is we said, okay, we have a list of, in this case, five libraries.
Go ahead and actually replace all of their occurrences in the graph with these ones.
And then when you go to run it, you get all of the benefits of using the faster libraries.
So, you know, just back to the, is it worth it?
So this one I hadn't really planned on getting into so much.
This one was a blog post from last month.
Somebody had gone and rebuilt parts of Arch Linux with, for x8664 v3.
And they have, so yeah, so the claim was that it was 10% performance improvement.
So the other part that's here that, I guess, yeah, not quite cut off is that the rebuilt one on v3 was also built with o3 flag versus the o2 flag that Arch Linux uses.
And then they just went through a couple of programs to see, you know, is it actually faster?
What type of speed benefit can you get?
So negative times are faster, positive times are slower.
So in this case it was, you know, compressing the kernel was faster, decompressing was slower.
Flak was faster in all cases.
Gawk was, you know, toss up.
Gzip was slightly faster, but that might just be o3.
LZ4 was slower.
Python was slower.
R was the same.
Forbus was faster.
And, you know, XZ, basically the same.
Find decompression was faster.
That in general, you're still left with a couple of packages here and there actually benefit from having,
uh, faster libraries.
It's not going to keep people from saying, I want everything to be compiled faster.
I'm going to go back to the fun role loops and, you know, you have to eke out that extra little bit of speed.
But, you know, it's, you know, yes, it's a, you know, from the distro side,
some of it becomes a how much time do I want to spend actually,
I guess maybe not specifically supporting the different options because,
you know, I just send it through and it gets built and it's done,
but how much time do I want to spend building four copies of everything
so that I can mush them all together and, you know, expand the size of the final library?
Um, what did I have over here that I...
No, I thought I had a thing right there.
Uh, so I guess the other part that we had with this was that, you know, this one, you know,
this assumes that, I mean, first of all, this works well for GSL.
Uh, I could go and change it from, you know, GSL HWABI is the name of the function to make it more general
and then start passing it other, you know, pass the name of the actual library to inherit from and all of that.
But, you know, the other part of this is this assumes that passing just C flags and CXX flags
are going to actually go and produce the binary, the optimized files that you're looking for.
And, you know, not always the case.
Sometimes you end up with ones that need extra CXX flags or you need to go and manually add them in anyway
or they're hard-coded and they need to be substituted out.
And, you know, going back to the, do I, you actually want to go and support every single package
becomes a do you want to go through the entire archive of all of the packages
for something that may or may not actually make a difference on all of the libraries?
Oops, that was too far.
So, yes, yeah, are there any questions?
Any comments?
Okay.
Thanks.
So how far have you gotten in implementing this?
Is it just something you've been experimenting with or something that's actually working?
I've mostly been experimenting with it.
Some of it is, you know, I don't want to actually, don't actually want to build everything multiple times.
But the size increase, that's the part that I thought I had, the size increase on GSL,
it went from, I think it was 5.5 megabytes to about 18 megabytes by adding in basically the four different copies
of all of the libraries.
So it really becomes, you know, say for Vorbis or for Ag or for specific libraries that we know are going to make a difference.
It really makes a difference.
For other ones, you look at it and say, okay, you know, LibxUL runner for Firefox, that's 100 megabytes.
And it's a long build process.
Maybe we won't do that one.
Okay.
You said that there is support for PowerPC, Power9 and Power10.
And what is this older variant?
So PowerMicroVod or Power7?
The...
They are all 64-bit PowerPC variants.
They are all PowerPC, they are all the 64-bit variants from the actual G-Lib C, where was it?
From the actual G-Lib C source code, these are the only directories that are currently...
I think this was accurate as of 2.38.
These are all of the directories that are searched for additional libraries.
So I think Geeks right now targets Power8 as the baseline.
So a backboard would be needed for Power7 and for MicroVod.
You have to get it into G-Lib C to have the...
I mean, I guess if you compiled the distribution for Power7, then you would have support for Power7 there.
But in terms of having the special directories, currently there's no support in G-Lib C, although I suppose it could be added.
I might investigate later if I have hardware or buy hardware, because I'm interested in the PowerPC notebook project.
And they have much more modern hardware compared to anything Apple used, but it's still older than Power8.
I've tried some benchmarks yourself with some of the applications, because what you showed with the microscope,
those were mostly SIMD instructions, which were optimized.
So I think everything which uses those can profit from the knowing that there's like a different kind of vector extension.
I ran a couple of benchmarks. Most of them were inconclusive.
The one that I actually noticed the biggest change in was LZ4.
I actually compiled one for X32 for the 64-bit, X8664 with 32-bit instructions.
I think the claim in general is that it's supposed to be up to 40% faster, and I found that the LZ4 benchmarks were 5% slower.
So other than actually being quite surprised by that, a lot of it really seemed to fall into the, is it just hot cash?
Is there something else running in the background? Is it actually a big enough change to be worth it?
I don't know if that's fine, but thank you very much for your time.