Re: multi-CPU optimization inside a distribution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 30, 2016 at 5:01 PM, Jan Kratochvil
<jan.kratochvil@xxxxxxxxxx> wrote:
> On Thu, 30 Jun 2016 16:13:59 +0200, Josh Boyer wrote:
>> On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> wrote:
>> > But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>> >>=Power8 hardware does use ppc64le which is already Power8 optimized.
>> > So isn't this problem (somehow temporarily) solved for now?
>>
>> POWER8 can run in either endian mode.  So no, the problem is not solved.
>
> End-users do not even know what is endianity.  And all application developers
> need to write software BE/LE-independently (such as using ntohl()/htonl()
> etc.) so they also do not care whether the host is BE or LE.  Only <1% of
> developers for high performance core or very low-end libraries (like glibc or
> glib) need to care about BE/LE.
>
> So why to run Power8 in BE?  Power is switching to LE AFAIK which makes it
> also better compatible with buggy software ignoring BE/LE difference which is
> (as all the software) targeting primarily x86* (=LE).

Data conversion is expensive, slow and problematic so once it's in one
format it tends to stay that way. There's also legacy/proprietary
tools that run as big endian on the Power64 platform. For a new
deployment there's no reason not to do it as LE from the outset, and
migration from other LE platforms makes sense but if you're in a BE
world (AIX, Solaris, Z-series and friends) it makes sense to run in
BE.

There are some applications where the data comes in in BE format and
it's costly to deal with that in real time, especially in high
throughput scenarios.

>> Realistically, it isn't about either specifically.  Each iteration of
>> POWER tends to require tuning specifically for that generation if you
>> want to get the most performance out of your software.
>
> Latest CPU features get utilized mostly only in inner loops of high
> performance code which should use IFUNC.  So building the whole distro for the
> latest CPU brings only incompatibility with no real performance advantage.

We're looking at IFUNC as one option, Function multi-versioning in GCC
6 [1] is presumably also another option, although wouldn't be useful
for already released enterprise releases, although obviously
irrelevant for the Fedora conversation.

> At least this is my expectation, the OP misses any real benchmark numbers
> whether the distro build for the latest CPU generation is worth it.
> IIRC for x86* it was not worth it.


[1] https://lwn.net/Articles/691932/
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux