Test performance about cosmo

[wmwv]

Pow(x, -0.5) is in fact implemented as 1/Sqrt(x) in math.pow.go

   func pow(x, y float64) float64 {
        [...]
     case y == -0.5:
       return 1 / Sqrt(x)

[wmwv]

E(z) is 8 ns/call
Einv(z) defined as return 1/cos.E(z) is 13 ns/call
Explicitly writing out Einv(z) with Math.Pow([...], -0.5) is 14 ns/call.
Defining a test Einv(z) incorrectly as just return cos.E(z) is 11 ns/call.

[wmwv]

A ComovingDistance call is painful. It's 1.6 ms for one redshift.
And looping through 10,000 redshifts is 1.4 seconds! 1000x larger.

Python astropy.cosmology takes a similar amount of time for the same calculation. 1.7 s for N=10,000. 11 s for N=100,000 + N=10,000.

import numpy as np

import astropy.cosmology

cosmo = astropy.cosmology.FlatLambdaCDM(H0=70, Om0=0.3)

N = 10000
z = np.arange(N) + 0.001
cosmo.comoving_distance(z)

N = 100000
z = np.arange(N) + 0.001
cosmo.comoving_distance(z)

[wmwv]

So that's consistent. I was just hoping to do better because the astropy.cosmology implementation has always seemed really slow.

[wmwv]

Setting Gaussian quadrature n points to 1,000 preserves abs tolerance in distances of 1e-6 in Mpc and 1e-8 in distance modulus for the tested range of 0<z<3. Decrease from former value of 10,000 speeds of individual calculation by 10, as expected.

But the large N=10,000 redshift points loops are still at ~1.4 seconds. There are perhaps residual overheads I should look into further.

[wmwv]

If I test for looping over E(z), I get 85,000 ns, which is exactly in line with the 7-9 ns for the individual * N=10,000.

[wmwv]

Using a switch to avoid a math.Pow for w=-1 shaves 3 ns off the 8 ns runtime of E(z).

[wmwv]

math.Sin vs. math.Sinh doesn't matter