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

[Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx>]

I meant fmin, not minf :-)

On Fri, Jan 17, 2020 at 9:46 AM Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx> 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
   -------------------------------------------------------------