RE: [eigen] Use of vec_min/max on ppc

Thanks all for the information. It looks like that's correct, vec_min outputs whatever argument isn't NaN instead of just the first. I don't see a better vector approach than Eigen has right now then, ppc has a single instruction to implement that on scalars but not vectors...

Once again, thanks!

Best regards,

Everton Constantino

Software Developer

Application Libraries Optimization
Linux Technology Center, IBM Systems
e-mail: everton.constantino@xxxxxxx

----- Original message -----
From: Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx>
To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [eigen] Use of vec_min/max on ppc
Date: Fri, Jan 17, 2020 14:49

I meant fmin, not minf :-)

On Fri, Jan 17, 2020 at 9:46 AM Rasmus Munk Larsen <rmlarsen@xxxxxxxxxxx> wrote:

As Christoph points out, this refers to the semantic difference between std::min and minf (and similar for max*) in the presence of NaN arguments. As you can see in the bugs Christoph linked, we agree that it would be nice to have packet ops for the various behaviors (possibly chosen using a template argument), but currently Eigen follows the std::min semantics, which are equivalent to the ternary _expression_

template<class T>
const T& min(const T& a, const T& b)
{
return (b < a) ? b : a;
}

See https://en.cppreference.com/w/cpp/algorithm/min

On Fri, Jan 17, 2020 at 8:45 AM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi!

Which IEEE754 version are you referring to?

In IEEE754-1985, there was no min/max, then the 2008 draft suggested
introducing minNum/maxNum which propagate numbers, and the 2019 draft
suggests replacing those by
{min,max}imum{,Number,Magnitude,MagnitudeNumber} which either propagate
NaNs or numbers. (All to the best of my knowledge, please correct me, if
I'm wrong).

Eigen follows the `std::min`/`std::max` convention of propagating the
first argument, if one argument is NaN. SSE/AVX propagates the first,
which is why we change the order for those.
I'm really no expert on Altivec/PPC, so no idea if there is a more
efficient instruction consistent with `std::min/max`.

For reference: Here is the commit which introduced the lines you are
referring to:
https://gitlab.com/libeigen/eigen/commit/e91e314347c14774206307a91d1b427e49f9b3e2

Also, check these issues for further discussion on the topic:

https://gitlab.com/libeigen/eigen/issues/564
https://gitlab.com/libeigen/eigen/issues/1373
https://gitlab.com/libeigen/eigen/issues/1494

Cheers,
Christoph

On 17/01/2020 16.50, Everton Rufino Constantino1 wrote:
> Hi,
> looking at the implementation of pmin and pmax for Packet4f on
> Altivec/PacketMath.h I came across the following statement to justify not using
> VSX's intrinsics:
> "// NOTE: about 10% slower than vec_min, but consistent with std::min and SSE regarding NaN"
> I fail to understand the reasoning, afaik ppc and stdlib both are IEEE
> compatible right? Can somebody please clarify the statement? I think sometime in
> the past ppc had a non-IEEE mode that you could turn on or off but that's gone
> for a while now.
> Best regards,
> Everton Constantino
> <everton.constantino@xxxxxxx>
>

--
Dr.-Ing. Christoph Hertzberg

Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx

Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany

Geschäftsführung:
Prof. Dr. Antonio Krüger (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats:
Dr. Gabriël Clemens
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------