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.

J784S4XEVM: TI C7000 Compiler Optimizations: No changes observed with changing optimization compiler flag.

Part Number: J784S4XEVM

I am testing a code's execution time with TI C 7000. The part of the code that I am benchmarking is MATLAB generated. What I observed is that given everything else is the same changing: 
--opt_level from off to 4 : did not accelerate the code execution
--opt_for_speed from 0 to 4: did not accelerate the code execution
--fp_mode from strict to relaxed: did not accelerate the code execution
after seeing this indifference in execution times I replaced the code block with a testing function given below: 

#define MATRIX_SIZE 1024

// Declare an external function to "consume" the matrix
// Prevents the compiler from optimizing everything away
#ifdef __cplusplus
extern "C" {
#endif
    void useMatrix(float mat[MATRIX_SIZE][MATRIX_SIZE])
    {
        volatile float sink = mat[0][0];
        (void)sink;
    }
#ifdef __cplusplus
}
#endif

static float matrix[MATRIX_SIZE][MATRIX_SIZE];


int32_t TestClass::Init()
{
    for (int i = 0; i < MATRIX_SIZE; i++) {
        for (int j = 0; j < MATRIX_SIZE; j++) {
            matrix[i][j] = (float)(i + j);
        }
    }

    InitFlag  = true;
}

void TestClass::TestOptimization()
{
    // i increasing, j decreasing (as requested)
    for (int i = MATRIX_SIZE - 1; i >= 0; i--) {
        for (int j = MATRIX_SIZE - 1; j >= 0; j--) {
            float val = matrix[i][j];

            // Some arithmetic to encourage optimization (FMA, pipelining, etc.)
            val = val * 1.2345f + 0.9876f;
            val = val * val - 0.4321f;

            matrix[i][j] = val;
        }
    }

    // Pass to external function so compiler can't eliminate it
    useMatrix(matrix);
}

and I measure the execution time of TestOptimization function. For compiler options, changing the --opt_level from off to 2 or 4 does not accelerate execution time. 
Why might this be? Could you provide some direction to which we can turn the optimization on and observe and acceleration in code execution? 

  • Hi Ekin,

    Could you please let us know which CGT version you are using?
    We will check whether the issue can be reproduced on our end using the provided test code and will keep you posted.

    Regards,

    Betsy Varughese

  • Hi Betsy, 

    I am using CGT version 5.0.0 LTS together with Linux SDK 11_01_00_03 and kernel 6.12. SDK RTOS_11_01_00_04. The tests yielded similar results using no-boot and HLOS modes. 

    Additionally, we are currently using <cmath> as our math library and are open to any suggestions for a more suitable library. 

    Thank you for your help in advance

  • Hi Betsy, 

    I am using CGT version 5.0.0 LTS together with Linux SDK 11_01_00_03 and kernel 6.12. SDK RTOS_11_01_00_04. The tests yielded similar results using no-boot and HLOS modes. 

    Additionally, we are currently using <cmath> as our math library and are open to any suggestions for a more suitable library. 

    Thank you for your help in advance

  • Hi Ekin,

    Could you please confirm your timing measurement method (e.g., chrono, time.h, or TSC)? I have used the hardware TSC for evaluations.

    I have observed varying cycle counts across different optimization levels and reduced the matrix size (to 256x256) so that the data fits entirely within the L2 SRAM. I will share the results along with the test code used below:

    test_code.cpp
               

    Optimization Level  (Matrix Init)  (Kernel Computation)
    -O0 1,255,677 8,548,401
    -O1 1,255,670 8,347,168
    -O2 424,249 1,822,644
    -O3 424,257 2,381,507
    -O4 424,324 2,381,451


    Could you also share your linker script and full test code? For comparison, I am currently using the default linker script from DSPLIB.

    Regards,
    Shabary S Sundar

  • Hi Betsy,

    We are working on FreeRTOS, using j784s4_linker_freertos.cmd and linker_mem_map.cmd.

    As the timing measurement method /app_utils/utils/timer

    uint64_t appLogGetGlobalTimeInUsec(void)
    {
        uint64_t cur_ts = 0; /* Returning ts in usecs */
        if ((0u != GTC_BASE_ADDR) &&
            (0u != mhzFreq))
        {
            cur_ts = appLogGetGtc() / mhzFreq;
        }

        return cur_ts;
    }


    function is used.

  • Hi Ekin,

    We are working on FreeRTOS, using j784s4_linker_freertos.cmd and linker_mem_map.cmd.

    From your setup, the issue looks memory-bound rather than compute-bound. Your 1024×1024 float matrix (~4 MB) is placed in DDR by default, while the C7x_1 L2 cache is only 64 KB. Since the working set is much larger than the cache, the core may spend most of its time waiting on DDR accesses, so compiler optimizations don’t show any noticeable impact.

    Could you please try reducing the matrix size to fit within L2 SRAM (448 KB) and place it in L2 SRAM explicitly and then try compiling with different optimization levels.

    Regards,
    Shabary S Sundar