[RFC] Quad-float support, round 4

[FX]

I've played a bit with the timing file attached. Compile with:

gcc -x c -E timing.pf90 -o timing.f90 && gfortran -ffree-line-length-none -fno-whole-file timing.f90 -lquad -O2 && ./a.out

On x86_64-darwin, I get:

 Time for   sqrt with kind  4 = 0.2322E-08
 Time for   sqrt with kind  8 = 0.2316E-08
 Time for   sqrt with kind 10 = 0.2319E-08
 Time for   sqrt with kind 16 = 0.4536E-06

 Time for    sin with kind  4 = 0.2275E-07
 Time for    sin with kind  8 = 0.2456E-07
 Time for    sin with kind 10 = 0.3934E-07
 Time for    sin with kind 16 = 0.2553E-05

 Time for    cos with kind  4 = 0.2426E-07
 Time for    cos with kind  8 = 0.2758E-07
 Time for    cos with kind 10 = 0.4513E-07
 Time for    cos with kind 16 = 0.3874E-05

 Time for  asinh with kind  4 = 0.1616E-07
 Time for  asinh with kind  8 = 0.8281E-07
 Time for  asinh with kind 10 = 0.8778E-07
 Time for  asinh with kind 16 = 0.9619E-05

 Time for   erfc with kind  4 = 0.7840E-07
 Time for   erfc with kind  8 = 0.6666E-07
 Time for   erfc with kind 10 = 0.1921E-06
 Time for   erfc with kind 16 = 0.5030E-05

Which means, comparing __float128 to double: SQRT slowed by 200, SIN slowed by 100, COS slowed by 140, ASINH slowed by 100, ERFC slowed by 75.


On the same target, g95 does not have a generic ASINH, it doesn't accept real(kind=10) arguments to ERFC, and has no library implementation of SIN and COS for real(kind=16)... but sqrt gives:

 Time for   sqrt with kind  4 = 0.3361E-08
 Time for   sqrt with kind  8 = 0.3090E-08
 Time for   sqrt with kind 10 = 0.5876E-08
 Time for   sqrt with kind 16 = 0.2526E-05

(__float128 is 820 times slower than double).



On x86_64-linux, I get:

 Time for   sqrt with kind  4 = 0.2550E-08
 Time for   sqrt with kind  8 = 0.2515E-08
 Time for   sqrt with kind 10 = 0.2515E-08
 Time for   sqrt with kind 16 = 0.4783E-06

 Time for    sin with kind  4 = 0.2410E-07
 Time for    sin with kind  8 = 0.2610E-07
 Time for    sin with kind 10 = 0.4639E-07
 Time for    sin with kind 16 = 0.2796E-05

 Time for    cos with kind  4 = 0.2690E-07
 Time for    cos with kind  8 = 0.2640E-07
 Time for    cos with kind 10 = 0.4889E-07
 Time for    cos with kind 16 = 0.4119E-05

 Time for  asinh with kind  4 = 0.7079E-07
 Time for  asinh with kind  8 = 0.8759E-07
 Time for  asinh with kind 10 = 0.1129E-06
 Time for  asinh with kind 16 = 0.1054E-04

 Time for   erfc with kind  4 = 0.3210E-07
 Time for   erfc with kind  8 = 0.3499E-07
 Time for   erfc with kind 10 = 0.4669E-07
 Time for   erfc with kind 16 = 0.5482E-05

Which means, comparing __float128 to double: SQRT slowed by 200, SIN slowed by 100, COS slowed by 150, ASINH slowed by 120, ERFC slowed by 150.
It's pretty much the same as for darwin, except ERFC. But then, those are two different libm's (Darwin and glibc).


I also tried with Intel on x86_64-linux, and had to hide the hide_me functions in another file (and specify -no-ip) to prevent it from optimizing *everything* away... In the end, compiling with -O, I get:

 Time for   sqrt with kind  4 = 0.2555E-08
 Time for   sqrt with kind  8 = 0.2510E-08
 Time for   sqrt with kind 16 = 0.4077E-06
 
 Time for    sin with kind  4 = 0.2070E-07
 Time for    sin with kind  8 = 0.2600E-07
 Time for    sin with kind 16 = 0.1635E-06
 
 Time for    cos with kind  4 = 0.2050E-07
 Time for    cos with kind  8 = 0.2420E-07
 Time for    cos with kind 16 = 0.2210E-06
 
 Time for  asinh with kind  4 = 0.2590E-07
 Time for  asinh with kind  8 = 0.2340E-07
 Time for  asinh with kind 16 = 0.1715E-06
 
 Time for   erfc with kind  4 = 0.2550E-07
 Time for   erfc with kind  8 = 0.1831E-06
 Time for   erfc with kind 16 = 0.8189E-06
 
(Yeah, Intel compiler doesn't like real(kind=10)...)

Again, comparing __float128 to double:
SQRT is slower by 160, SIN is slower by only 6, COS by 10, ASINH by merely 10 and ERFC by 6 again. I'm actually amazed at how it does that!



Of course, this is very poor benchmarking, as the functions are sampled only in a quite limited range of input, but that only took 20 minutes to write, compile, and send this mail :)

Regards,
FX


PS: I should state that, unless someone comes forward with ready patches for libquad, I don't consider putting time into improving its runtime performance myself. I thought, however, that knowing at least roughly how well/bad it behaves is important to potential users.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: timing.pf90
Type: application/octet-stream
Size: 2155 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20100913/409d3bc5/attachment.obj>