Calling System.Math floating point operations in a loop causes long GC pause times

[jkotas]

dotnet/performance#1049 (comment)

category:cq
theme:optimization
skill-level:intermediate
cost:medium

[jkotas]

I have tried to add the GC polls to the System.Math FCalls, but it regressed their performance in non-trivial way. I believe that emitting the GC polls in managed code would be the best way to fix this problem.

It looks exactly like what SuppressGCTransitionAttribute was designed for. Unfortunately, the implementation of SuppressGCTransitionAttribute is not efficient currently (tracked by #13582). Once #13582 is fixed, it should be trivial to switch these math FCalls to QCalls w/SuppressGCTransitionAttribute to fix the GC pause time problem.

cc @dotnet/jit-contrib @AaronRobinsonMSFT

[jkotas]

Blocked by https://github.com/dotnet/coreclr/issues/27186

[VSadov]

I assume the solution to SuppressGCTransitionAttribute will be equally available to fast FCALLs which must be FCALLs (ex. casts), but suffer from the same problem. Re: https://github.com/dotnet/coreclr/issues/27931

emit the poll just once per loop in managed code, if there is a loop - seems to be sufficient solution for both cases.

[erozenfeld]

@jkotas @VSadov #13582 is done so this one is now blocked by #13591 (crossgen support for inlined GC polls).

[am11]

@jkotas, is this issue tracking the conversion of methods in both Math.CoreCLR.cs and MathF.CoreCLR.cs from FCall to QCall? There are total 56 methods, seems like they all will require same conversion mechanics for QCall.

$ git grep '\[MethodImpl(MethodImplOptions.InternalCall)\]' :/src/coreclr/*.{cs,vb} | grep -i math | wc -l
56

[am11]

Something like this: master...am11:feature/fcalls-to-qcalls

[jkotas]

Yes, something like this. Would you like to submit it as PR?

We may not need (most/all) of the COMSingle/COMDouble wrappers with this approach, and instead just call C-runtime methods directly. It will help with reducing the overhead.