Bug Vectorized Trig Functions Results Differ

Hello, I am doing some noise generation, taking advantage of the Burst compiler, and it works (at least usually) great for batch workloads. I process 32 floats per loop and usually get nice vectorized code. I also have a fallback scalar evaluation function that processes 1 float per loop for algorithms that aren't suitable for batch. A noise function should return the same output when given the same input and I would like to ensure that the result is the same for an input whether the input is passed to the vectorized batch evaluation function or the scalar evaluation function. It is usually not too difficult to achieve equal results between the batch evaluation function and the scalar evaluation function. It is a different story with sin & cos.

The values returned from sin & cos in the batch evaluation function differ slightly from those returned from the scalar function. The only method I have found to produce equal results from the functions is to compile with FloatMode.Deterministic. The issue with this solution is calls to sin & cos are no longer auto-vectorized by Burst, instead reverting to calling sin/cos 32 times. With manual vectorization (using float4) the results remain equivalent to the scalar function while being more performant, though unfortunately, there doesn't seem a way to manually vectorize sin & cos up to Avx instructions (8 floats). This leaves me with a few questions.

Is it expected behavior that the results from sin & cos differ when vectorized vs not vectorized? Is there a better way to achieve equal results from the scalar and batch functions? Would it be possible to add Avx intrinsic functions for sin, cos, etc.? Is there something I am overlooking? Thanks.

 

Thank you both for your replies.

@tim_jones What I was thinking here wouldn't be exposing the SLEEF functions themselves, as that would put the burden on the caller to decide which version to use, but rather a "simple" Avx intrinsic function that does the same thing as float4 sin/cos in calling whichever version Burst deems fit.

Will be done asap.

@MarcoPersson Just tried it now and it does lessen the average difference between the batch and scalar functions by a factor of ~10, but in doing so, also lessens the performance. I am actually looking to use FloatPrecision.Low here as I am more concerned about performance. I just need the performant code to return the same results between the batch and scalar versions. Also, to clarify, both the scalar and batch evaluation functions are Burst compiled but, of course, only the batch version is vectorized.

 

I have gone ahead and filed a bug report for this issue: IN-42241