|[9 earlier articles]|
|Re: Loop jamming!? email@example.com (1997-07-28)|
|Re: Loop jamming!? firstname.lastname@example.org (Steve Simmons) (1997-07-29)|
|Re: Loop jamming!? email@example.com (Stanley Chow) (1997-07-31)|
|Re: Loop jamming!? firstname.lastname@example.org (Jan Vorbrueggen) (1997-07-31)|
|Re: Loop jamming!? cliff.click@Eng.Sun.COM (cliffc) (1997-08-07)|
|Re: Loop jamming!? email@example.com (Mike Kent) (1997-08-07)|
|Re: Loop jamming!? firstname.lastname@example.org (Stanley Chow) (1997-08-09)|
|From:||"Stanley Chow" <email@example.com>|
|Date:||9 Aug 1997 20:14:43 -0400|
|Organization:||Bell-Northern Research Ltd.|
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.
>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; firstname.lastname@example.org, (613) 763-2831
Nortel/BNR, PO Box 3511 Station C, Ottawa, Ontario
Return to the
Search the comp.compilers archives again.