optimising pipelined loop

is this an issue because I am using floats? I changed to signed int's to see what happened and the loop carried dependency bound changed from 9 to 0 and it started using LDDW and STDW.

Graham,

It might help us to know which device this is targeted for.

SIvaraj picked up on the fact that your data types are floats. There may be other interesting information missing from your source snippet, such as array alignment.

As you should find from the documents Sivaraj recommended, you can use intrinsics like _amem8() to force wider reads when you know the alignment and locations will work out for you. The compiler might need more information, such as _nassert() to help it understand alignments.

Regards,
RandyP

Randy,

the device is the C6748.

I have tried using _nassert(((int)&array_name % 8) == 0) with no change in the timings, I believe arrays are aligned to 64 bit addresses on this device.

I will look into _amem8() and read the documentation that Slvaraj pointed to, hopefully that will help.

Graham

This is all confusing. For starters, why is equal sign drawn between LDDW and optimal performance? For example if algorithm works best by isolating data and A and B halves of register bank, then it might be more efficient to load data directly to A and B and avoid cross-references. I'm not saying that this is such case, only that lack of LDDW is not necessarily sign of bad performance. What is critical for performance is iteration interval observed after SPLOOP[D] instruction. It's 9 in presented snippet. And the question should be if this is optimal, for this case that is (there is no universal rule to calculate one, it all depends). Because if it's optimal, then there is nothing one can do, with or without LDDW. Well, this holds absolutely true for long loops, as for short ones there might be ways to cut corners... Again, not saying that this is such case. In other words it's hard to tell if 9 is right in this case, but *if* loop was long, then given amount of required resources 2 would be optimal if loop wasn't unrolled. Latter means that optimal coefficient would have to be multiplied by unroll factor if loop is unrolled, e.g. it would be 4 for loop unrolled twice.

Secondly, story doesn't seem to match. It's asserted that loop is executed in 828 cycles, but disassembler listing suggests that it takes ~40 (assuming that it's from actually i<6). Even if data is not in cache, it still can't possibly go up to 800. It sounds more like unoptimized code was measured, not disassembled one. Or something else was measured, not loop in question...

Hi Andy,

Thanks for the reply, I draw a link between LDDW and optimal performance from something that was said in an optimisation workshop video which I found somewhere on the ti wiki, not sure what the link was but it was done by Eric Wilbur and Scott Specker.

from the assembly code it looks like the A and B registers are not isolated as you have some cross adds and multiplies e.g.

           ADDSP   .L1X    B17,A3,A3         ; |353| (P) <0,13>  ^ 

||         MPYSP   .M2X    B19,A4,B4         ; |359| (P) <0,13> 

for measuring the loop time I used the following code, if I build the code as un-optimised I get approximately 4860 CPU cycles :(

start_time = _itoll(TSCH, TSCL);


#pragma MUST_ITERATE(6,6,6);
#pragma UNROLL(2);
for(i = 0; i < 6; i++)
{
	temp[0] += (ten_HZ_high_pass[i] * last_hp_ch1[i]);
	temp[1] += (ten_HZ_high_pass[i] * last_hp_ch2[i]);
	temp[2] += (ten_HZ_high_pass[i] * last_hp_ch3[i]);
	temp[3] += (ten_HZ_high_pass[i] * last_hp_ch4[i]);
}

end_time = _itoll(TSCH, TSCL);

cycle_count[cycle_index] = end_time - start_time - overhead;

cycle_index++;

if(cycle_index == 100)
{
	cycle_index = 0;
}

RandyP said:

_nassert(((int)&array_name % 8) == 0)

This is pseudo code since there is nothing named array_name in your code snippet. If the meaning is correct, then the '&' symbol is incorrect here and will not tell the compiler what you want it to know. As you suggest, the alignment may be 64-bit already, but it never hurts to tell the compiler true information.

Hi Randy, the following was just to avoid re-writing the same code again with all 6 of the arrays used in the loop, I should have made it clear that I was just being lazy and substituting array_name for temp, ten_HZ_high_pass, last_hp_ch1, last_hp_ch2, last_hp_ch3 and last_hp_ch4.

Regards,

Graham  

Randy,

You can't tell me how I feel :-) I mean if I say I'm confused, then you can't tell me that I'm not. Well, what exactly I am confused about can also be matter of confusion. Which seems to be the case. You seem to imply that I'm not at all confused about processor inner workings. But this is correct, I'm not, nor have I ever said that I am confused about that. It's other things, namely a) equality sign between LDDW and performance, and b) fact that pieces of the story don't seem to match each other. As for a). It's actually not original question that is confusing, but rather the fact that TI didn't draw OP's attentions to other vital factor, such as SPLOOP iteration interval. Note that I never said that LDDW doesn't matter for performance, only that it's not the only factor. And I implied that under circumstances maybe it's not most important one. Indeed, if interval chosen by compiler is 9, when optimal should be 2*unroll factor, then one should first ask what prevents compiler from using lower interval... [Or show that generated code delivers performance not much worse than 2*iterations+epilogue.]

Graham,

As for A and B not being isolated in your specific case. I did write "I'm not saying that this is such case." I mentioned isolation to make more general point, the above one, that one should probably refocus question on iteration interval. Not to mention that it might turn out that once you manage to convince compiler to use lower interval, it might start isolating data in A and B. Point is that there might be questions that needs to be answered first, before other questions become meaningful to pose, at least in my opinion.

As for cycles counter. Looking at cycles counter for non-optimized code makes virtually no sense. Question is If you can actually confirm that originally mentioned 800 cycles are in fact for optimized code presented in disassembler window, so that you can actually see that TSC is accessed right before loop, as well as after, we see only latter. You have to recognize that compiler doesn't have to keep exact order of expressions as they appear in C source code, and can reorder operations so that something else is measured. If you can actually confirm all this, then key question would be how come the count is so high. As already mentioned I personally have hard time imagining the reason, but TI might have an idea... Now you also say that you collect multiple data point in an array, but you mention single result. Which one is it? Maximum? Minimum? Average?

In either case keep in mind that you can't count on community member such as myself to actually solve your problems. I might be able to help, or might not...

Graham Long said:

RandyP

_nassert(((int)&array_name % 8) == 0)

This is pseudo code since there is nothing named array_name in your code snippet. If the meaning is correct, then the '&' symbol is incorrect here and will not tell the compiler what you want it to know. As you suggest, the alignment may be 64-bit already, but it never hurts to tell the compiler true information.

Hi Randy, the following was just to avoid re-writing the same code again with all 6 of the arrays used in the loop, I should have made it clear that I was just being lazy and substituting array_name for temp, ten_HZ_high_pass, last_hp_ch1, last_hp_ch2, last_hp_ch3 and last_hp_ch4.

In case you missed it, Randy also pointed out that you have an extraneous & in that _nassert.

Also judging from your output you don't appear to have an aliasing problem, but restrict is another important piece of information for the compiler to optimize.

So your code might look like:

#include <assert.h>

void func(float const * restrict ten_HZ_high_pass, float const * restrict last_hp_ch1, float const * restrict last_hp_ch2, float const * restrict last_hp_ch3, float const * restrict last_hp_ch4, float * restrict temp)
{
    _nassert((int) ten_HZ_high_pass % 8 == 0);
    _nassert((int) last_hp_ch1 % 8 == 0);
    _nassert((int) last_hp_ch2 % 8 == 0);
    _nassert((int) last_hp_ch3 % 8 == 0);
    _nassert((int) last_hp_ch4 % 8 == 0);
    _nassert((int) temp % 8 == 0);
    
    int i;
    
    #pragma MUST_ITERATE(6, 6, 6)
    for(i = 0; i < 6; i++)
    {
        temp[0] += (ten_HZ_high_pass[i] * last_hp_ch1[i]);
        temp[1] += (ten_HZ_high_pass[i] * last_hp_ch2[i]);
        temp[2] += (ten_HZ_high_pass[i] * last_hp_ch3[i]);
        temp[3] += (ten_HZ_high_pass[i] * last_hp_ch4[i]);
    }  
}

Experiment with UNROLL as you like.