Yeah, after posting I realized that the compiler would probably be smart
enough to optimize that out, so I changed them to:
func BenchmarkUntypedConstants(b *testing.B) {
var z float64
for i := 0; i < b.N; i++ {
z = 0.3 - 0.1*3
}
b.Log(z)
}
func BenchmarkDecimalPackage(b *testing.B) {
var z *decimal.Big
for i := 0; i < b.N; i++ {
x := decimal.New(1, 1)
y := decimal.New(3, 0)
z = decimal.New(3, 1)
z.Sub(z, x.Mul(x, y))
}
b.Log(z)
}
BenchmarkUntypedConstants-8 2000000000 0.29 ns/op
BenchmarkDecimalPackage-8 5000000 256 ns/op
I guess the var declarations inside the loop for the decimal package
consume some cycles, but anyway the difference is substantial. To be clear,
my point here is not to demonstrate this decimal package (or any other
similar) isn't a good option; but rather if the Go internal untyped
constant code is that fast and easy to use, why not make it available for
more general purposes (financial, scientific, etc..)?
On Sunday, September 2, 2018 at 9:27:46 PM UTC-4, kortschak wrote:
>
> This is not a benchmark of the untyped constant expression evaluation.
> The expression in the loop is performed once and thrown away *at
> compile time*. The benchmark here is really:
>
> func BenchmarkUntypedConstants(b *testing.B) {
> b.Log(0.3 - 0.1*3)
> for i := 0; i < b.N; i++ {
> }
> }
>
> On Sun, 2018-09-02 at 16:53 -0700, José Colón wrote:
> > Maybe this comparison is completely wrong or unfair, but calculations
> > with
> > Go untyped constants is much faster than
> > the github.com/ericlagergren/decimal package. In the end, they both
> > produce
> > the same correct answer: 0 .
> >
> > func BenchmarkUntypedConstants(b *testing.B) {
> > b.Log(0.3 - 0.1*3)
> > for i := 0; i < b.N; i++ {
> > _ = 0.3 - 0.1*3
> > }
> > }
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
