[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ATLAS
- To: R Clint Whaley <rwhaley@cs.utk.edu>
- Subject: Re: ATLAS
- From: Camm Maguire <camm@enhanced.com>
- Date: 07 Jul 2000 19:03:56 -0400
- Cc: atlas-comm@cs.utk.edu
- In-Reply-To: R Clint Whaley's message of "Fri, 7 Jul 2000 15:46:19 -0400 (EDT)"
- References: <200007071946.PAA02468@nala.cs.utk.edu>
Hello again!
R Clint Whaley <rwhaley@cs.utk.edu> writes:
> Camm,
>
> I don't know what specific requirements SSE forces on you, but the read/write
> pattern is much better for DDOT-based codes than DAXPY, because DAXPY
> does additional writes, whereas DDOT does additional reads, which are
> cheaper than writes . . .
>
> Cheers,
> Clint
>
You are of course right here, and I think, contrary to my earlier
guess, the complex case shows this to be the case even more. But I'm
a bit confused:
sgemvT prefetcht0 208 MFLOPS stable
sgemvT prefetchnta 238 MFLOPS stable
sgemvN prefetcht0 217 MFLOPS fluctuates a bit
sgemvN prefetchnta 242 MFLOPS fluctuates a bit
cgemvT prefetcht0 370 MFLOPS stable
cgemvT prefetchnta 383 MFLOPS stable
cgemvN prefetcht0 330 MFLOPS stable
cgemvN prefetchnta 250 MFLOPS fluctuates a lot
What appears to be going on here is that the extra writes in the N
case pollute the L1 cache in an erratic fashion. Apparently the nta
doesn't guarantee that the data is in all levels of cache, making
this disruption more evident. The single precision appears to be
entirely ram bandwidth limited, but then why does the axpy in the N
case do *better*? At least this seems to indicate that the complex N
case could \profit from a ddot implementation, no?
Take care,
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Follow-Ups:
- Re: ATLAS
- From: Camm Maguire <camm@enhanced.com>