This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6748: Optimization of Complex

Part Number: TMS320C6748


code we use has got re/img saved in an array in order to use for complex values, and i have all the related functionalities, written in c, for conj, complex multiplication as suggested in the previous post i have linked to.

but there is a suggestion to go for complex values in my team, can someone advise the side effects it would along bring with.

The complex type uses lesser memory? or does it use more, than allocating re/im in an array ?

I could see some positives it has, it makes the code more readable, and it also comes with the added conj, complex multiplication lib functions. 

but, is it a worthy switch? considering the memory and optimization, as both of them are critical in my project.

  • Hello!

    I believe both approaches are exactly same memory-wise if you use same precision/representation.

    I agree that code written with complex math is more readable comparing to in-house constructs. And this benefit is really worth consideration.

  • Hi, 

    Thanks for your response, but timing wise and optimization, would it yield the same result?

    The no of cycles it takes, do you have any suggestions or links that you can refer me to?

     obviously, i have taken the no of cycles for the original implementation, but going to complex.h, is a complete restructuring, 

    after we update everything, if it gonna hit us with the timing, it would be wasted few months on implementation.

    hence would like to know, if you know about the timings from your previous experience?

  • Hi again,
    Per compiler doc, complex data types are stored as arrays of re/im values, that is array of complex numbers will have their re/im parts stored interleaved. Thus, from memory point of view there is exactly same storage requirement.
    As to performance, I have no practical experience with complex.h, so please treat my contribution as guess.
    As I see, complex.h provides floating complex types, and as your DSP has no instructions to accelerate floating operations, I expect as complex types, so handcrafted code would have exactly same performance.
    However, if you opt for fixed point and proceed with complex data as int16-by-int16, there is a room for SIMD instructions optimizations like CMPY, CMPYR instructions.
  • Thanks for your response, 

    no, we have to use float, for precision sake, so wont be going down the line of int16.

  • Then it matters, how did you code your in-house complex routines.
  • C674x is a floating and fixed point DSP so the DSP does have floating point compute capability. The C99 standard requires that a complex number be represented as a struct containing one array of two  elements of the corresponding real type. Element 0 is the real component, and element 1 is the imaginary. component.

    The Complex types are defined as shown in here in the compiler documentation:

    IF you use floating point complex, the memory usage will be same. There is no need to use integer data types as C674x does provide good performance with single precision float values. 

    Other than readability, the advantage is that compiler can now read both read and imaginary data in a single instructions by doing a 4 byte load and the compiiler provides lot of helper functions. The long term advantage could also be with use of the same code on C66x DSP will take advatage of complex instructions native added to the C66x architecture.

    Regards,

    Rahul