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

Add fibonacci benchmark, for fairly low-level eval performance #892

Merged
merged 2 commits into from
Jul 11, 2024

Conversation

devyn
Copy link
Contributor

@devyn devyn commented Jul 11, 2024

This is a benchmark that I created while testing IR. It's meant to basically do only very simple operations but be running 100% Nushell code most of the time, without any heavy lifting being done by commands, and without any closure calls or anything like that. It seemed useful to keep around so I'm adding it to nu_scripts.

@fdncred
Copy link
Collaborator

fdncred commented Jul 11, 2024

Thanks

@fdncred fdncred merged commit 0d70dbd into nushell:main Jul 11, 2024
1 check passed
@devyn devyn deleted the fibonacci-bench branch July 11, 2024 12:11
@amtoine
Copy link
Member

amtoine commented Jul 13, 2024

just for fun, because generate is cool and helps annihilate mut 😏

# compute the Fibonacci numbers until $F_n$
#
# # Example
# ```nushell
# # compute $F_42$
# fib 42 | last
# ```
def fib [n: int]: [ nothing -> list<int> ] {
    generate [0, 1] { |fib| {
        out: $fib.0,
        next: [$fib.1, ($fib.0 + $fib.1)],
    } }
    | first ($n + 1)
}

@devyn
Copy link
Contributor Author

devyn commented Jul 13, 2024

Yeah we can add that too, it's actually a good comparison / goal for optimization.

It is much slower though. It would be really nice to be able to get things to the point where it has similar performance, but the mutable version really is so much simpler to execute unfortunately

@fdncred
Copy link
Collaborator

fdncred commented Jul 13, 2024

it would be interesting to compare the ir of these two methods through debug profile

@devyn
Copy link
Contributor Author

devyn commented Jul 14, 2024

One of the things you won't see in debug profile is the extra work being done to make a closure call. That's something I'd like to make more efficient

@amtoine
Copy link
Member

amtoine commented Jul 14, 2024

aah yeah, that's a bummer if the generate version is so much slower... i find it much much better than using mut, more Nushelly 😌

@devyn
Copy link
Contributor Author

devyn commented Jul 14, 2024

Certainly. I think the main thing holding it back really is closure eval performance, though I should try profiling it

There's also a free/alloc on each loop there because of the list. Mimalloc is efficient, but I think the mutable version involves no extra heap allocations for each loop

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

Successfully merging this pull request may close these issues.

3 participants