Re: [Gcl-devel] Floating-point performance of GCL? Bug?

[Camm Maguire]

Greetings!

Nicolas Neuss <address@hidden> writes:

> > DDOT-long: 205.83 MFLOPS
> > DDOT-short: 577.80 MFLOPS
> 
> These look acceptable, although the C version gives better results:
> 
> gcc -O3 mflop.c; a.out
> ddot-long 272.34 MFLOPS
> ddot-short 917.73 MFLOPS
> daxpy-long 163.06 MFLOPS
> daxpy-short 1136.23 MFLOPS
> 
> [Aside: Interestingly, those numbers can be surpassed (for short vectors,
> i.e. no cache issues).  Performance of a matrix-matrix-multiply of the
> ATLAS library gives a peak performance of about 3 GFLOPS on my machine!  I
> guess this requires Intel's compiler, though.  Can GCL use other compilers
> than GCC?]

Atlas does not require non-gcc.  None such is available on Debian, and
numerous packages in this distro make use of atlas.  The L1 blas
operations you report above cannot be compared with L3 routines -- the
former will basically be bound by the memory bandwidth for reasonable
cases at best.  Your 'short' numbers are likely highly misleading, as
they presuppose finding the entire vector in some level of cache,
which is very likely not the case on a general call.

> 
> > DAXPY-long: 10.40 MFLOPS
> > DAXPY-short: 11.98 MFLOPS
> 
> These do not.  Basic question: can GCL handle unboxed floating point
> numbers and uniform arrays of those?  I didn't find anything in the
> documentation when I looked last time, and this would probably be the
> decisive step.

See separate post.

Take care,

> 
> Thanks, Nicolas.
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah