On Tue, 16 Dec 2014 14:22:14 -0600
Michael J Wolf <mjwolf(a)us.ibm.com> wrote:
> > Subject:
> >
> > Re: Fedora 22
> >
> > Sent by:
> >
> > ppc-bounces(a)lists.fedoraproject.org
> >
> > >> Hi
> > >> We briefly discussed priorities for Fedora 22 and I had
> > >> taken an action item to start an email conversation about
> > >> this. So here is what I would like to see for Fedora 22.
> > >>
> > >> 1) Get the -mcpu and -mtune flags set properly for the LE
> > >> build. Should be -mcpu=power7 -mtune=power8
> > >
> > > done, all packages that honour the Fedora system wide compiler
> > > flags use them, if they don't it's a packaging bug
> > >
> > >> 2) Have a cloud image available
> > >> 3) For BE I would like another subarch. Same packages as the
current
> > >> one but tuned for P8.
> > >
> > > you mean in addition to ppc64p7? can't we just switch ppc64p7
> > > from -mcpu=power7 -mtune=power7 to -mcpu=power7 -mtune=power8?
> >
> > This makes sense to me as it then mirrors what we have in ppc64le
> > and it saves having more targets.
>
> The disadvantage of this would be to cut off users that have Power 7
systems
> and optimized code. So why would people want to optimize from
> Fedora 21
to
> Fedora 22. You would be taking a big step back in performance. I
> don't want to suggest keeping a subarch for each type of POWER
> system out
there. I
> was thinking of keeping two. So when the next POWER arch that
> comes out, the Power 7 subarch goes away and you would have Power 8
> and the new Power arch.
The above comment is not correct I was assuming -mcpu=power8 but your
comment states
-mcpu=power7 so yes that is reasonable and keeps things consistent
across BE and LE.
The only drawback here is that you would be leaving some performance
behind as you
would not be using all the new Power 8 instructions.
I think it (as not using P8 instructions) would be acceptable
compromise for a binary distribution. But it would be interesting to see
some numbers what the difference between the various combinations of
-mcpu and -mtune and used hardware is.
Also introducing a new subarch means updating (patching) our build and
release engineering tools starting with rpm itself.
Dan