Related articles |
---|
[9 earlier articles] |
Re: Loop jamming!? genew@netcom.com (1997-07-28) |
Re: Loop jamming!? simmons@nortel.ca (Steve Simmons) (1997-07-29) |
Re: Loop jamming!? schow@nortel.ca (Stanley Chow) (1997-07-31) |
Re: Loop jamming!? jan@fsnif.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) (1997-07-31) |
Re: Loop jamming!? cliff.click@Eng.Sun.COM (cliffc) (1997-08-07) |
Re: Loop jamming!? mkent@acm.org (Mike Kent) (1997-08-07) |
Re: Loop jamming!? schow@nortel.ca (Stanley Chow) (1997-08-09) |
From: | "Stanley Chow" <schow@nortel.ca> |
Newsgroups: | comp.compilers |
Date: | 9 Aug 1997 20:14:43 -0400 |
Organization: | Bell-Northern Research Ltd. |
References: | 97-07-130 97-08-010 |
Keywords: | optimize |
Stanley Chow wrote:
>> Loop jamming will result in a loop that is, in general, slower than
>> each of the original loops. The time penalty will depend on many
>> factors (including cache size, serial dependency, multiple ALU) and
>> in the extreme case, the time penalty can be zero wrt the slower loop.
<cliff.click@Eng.Sun.COM> wrote:
>Actually, it's pretty easy for the jammed loop to run faster than the
>slowest loop, if the cache locality is right.
Then the compiler was not doing a good job for the slow loop - it should
have managed the cache better. In the extreme :-), it could invent
the "extra" loop and use loop jamming to speed up the slow loop.
--
Stanley Chow; schow@nortel.ca, (613) 763-2831
Nortel/BNR, PO Box 3511 Station C, Ottawa, Ontario
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.