On Wed, 2017-09-06 at 10:31 -0400, Josh Boyer wrote:
On Tue, Sep 5, 2017 at 10:20 PM, Steven Munroe
<munroesj(a)linux.vnet.ibm.com> wrote:
> On Tue, 2017-09-05 at 15:35 -0500, Carlos O'Donell wrote:
>> On 09/05/2017 03:03 PM, Steven Munroe wrote:
>> > On Fri, 2017-09-01 at 09:24 -0500, Carlos O'Donell wrote:
>> >> On 09/01/2017 09:03 AM, Steven Munroe wrote:
>> >>> If you want to cut back you can't try 970 as base, plus power6
and
>> >>> power7 -mtune power8
>> >>
>> >> s/can't/can/g?
>> >>
>> >> I assume you're suggestion:
>> >>
>> >> * 970 base multilib.
>> >> * power6 multilib.
>> >> * power7 multilib with power8 tunning.
>> >>
>> >> Which implies:
>> >>
>> >> * Drop the power8 multilib.
>> >>
>> >> That drops only 1 multilib.
>> >>
>> >> Do we need power6 or can we fold that into the 970?
>> >> e.g.
>> >>
>> >> * 970 base multilib with power6 tuning.
>> >> * power7 multilib with power8 tuning.
>> >>
>> >>
>> >
>> > That seems simple but is ignoring the major features added with each ISA
>> > level.
>> >
>> > So between 970 and power8 we added DFP, VSX, VSX Scalar Float, and HTM.
>> > This is over 300 new instructions including additions to existing ISA
>> > categories, like Fixed Point 64-bit, Floating Point, and VMX (Altivec)
>> > beyond what was in 970.
>> >
>> > So what you propose will mean Power6 would be restricted to software
>> > emulation of DFP and the DFP hardware unused. And will not have the
>> > mutex lock hint and compare bytes optimization.
>> >
>> > Power7 will get both HW DFP and VSX (vector double and extended scalar
>> > double) but without Scalar extended Float. Also will leave the HTM and
>> > direct moves (GPR <-> VSR) optimization disabled.
>> >
>> > So if you holding on to your Apple G5 you may not know what your
>> > missing, but your P6 JS21 blade will be disappointing. And your P8 will
>> > run slow due to missing direct move support.
>>
>> The library, glibc, *may* be missing the use of some of those instructions
>> in the library and *iff* the compiler generated them as part of the
>> compilation of generic C code.
>>
>> The POWER7 multilib will still have POWER8 IFUNCs which make use of
>> all the POWER8 assembly implemented IFUNCs that IBM has contributed
>> upstream.
>>
>> How much of these features you quote are actually used by glibc when
>> compiled for that architecture?
>>
>> I expect user applications would make use of libdfp to access the
>> full power of POWER6 DFP, but glibc itself doesn't use DFP internally,
>> so I still don't see how the above suggested reduction makes things
>> really worse.
>>
>> We are only talking about limiting the glibc multilibs that we build.
>>
>> How about:
>>
>> * 970 with POWER6 tuning.
>> - Will not use DFP within glibc, but we have never used DFP in glibc.
>>
> Yes but customer do use DFP, Just not the customers you have talked to.
How many of those customers run Fedora? That is the context of this
conversation.
That is the problem with open source, customers don't have to tell you
what they are using (packagers or distro's). We only here when there is
a performance complaint or a bug.
I have talked to customers that are using DFP. They where usually banks
trying to fake decimal arithmetic using binary float, and have problems
as a result. They where happy to hear they we had real Decimal Floating
Point with fast implementation in hardware.
Once they had a solution, we never hear from them again. As is usual for
Open source.
So I don't remember any that where specific planning to us Fedora
(usually a enterprise distro) but that is NOT proof that none exist.
Also they can always use the IBM Advance Toolchain which always provides
multilib and libdfp.
It but is would better (easier for the customer) if it was just there.