Low performance using ARM inspector-executor pattern for sparse daxpyi

Hi, thanks for your patience :)

With regards to your first question, the answer is "maybe"... 

if you are timing the whole function you shared, which includes creating the sparse vector and destroying it as well as execution of the actual operation, then yes that will be slower than simply using your own loop. I observe the same performance ratio that you reported in that case, when comparing with a naive loop implementation.

However, if you just time the `armpl_spaxpby_exec_d` call over a number of iterations, then you should see better performance than the naive loop implementation. I see 2x better performance in Arm PL in this case. E.g.

    // Start timing
    struct timespec start, end;
    clock_gettime(CLOCK_MONOTONIC, &start);

    for (int i = 0; i < niters; ++i)
    {
        status = armpl_spaxpby_exec_d(alpha, spvec_x, beta, y);

        // Re-initialize y for fair timing
        for (int i = 0; i < n; i++) {
            y[i] = (double) rand() / RAND_MAX;
        }

        if (status != ARMPL_STATUS_SUCCESS)
        {
            fprintf(stderr, "Error: armpl_spaxpby_exec_d failed at iteration %d with status %d\n", i, status);
            armpl_spvec_destroy(spvec_x);
            return;
        }
    }

    // End timing
    clock_gettime(CLOCK_MONOTONIC, &end);

    // Compute elapsed time in seconds
    double elapsed_sec = (end.tv_sec - start.tv_sec) + 1e-9 * (end.tv_nsec - start.tv_nsec);

    printf("Executed armpl_spaxpby_exec_d %d times\n", niters);
    printf("Total time: %.6f seconds\n", elapsed_sec);

My answer was "maybe" to your question about misapplying the interface because it depends on what you're trying to do.

If you have a scenario where the sparsity pattern of the sparse vector remains the same over repeated applications of spaxpby, then you should only create the `armpl_spvec_t` object once and reuse that in a loop over the` armpl_spaxpby_exec_d` call. The library should give good performance then.

However, if your sparse vector changes each time, then as you've seen you're probably better off avoiding the overhead of creating & destroying the `armpl_spvec_t` object each time, and using your own loop instead. 

With regards to question 2: since this is a memory-bound operation, there aren't really any caching optimizations.

For question 3, if you have the second scenario (a sparse vector that changes each time) and need your own loop implementation, then ensuring the loop is using Neon or SVE SIMD instructions can make a difference. Compilers can generate these for you with the right set of flags and possibly requiring some compiler directives such as `#pragma omp simd`.

I hope that helps! Please let me know if you need any further help.

Regards,

Chris.

Hi, thanks for your patience :)

With regards to your first question, the answer is "maybe"... 

if you are timing the whole function you shared, which includes creating the sparse vector and destroying it as well as execution of the actual operation, then yes that will be slower than simply using your own loop. I observe the same performance ratio that you reported in that case, when comparing with a naive loop implementation.

However, if you just time the `armpl_spaxpby_exec_d` call over a number of iterations, then you should see better performance than the naive loop implementation. I see 2x better performance in Arm PL in this case. E.g.

    // Start timing
    struct timespec start, end;
    clock_gettime(CLOCK_MONOTONIC, &start);

    for (int i = 0; i < niters; ++i)
    {
        status = armpl_spaxpby_exec_d(alpha, spvec_x, beta, y);

        // Re-initialize y for fair timing
        for (int i = 0; i < n; i++) {
            y[i] = (double) rand() / RAND_MAX;
        }

        if (status != ARMPL_STATUS_SUCCESS)
        {
            fprintf(stderr, "Error: armpl_spaxpby_exec_d failed at iteration %d with status %d\n", i, status);
            armpl_spvec_destroy(spvec_x);
            return;
        }
    }

    // End timing
    clock_gettime(CLOCK_MONOTONIC, &end);

    // Compute elapsed time in seconds
    double elapsed_sec = (end.tv_sec - start.tv_sec) + 1e-9 * (end.tv_nsec - start.tv_nsec);

    printf("Executed armpl_spaxpby_exec_d %d times\n", niters);
    printf("Total time: %.6f seconds\n", elapsed_sec);

My answer was "maybe" to your question about misapplying the interface because it depends on what you're trying to do.

If you have a scenario where the sparsity pattern of the sparse vector remains the same over repeated applications of spaxpby, then you should only create the `armpl_spvec_t` object once and reuse that in a loop over the` armpl_spaxpby_exec_d` call. The library should give good performance then.

However, if your sparse vector changes each time, then as you've seen you're probably better off avoiding the overhead of creating & destroying the `armpl_spvec_t` object each time, and using your own loop instead. 

With regards to question 2: since this is a memory-bound operation, there aren't really any caching optimizations.

For question 3, if you have the second scenario (a sparse vector that changes each time) and need your own loop implementation, then ensuring the loop is using Neon or SVE SIMD instructions can make a difference. Compilers can generate these for you with the right set of flags and possibly requiring some compiler directives such as `#pragma omp simd`.

I hope that helps! Please let me know if you need any further help.

Regards,

Chris.

Thanks for the suggestion!

I'll try this out and do more testing.