Live data from Hacker News

Keeping POWER relevant in the open source world

peter.czanik.hu

71–75 of 75 posts

Re: Keeping POWER relevant in the open source world

#71
post #59

Earlier quoted context omitted.

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 instru…

Just keep in mind that the FPRs and vector registers are now aliased together (in VMX-only CPUs this wasn't necessarily the case). What is particularly stupid about my example is that it may have to spill to memory to move the uint64_t (a GPR) into the VSX register (an FPR) and then move it back because PowerPC famously had no direct GPR-FPR moves for quite a while. Since I didn't specify -mcpu=power8 (or higher), gcc doesn't issue the new instructions and I'm not sure it would know how to.

A better way would be to explicitly use the newer mtvsrd (mtfprd) and mfvsrd (mffprd) instructions and avoid the spill. So here's a revision 2.

  #include 
  #include 
  #include 
  #include 
 
  int main(int argc, char **argv) {
        uint64_t v = 0;
 
        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__(
                "mtfprd %1, %0\n"
                "xxbrd %1, %1\n"
                "mffprd %1, %0\n"
                :"=r"(v)
                :"r"(v)
        );
        fprintf(stdout, "0x%lx\n", v);
        return 0;
  }
If v is already in a register, then it can just stay there.

Re: Keeping POWER relevant in the open source world

#72
post #64

Earlier quoted context omitted.

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).

The problem about Ubuntu dropping POWER8 support isn't that hardware owners won't find another distro to run.

The problem is that home lab owners who develop on their second-hand POWER8 hardware can no longer have the same software environment as the POWER9 systems running latest Ubuntu that they deploy to. And Ubuntu is very popular in the Cloud.

Re: Keeping POWER relevant in the open source world

#73
post #13

At the other end of the scale, if anyone wants to play you can run a little openpower CPU on an FPGA with completely open source. https://github.com/antonblanchard/microwatt It's capable of running Linux, some example docs are https://shenki.github.io/boot-linux-on-microwatt/ The toolchain consists of "apt install gcc-powerpc64le-linux-gnu" on Debian, no funny downloads. And if you want to target a Lattice ECP5 board…

We've now got a walkthrough up for getting Microwatt going on an OrangeCrab ECP5 board. https://codeconstruct.com.au/docs/microwatt-orangecrab/

Re: Keeping POWER relevant in the open source world

#74
post #32

Earlier quoted context omitted.

PASemi was stopped by an acqui-hire. I don't like counterfactuals, but that was a huge transfer of expertise from Power to ARM

I mean, this is true, but it doesn't really change a lot of what i said. It was always something :) If your ecosystem is stopped in its tracks because someone acquired a small company, it is not a particularly robust ecosystem. From what i was told (and i was very young and inexperienced when i worked at IBM, so take it with a grain of salt), the baseline issue was always the same on the IBM side - the chip groups co…

[deleted]

Re: Keeping POWER relevant in the open source world

#75

The most compelling argument for POWER was to make sure there is competition to amd64/x86 and we do not develop a monoculture. I think arm and risc-v have filled that hole nicely and taken over for POWER. Without readily available and affordable hardware I do not see much of a future for POWER in open-source. It seems entirely dependent on IBM to keep it going unless this changes.

I'm not sure I agree about RISC-V. ARM is now indisputably in the same performance ballpark as x86_64 (M1 most obviously but there are others), as is Power, but RISC-V has a ways to go before it can compete on the same turf. It hasn't even really competed with ARM in embedded, despite its advantages there (though it has all but killed the zombie corpse of neo-MIPS). I do agree that without other processor makers, how…

I did not mean to imply that I thought RISC-V was a challenger to x86 and ARM right now. Just that it is accessible to those that want it which can let them make sure software runs on it. Even that, I do not think is really true yet but it seems like it is the direction things are heading.

With POWER, I just do not see the motivation, outside of IBM, for doing any work with it anymore.

Post reply on HN