Eval4Inputs optimisation about little-cms

[mm2]

Thanks @glennwilton
The current code is such because it has been tested for speed in many optimizing compilers and this variant runs fast. The two loops are vectorized in some cases. I choose to keep this code for clarity sake. Also, I found the whole tetrahedra partition has to be recomputed because sometimes is different when K advances. Assembly code produced by optimizer is quite different from C, so those additions probably are not there.

If you want to provide a PR, I will be glad to run it across an extensive throughput test bed I keep for such cases.

[glennwilton]

Thanks, I did not consider compiler optimisations, which negate the complexity; I'm using a similar function in Javascript on 3D/4D Luts and noticed the optimisations that make a big difference in JS, as I need all the optimisations I can get!!

[mm2]

Yep, JS is a quite different thing. You can try what modern optimizers does in C here:

https://godbolt.org/

I tried this code with -Ofast as options:

int test()
{
    int a = 0;

    for (int i=0; i < 10; i++)
    {   
        a += i*2;
    }
    
    for (int j=0; j < 10; j++)
    {   
        a -= j/3;
    }

return a;
}

And the compiler generated this assembly:

test():
        mov     eax, 78
        ret

[glennwilton]

That is interesting. It has been a long time since I did anything In C.

Out of interest are there any utils for testing the throughput performance of LittleCMS, I'm curious to see the speed difference between LCMS and what I've done in JS. My C is very rusty, but I suspect I could modify transicc.

On my Ryzen7 3700X in Javascript (all single Core/ No threads) using a prebuilt RGB->CMYK LUT 33x33x33 with 64bit float values , and 8bit input/out arrays , Chrome is pushing through 39 million pixels per second, and Firefox 36 million pixels per second. Fast enough for what I need but interesting to see what C code can pump though.

[mm2]

No defect was described here, so I close the issue