Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(runtime): Avoid branches in 164abs and 164neg in runtime/numbers #2171

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

spotandjake
Copy link
Member

This is a small pr that changes the way we do abs and neg in the runtime for some of our helpers, normally this would not matter but given we call gcd a lot it makes sense to avoid branching.

Copy link
Member

@ospencer ospencer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the sort of change that without some benchmarking I'd be reluctant to merge the change. It makes the code much harder to read, and this is the exact type of optimization that binaryen/the wasm runtimes would make for us.

@spotandjake
Copy link
Member Author

spotandjake commented Oct 28, 2024

This is the sort of change that without some benchmarking I'd be reluctant to merge the change. It makes the code much harder to read, and this is the exact type of optimization that binaryen/the wasm runtimes would make for us.

I compiled the program below:

module Main

ignore((1/4) * (2/4))

Screenshot 2024-10-28 at 3 28 44 PM
with grain types.gr --release --wat both with the changes applied and without them and as can be seen from the wat diff, Binaryen does not seem to be catching what is happening and produces the comparison still. (Maybe this is an indicator that we need to play around with the binaryen optimization settings a little more?

I was trying to benchmark this program with a simple loop like:

module Main

for (let mut i = 0; i < 100_000_000; i += 1) {
  ignore((1/4) * (1/8))
}

test()

But i kept running into OutOfMemory: Maximum memory size exceeded when running with wasmtime types.gr.wasm which kind of sounds like a memory leak, and I wanted to let test with a lot of iterations so the jit compiler could kick in and the time taken for the module to warmup would be less of an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants