One of the problems with the systems seems to be IBM support, at least for people with Sierra/Summit-like nodes who are averse to trying to talk to Livermore and Oak Ridge. That includes dropping support for what seemed to be the major selling point for our system before it got going. (Admittedly it probably only needs someone who needs it with some get-up-and-go to do the work, but still.) It is different with the IBM GCC maintainers, who you don't talk to through IBM, of course.
Keeping POWER relevant in the open source world
61–70 of 75 posts
Re: Keeping POWER relevant in the open source world
#62> in most parts software support for Power 9 is now in par with x86 and ARM.
I very much doubt this.
> we need affordable Power hardware quickly to keep and expand the momentum.
Possibly, but the POWER architecture would get (a lot ?) more traction if the entities behind it made VMs with OS distros easily available for ensuring FOSS builds and works on them. This is much less of a challenge than making cheap hardware available.
Travis CI - the way it used to be anyway before they started asking for money even from FOSS developers - is a good example of how this could be offered. It was very easy to set this up for your FOSS repository (on GitHub at least - but IBM would need be more welcoming than that), and from that point it wasn't that hard.
For some larger projects, direct interaction may be even more readily effective, e.g. getting in touch with maintainers of Linux and with BSD distributions, with the Document Foundation for LibreOffice support (maybe it's already supported?) etc.
---
If this happens in parallel (or before) reasonably-cheap hardware is available, then I would expect more "buy-in", figuratively and literally.
Re: Keeping POWER relevant in the open source world
#63Big Endian POWER isn't bug-for-bug compatible with buggy Javascript usage of typed arrays that assumes little endianness, and thus browsers/nodejs/deno on POWER will be exposed to bugs that don't affect little endian x86-64/ARM.
After so many years of endianness bugs in C/C++ code, it's perplexing that the web standards committee voted to put typed arrays in Javascript in such a way that exposes platform byte order to Javascript programmers who can't generally be expected to have low-level C/C++/ASM experience with memory layout issues:
function endianness () {
let u32arr = new Uint32Array([0x11223344]);
let u8arr = new Uint8Array(u32arr.buffer);
if (u8arr[0] === 0x44)
return 'Little Endian';
else if (u8arr[0] === 0x11)
return 'Big Endian';
else
return 'WTF (What a Terrible Failure)';
}
Re: Keeping POWER relevant in the open source world
#64IBM has had this argument internally for eons. When i was there, two decades ago , people were making presentations internally saying the same thing - "without affordable volume machines that random people can buy and use to develop, this ecosystem will fail" Then, like now, there were even organizations/companies people thought might eventually take care of doing this that weren't IBM (Spoiler alert: They didn't) Gi…
Warning: rant (sorta) I remember discussing with an IBM representative at one of the last CeBIT shows (was it 2016?) that the community who did open source development on non-x86 were gravitating away from POWER/PowerPC towards ARM. The affordable hardware was a major selling point. His offered "solution" was that IBM granted free access to its POWER cloud. But that is of course not interesting for someone who runs a…
I think Debian still supports POWER8 (and has unofficial ports for 32-bit PowerPC and for big-endian POWER).
Re: Keeping POWER relevant in the open source world
#65Earlier quoted context omitted.
Fedora on POWER9 for my daily driver, personally (a dual-8 Raptor Talos II). I like the architecture, having been an AIX admin since the 3.2.5 days (still have a personal POWER6 with it) and a long time Power Mac bigot, and I like Raptor's commitment to openness. My HTPC is a Blackbird. It shouldn't be a privilege to own a fully user-auditable computer. Cost continues to be a problem, which is why I hope Microwatt ge…
Unrelated, but thank you for your blog! I check in occasionally, mostly looking for a reason to justify buying one of the Raptor machines at work. I really enjoy the articles on qemu/virtualization.
Hey, thanks! Very kind of you to say.
Re: Keeping POWER relevant in the open source world
#66Earlier quoted context omitted.
Very interesting. Which channel specifically? VSX is really where the new development is happening, but it's become quite complete. The PC-direct instructions first made available in P9 also really closed a gap (beforehand you had to do bl with a weird flag to get PC in LR without trashing the history table).
The IRC channel was #talos-workstation on FreeNet, now on Libera.Chat. Do you know of some minimal example of calling VSX instructions from C? Ideally just one .c file and one Makefile or README with the exact GCC command to compile it, plus a pointer to documentation describing each instruction. I’ve seen assembler inserted into C source code with GCC, but I’ve never done it and I assume there are some non-obvious d…
Sorry, didn't see this until now (out all day). Here is a very stupid example that uses `xxbrd` to byteswap a 64-bit quantity.
#include
#include
#include
#include
int main(int argc, char **argv)
uint64_t v = 0;
double o;
if (argc != 2) {
fprintf(stderr, "usage: %s quantity\n", argv[0]);
return 1;
}
v = strtoull(argv[1], NULL, 0);
if (errno == EINVAL || errno == ERANGE) {
perror("strtoull");
return 1;
}
__asm__(
"xxbrd %0, %1\n"
:"=f"(o)
:"f"(*(double *)&v)
);
fprintf(stderr, "0x%lx\n", *(uint64_t *)&o);
return 0;
}
% gcc -o xxbrd xxbrd.c
% ./xxbrd 0x123456789abcdef
0xefcdab8967452301Re: Keeping POWER relevant in the open source world
#67Big Endian POWER isn't bug-for-bug compatible with buggy Javascript usage of typed arrays that assumes little endianness, and thus browsers/nodejs/deno on POWER will be exposed to bugs that don't affect little endian x86-64/ARM. After so many years of endianness bugs in C/C++ code, it's perplexing that the web standards committee voted to put typed arrays in Javascript in such a way that exposes platform byte order t…
Spoiler alert: it does (typing this in Firefox 96 on a little-endian POWER9). In TenFourFox, which ran exclusively big, we had code to byteswap typed arrays to make them look little-endian to scripts. This partially worked (enough for many `asm.js` scripts to run).
Re: Keeping POWER relevant in the open source world
#68Can someone who's using a PowerPC workstation for day-to-day tasks tell where its better than x86_64 or ARM?
Re: Keeping POWER relevant in the open source world
#69IBM has had this argument internally for eons. When i was there, two decades ago , people were making presentations internally saying the same thing - "without affordable volume machines that random people can buy and use to develop, this ecosystem will fail" Then, like now, there were even organizations/companies people thought might eventually take care of doing this that weren't IBM (Spoiler alert: They didn't) Gi…
This is starting to feel a lot like the DEC Alpha, at least from the perspective of the 3rd party motherboards. The ubiquity of x86 and ARM does not leave much room for the Power architecture in the general market.
Or is it the Power architecture who is not bringing much on the table for the price? (except radiation hardened chips, where money is not important)
Re: Keeping POWER relevant in the open source world
#70Earlier quoted context omitted.
The IRC channel was #talos-workstation on FreeNet, now on Libera.Chat. Do you know of some minimal example of calling VSX instructions from C? Ideally just one .c file and one Makefile or README with the exact GCC command to compile it, plus a pointer to documentation describing each instruction. I’ve seen assembler inserted into C source code with GCC, but I’ve never done it and I assume there are some non-obvious d…
I don't know what you want of the VSX, but if you want vectorized code, what do you expect to gain over letting the compiler do it on your C? If you want an example, there's the kernels in OpnBLAS and FFTW (and BLIS, but that seems to be broken on POWER9). There's an IBM web page somewhere with three(?) alternatives for using VSX, one of which is just using SSE intrinsics -- I don't know how well that works -- and an…
What I’d like to do is a quick proof-of-concept to see whether whatever instructions are available in my CPU can be leveraged for UTF-8 en-/decoding.
For instance, does it work any better than my C implementation? https://github.com/Sentido-Labs/cedro/blob/master/src/cedro....
Maybe the compiler already compiles that to an optimal SIMD version, I don’t know. That’s what I would like to find out. And if the VSX instructions are not a good fit for this task, which instructions would be needed? Can I come up with a combination of logic gates that does that? Maybe not, there might be no way of implementing any significant part of the algorithm without branches or look up tables.
The thing is that I need to start somewhere, and for that classichasclass’ example is exactly what I need.