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

[ Thread Index | Date Index | More Archives ]

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>
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;
On Fri, Jan 17, 2020 at 8:45 AM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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:

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


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:
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  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:
   Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
   Trippstadter Straße 122, D-67663 Kaiserslautern, Germany

   Prof. Dr. Antonio Krüger (Vorsitzender)
   Dr. Walter Olthoff

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


Mail converted by MHonArc 2.6.19+