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.
