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

Re: [f-cpu] Re: Navier-Stokes



Hi again,

On Thu, 18 Apr 2002, Yann Guidon wrote:
>hello,
>
>Juergen Goeritz wrote:
>> Ji YG,
>> 
>> are you also thinking about several caching strategies
>> for f-cpu? I can think of LRU data cache as not being
>> always the best strategy when computing big arrays, e.g.
>> big array mult. What's your opinion, could there also be
>> a PCL (partially cache lock) or a ULA (update last again)
>> or a UR (update randomly) strategy?
>
>i don't know why you called this cache-related post "Navier-Stokes",
>unless you have an idea ;-)

:-)
just some control change for heavy data reuse on large scale
where normal LRU strategy always results in miss.

>FC0 controls the L1 cache and uses 2 means to control the data locality :
> - L1 works with LRU or whatever strategy the user implements.
>   Personally i have better confidence in LRU because it's more
>   predictive than others.

But if I want to use a switchable strategy I need some means
to control this beast, don't I? Are there any registers where
I could add those control bits or do I have to make a separate
set?
 
> - cache hinting flags : the load/store instructions have a flag
>   that indicates whether the accessed line can be stored in L1
>   or directly flushed outside of FC0. So if you know that you won't
>   reuse this data, this bypasses the L1 "buffer" (because it acts
>   as a huge FIFO for the write back).

From this I understand that the load/store opcodes each have
a flag telling the cache what to do with the data, i.e. keep
or forget immediately after use.

>Together and with some adaptative algorithms, this is enough AFAIK.
>Adaptative strip-mining is an efficient way to process large data sets
>at the speed of the L1. I think that multi-level strip-mining is also
>possible, though a bit more complex, but if i think what you think correctly,
>this will do the trick.

Yes, this would do the trick. It's still open though how the
high level language developer (f,c,c++) could use/influence
this option manually.

readU2
JG
>readU,
>WHYGEE


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/