-
Notifications
You must be signed in to change notification settings - Fork 483
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
Unrestricted force #5112
Unrestricted force #5112
Conversation
Don't look here yet. This is an experiment I've wanted to do for a while, just looking to get some benchmark numbers.
/benchmark plutus-benchmark:nofib |
Comparing benchmark results of ' plutus-benchmark:nofib' on '9fabd96d2' (base) and '6414603b4' (PR) Results table
|
/benchmark plutus-benchmark:validation |
Comparing benchmark results of ' plutus-benchmark:validation' on '9fabd96d2' (base) and '6414603b4' (PR) Results table
|
Rather than doing this as a post-hoc optimisation, why not omit emitting unnecessary delays and forces? That seems like a simpler thing to do. |
You could in PIR make one constructor for both type abstractions and lambdas of arbitrary (type) parameters, which would seemingly allow you to emit more optimised UPLC. |
I disagree with this as a compiler design principle. IME (and I think this is the standard wisdom) it's almost always better to make code-gen as dumb as possible and then optimize away the bad stuff. That makes your code gen simpler (which is important since it's almost always pretty complicated anyway), and your optimizations will benefit you in other places. |
Pretty modest tbh, slightly disappointing. |
Don't look here yet. This is an experiment I've wanted to do for a
while, just looking to get some benchmark numbers.
Pre-submit checklist: