float and double have different ranges and so you hit the "slow" path in float sooner.

That is, MathF.Exp(88.7228546f) (roughly iteration 893080) returns float.PositiveInfinity, where-as Math.Exp(88.7228546f) returns 3.4028764221808227E+38, which then downcasts to float.PositiveInfinity.

You actually never hit the "slow" path for double given the ranges you're computing since even 5000000 iterations ends up returning 1.2021196743947096E+211 (which is for roughly Math.Exp(486.02954f)).

If you look at the code for an expf implementation such as from AMD's aocl-libm: https://github.com/amd/aocl-libm-ose/blob/master/src/optmized/expf.c#L142, you'll see that the general case of value > 88.0f is considered "unlikely" and hits a generally slower computation path since it has to handle things like raising floating-point exceptions if they were enabled. -- Noting the code referenced here is not necessarily "exactly" what happens on a given platform, but it is a decent approximation for what most implementations end up doing.

So from a C/C++ perspective, (float)exp(88.7228546f) and expf(88.7228546f) are not "equivalent operations" by default. They only end up being equivalent in .NET since we don't support the IEEE 754 floating-point exceptions and disable them.

.NET would have to port such code to managed or otherwise maintain our own "fork" to improve the performance for such cases, but there is a lot of complexity and concern around long term maintenance burden where we to do that. -- CC. @jkotas