XSIMD implementation is slower than scalar performance with mixed precision operations

[spectre-ns]

The following code performs operations on mixed types

    static void Xtensor_Uint16_2000x2000_DivideBy2Double_Xtensor(benchmark::State& aState)
    {
        xt::xtensor<uint16_t, 2> vInput = generateRandomInt16From0To100(cContainerAssignShape);
        auto vOutput = xt::xtensor<uint16_t, 2>::from_shape(cContainerAssignShape);

        for (auto _ : aState)
        {
            vOutput = vInput / 2.0;
        }
    }

When computing the expression, the result of uint16_t / int is an int. The resulting int then needs to be stored into vOutput as a uint16_t. As a result, std::copy is getting called in the inner loop inside load_aligned. The following code resolves this issue:

    static void Xtensor_Uint16_2000x2000_DivideBy2Double_Xtensor(benchmark::State& aState)
    {
        xt::xtensor<double, 2> vInput = generateRandomInt16From0To100(cContainerAssignShape);
        auto vOutput = xt::xtensor<double, 2>::from_shape(cContainerAssignShape);

        for (auto _ : aState)
        {
            vOutput = vInput / 2.0;
        }
    }

Is there a way to implement xsimd without copying data?

[JohanMabille]

Does it fix the issue if you explicitely cast the scalar to uint16_t ?

[spectre-ns]

Does it fix the issue if you explicitely cast the scalar to uint16_t ?

It eliminates the simd assignment which does get rid of the copy but shouldn't we be able to vectorize the whole operation right?

[JohanMabille]

Ha indeed, I forgot not all architectures provide instruction for integer division. But then I'm a bit confused with "When computing the expression, the result of uint16_t / int is an int"; from what I understand it should compute uint16_t / double as a double, and then copy the result to uint16_t.

Anyway, I'm afraid we cannot get rid of the conversion here, but maybe we could explore a different implementation of the load_aligned / store_aligned functions in xsimd, based on batch_cast instead of copying buffers. Not sure how faster it would be, though.