[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Camm Maguire
Subject: Re: [Gcl-devel] Floating-point performance of GCL? Bug?
Date: 19 Jul 2004 18:36:16 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]