Sorry to revive a dead thread. I have also been playing with an interpreter and found that increasing the size of runtime.staticuint64s helps with the convT64 issue a lot. https://github.com/golang/go/blob/aa8262d800f0cba2e4d4472a7e344eb60481b0ff/src/runtime/iface.go#L493-L526
I'm guessing that such a small static array is sufficient in most Go programs, but in interpreters that are constantly putting integers into interfaces, it might be worth wasting a MiB or 2 to cover a larger range. For me it made a huge difference. This is only helpful if you're willing to modify Go's runtime package, of course. -- Kyle On Tuesday, December 22, 2020 at 2:30:55 PM UTC-6 ben...@gmail.com wrote: > Wow -- yes, that's pretty significant! (Though point taken about "real > workloads".) Thanks for sharing this. > > On Tuesday, December 22, 2020 at 11:44:25 PM UTC+13 arn...@gmail.com > wrote: > >> Luckily, I have the "no scalar" version with a build tag. Here is a >> simple benchmark: >> >> func BenchmarkValue(b *testing.B) { >> for n := 0; n < b.N; n++ { >> sv := IntValue(0) >> for i := 0; i < 1000; i++ { >> iv := IntValue(int64(i)) >> sv, _ = add(nil, sv, iv) // add is the "real" lua runtime >> function that adds two numeric values. >> } >> } >> } >> >> Results with the "scalar" version >> >> $ go test -benchmem -run=^$ -bench '^(BenchmarkValue)$' ./runtime >> goos: darwin >> goarch: amd64 >> pkg: github.com/arnodel/golua/runtime >> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz >> BenchmarkValue-8 122995 9494 ns/op 0 >> B/op 0 allocs/op >> PASS >> ok github.com/arnodel/golua/runtime 1.415s >> >> Results without the "scalar" version (noscalar build tag) >> >> $ go test -benchmem -run=^$ -tags noscalar -bench '^(BenchmarkValue)$' >> ./runtime >> goos: darwin >> goarch: amd64 >> pkg: github.com/arnodel/golua/runtime >> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz >> BenchmarkValue-8 37407 32357 ns/op 13768 >> B/op 1721 allocs/op >> PASS >> ok github.com/arnodel/golua/runtime 1.629s >> >> That looks like a pretty big improvement :) >> >> The improvement is also significant in real workloads but not.so dramatic >> (given they don't spend all their time manipulating scalar values!) >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7b0f9aef-51d6-40eb-99c6-ec4d9a455a5bn%40googlegroups.com.