Re: Loop jamming!?

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
--

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