Re: Loop jamming!?

"Stanley Chow" <schow@nortel.ca>
31 Jul 1997 00:33:25 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: Loop jamming!? cdg@nullstone.com (Christopher Glaeser) (1997-07-18)
Re: Loop jamming!? schow@nortel.ca (Stanley Chow) (1997-07-21)
Re: Loop jamming!? cdg@nullstone.com (Christopher Glaeser) (1997-07-22)
Re: Loop jamming!? n8tm@aol.com (1997-07-27)
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)
| List of all articles for this month |

From: "Stanley Chow" <schow@nortel.ca>
Newsgroups: comp.compilers
Date: 31 Jul 1997 00:33:25 -0400
Organization: Bell-Northern Research Ltd.
References: 97-07-089 97-07-102 97-07-108
Keywords: optimize, architecture

Christopher Glaeser <cdg@nullstone.com> wrote:
>> >> In the extreme case, the slower loop is not slowed down any more
>> >> by merging another loop with it.
>> >
>> >Not true. In the extreme case, performance can actually decrease. This
>> >can occur, for example, when the fusion of the loops cause cache
>> >conflicts that were not present when the loops are run separately.
>>
>> Of course, both cases can be true (but for different extreme cases).
>
>I understood "In the extreme case, the slower loop is not slowed down"
>to mean there are *no* programs that will slow as a result of loop
>jamming. I contend such programs *do* exist. These two assertions can
>not both be true. Either such programs exist, or they do not.


I took "extreme" to apply to the time penalty to the slow loop; as
opposed to applying to the set of programs. To paraphrase the original
statement:


    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.




--
Stanley Chow; schow@nortel.ca, (613) 763-2831
Nortel/BNR, PO Box 3511 Station C, Ottawa, Ontario
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.