Related articles |
---|
Cache size restrictions obsolete for unrolling? linuxkaffee_@_gmx.net (Stephan Ceram) (2009-01-07) |
Re: Cache size restrictions obsolete for unrolling? harold.aptroot@gmail.com (Harold Aptroot) (2009-01-09) |
Re: Cache size restrictions obsolete for unrolling? gneuner2@comcast.net (George Neuner) (2009-01-10) |
Re: Cache size restrictions obsolete for unrolling? linuxkaffee_@_gmx.net (Stephan Ceram) (2009-01-10) |
Re: Cache size restrictions obsolete for unrolling? jgd@cix.compulink.co.uk (2009-01-10) |
Re: Cache size restrictions obsolete for unrolling? harold.aptroot@gmail.com (Harold Aptroot) (2009-01-10) |
From: | Stephan Ceram <linuxkaffee_@_gmx.net> |
Newsgroups: | comp.compilers |
Date: | 10 Jan 2009 12:58:36 GMT |
Organization: | Compilers Central |
References: | 09-01-010 09-01-011 |
Keywords: | architecture, DSP |
Posted-Date: | 10 Jan 2009 10:40:44 EST |
> I have a strong feeling that it all depends very much on the platform
> you're targeting. And maybe also on how much memory the loop itself
> accesses as data, that wouldn't put any more pressure on the code
> cache obviously, but if the code does not fit in the cache then the
> real data and the code will both be fighting for the same resources
> (secondary cache, main memory). I haven't tested it at all, but it
> could matter, right?
Yes, this seems reasonable for systems with separate data caches and
even more when both data and code are in the same cache. However, in
my system there is no data cache and all data is placed in a fast
memory close to the processor called scratch pad memory. So, what do
you think when data is not competing with the code for the memory
system? Can I-cache misses be neglected at the cost of more aggressive
optimization?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.