Double precision

[MiguelTasende]

OK, I know asking is very easy, but maybe the problems I found may help for something.

Yes, double-precision is something that I think would be great to have for scientific computing and supercomputing.

My objective was using the Parallella as a cluster for HPC, and trying to find out the problems that I would have.

More or less, I could get around the memory and badwidth limitations, but when I had a relatively reasonable version of my program in single-precision, I decided to change to double precision (which is the standard for Linpack, if I'm not wrong). The loss of performance in that case was worse than the previous problems, and more difficult to "get around" by ingenious means...

I hope that is not impossible or too "cost-inefficient"... sorry if this has already been discussed (I searched for "double" here and didn't find a topic for this).

[jar]

Miguel,

There are no double precision instructions on the Epiphany III cores so the operations are performed in software which is very expensive as you found out. Your best bet is to selectively use double precision where it matters. Or you could use extended precision methods where it matters http://andrewthall.org/papers/df64_qf128.pdf which is somewhere between single and double precision.

That is also more costly than single precision, but perhaps less than full double precision in software.

The extended precision work was developed for GPUs during a time when they didn't have hardware support for double precision. It's analogous to the state of the Epiphany architecture today. There weren't enough people like you asking for it. With Nvidia and AMD GPUs, it was a design decision to add support during one hardware generation.

[MiguelTasende]

Thanks!
That paper looks really interesting.
I hope I'll have some time to read it and use it to improve the code.

[MiguelTasende]

I read the first part of the paper (with certain care...).
I think that the "df64_mult" algorithm is missing a little detail (an omission posibly).

I think it is throwing away the a.y * b.y term (which may be a good aproximation), but in case you're in fact multiplying two single-precision floats you should not use the algorithm (the result would be zero, if I am not wrong), and you should use normal f32 multiplication.

So, an extra "if" may be necessary to check that the high parts of the doubles are not both zero.
Am I correct? (well, that question is just in case you have read the article, have the ideas fresh, and want to confirm my suspicions...)

It is good to have the FMADD instruction on the Epiphany (will try to implement the algorithms in assembler... after I learn how to use it and compile it )

[jar]

I think the multiplication operation is analogous to the algebraic FOIL operation (a+b)*(c+d) where b and d are small. For example, 10001*20002 can be approximated with (10000 + 1)*(20000 + 2) = 10000*20000 + 1*20000 + 2*10000. The 1*2 term is dropped because it saves two operations for negligible benefit to precision.

[MiguelTasende]