Re: [eigen] RFC: making a deterministic and reproducable product codepath with Eigen

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Just to throw in my 2 cents (mostly in the context of linear algebra): I understand that some perceive a great benefit of having 100% reproducible and deterministic computations, but I don't think it is realistic or even particularly useful in a parallel or multi-threaded environment, unless you want to grossly sacrifice performance. In my practical experience, this idea often comes from a desire to get predictable outcomes of regressions tests written without proper knowledge of the mathematics of the problem, i.e. error analysis. I have found time and time again that looking up the correct error bound in the literature (or deriving it) and possibly adding a small fudge factor solves such problems in a way that might even yield useful insights. 

On Fri, Sep 9, 2016 at 2:15 AM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 08.09.2016 at 21:45, Peter wrote:
In case you are interested, there's e.g. HP's Dynamo project,
<http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html>,
which messes around with binaries. And for scalar products, it's
sufficient to change the order of evaluation,
to loose bit-wise accuracy, eg. the scalar product of ( 1, 1e-50, 1)
with ( 1, 1, -1 ) is a simple example.

Sure, I'm aware that IEEE math is non-associative ...

I'm just not sure how far the processors mess around.

By design they should only execute things out of order, if the instructions (or the generated micro-instructions) are independent.
Everything beyond that would be insane, IMO. I'm not a CPU expert, but I'm pretty sure a lot of people would have complaining about it, if CPUs would do that.

I agree, using a F77 BLAS should be sufficient. Although I still don't
understand what one learns from bypassing all optimizations.

If you have a BLAS implementation that does exactly the same on every target architecture, you should be fine as well, of course. I don't know what the status of F77->GPU compilers is.

If correctness is important one should switch to exact scalar product,
like in C-XSC,
which removes the dependence on the order of evaluation and just _has_
to provide the same result everywhere.

The original RFC was just on reproducibility not on exactness, I think.

BTW, exact scalar products could be an interesting extension to Eigen in
some future version,
opening the door to verified computing.

Sure, that would be interesting. I'm not sure how complicated this will be to integrate though. And it will certainly be significantly slower.



Christoph


--
  Dipl. Inf., Dipl. Math. Christoph Hertzberg

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Zentrale: +49 421 178 45-6611

  Besuchsadresse der Nebengeschäftsstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:    +49 421 178 45-4021
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  chtz@xxxxxxxxxxxxxxxxxxxxxxxx

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/