Date: Thu, 02 Mar 2023 13:06:51 -0800
On Thursday, 2 March 2023 06:59:16 PST Niall Douglas via SG16 wrote:
> In any case, I appreciate that SIMD wasn't originally intended for work
> which has values cross lanes, hence byte-work with SIMD was historically
> inefficient. We can do better on very new CPUs thankfully, but it does
> mean we need to think in terms of the API being designed to allow
> sucking down hundreds of bytes per opcode.
In particular, the APIs must be designed in such a way that, when a contiguous
range is used, a SIMD and/or non-inline implementation is possible.
> In any case, I appreciate that SIMD wasn't originally intended for work
> which has values cross lanes, hence byte-work with SIMD was historically
> inefficient. We can do better on very new CPUs thankfully, but it does
> mean we need to think in terms of the API being designed to allow
> sucking down hundreds of bytes per opcode.
In particular, the APIs must be designed in such a way that, when a contiguous
range is used, a SIMD and/or non-inline implementation is possible.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-03-02 21:06:53