Faster binary operations

[geseq]

Improves BinaryOp performance significantly

Before:

-------------------------------------
fibonacci(35)
-------------------------------------
Result:  9227465
Go:      42.388955ms
Parser:  36.718µs
Compile: 109.024µs
VM:      2.787647146s
-------------------------------------
fibonacci(35) (tail-call #1)
-------------------------------------
Result:  9227465
Go:      42.789713ms
Parser:  21.297µs
Compile: 70.948µs
VM:      2.894222823s
-------------------------------------
fibonacci(35) (tail-call #2)
-------------------------------------
Result:  9227465
Go:      256ns
Parser:  17.864µs
Compile: 60.804µs
VM:      14.668µs 

After:

-------------------------------------
fibonacci(35)
-------------------------------------
Result:  9227465
Go:      41.610339ms
Parser:  33.751µs
Compile: 98.728µs
VM:      2.252044656s
-------------------------------------
fibonacci(35) (tail-call #1)
-------------------------------------
Result:  9227465
Go:      41.661108ms
Parser:  18.044µs
Compile: 59.931µs
VM:      2.700379139s
-------------------------------------
fibonacci(35) (tail-call #2)
-------------------------------------
Result:  9227465
Go:      240ns
Parser:  22.475µs
Compile: 70.738µs
VM:      22.121µs

[beoran]

@geseq While value based semantics can indeed improve performance, this drastically changes the API of Tengo. It would need to be versioned as v3 to make this change.

[geseq]

I agree

[beoran]

@geseq In that case, it might be an idea to try to implement full value semantics for all types for v3, not just for integrets. This might seem strange for maps , arrays, etc but it is possible if somewhat unusual.

[geseq]

I would want to construct benchmarks before I do that, and at the moment my use case doesn't really require it.

[geseq]

I'm happy for you to look into it and create a PR if you're interested.

[beoran]

Well, my main interest here is consistency. Now Tengo uses pointer semantics for v2 everywhere and that is easy to remember. Having a mix of pointer and value semantics is more confusing and less straightforward to use

[geseq]

Most languages have different semantics between primitive and Object types so that shouldn't be a concern.

I wouldn't mind implementing value semantics for Bool creating value semantics for the primitive types and leaving the pointer semantics well alone for the rest for now.

[geseq]

Again, I do agree with you that in the view of backwards compatibility this shouldn't go into v2, but the performance gains are fairly clear so I would think it's a worthwhile addition.

[d5]

curious. why couldn't you make bool value sematics?

[geseq]

Sorry, I just didn't think of it at first. As I mentioned a couple of posts above, i wouldn't mind doing Bools. Working on that now.

It would carve out primitive types as having value semantics.

[d5]

Yeah. I didn't look into all the details yet, but I like the idea of having value- and pointer- semantics for different types. It was long time ago, but I'm pretty sure I tried value-sematics when I was working on the first version for an obvious performance reason. Then I had to decide on pointers for a couple of reasons that I don't remember, unfortunately. Maybe I failed because I used value sematics for all types. Not sure.

[geseq]

updated with bools.

I wouldn't be entirely surprised if value semantics for non-primitive types did worsen the performance.

I'm happy to look into it whenever there is time (which there rarely is tbh), but for now I think this offers an improvement that's worth adding.

[d5]

Also I would suggest that we create v3 branch so we can put some other changes we need to upgrade the version - documentation, maybe some settings, etc. We can change this PR to base off of v3 branch. How does that sound?

[d5]

and maybe update the performance benchmark in README too? :)

[beoran]

Fair enough to use pointer semantics for arrays and maps, but in Go strings also have value semantics. I wonder if that would also work in Tengo?