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

Allow force on anything and/or give up forcing builtins #6569

Open
effectfully opened this issue Oct 14, 2024 · 2 comments
Open

Allow force on anything and/or give up forcing builtins #6569

effectfully opened this issue Oct 14, 2024 · 2 comments

Comments

@effectfully
Copy link
Contributor

Michele | Harmonic reported on X:

allow force frames during evaluation to accept any return value, not only delayed and builtins

so that stuff like

(force [[[(force (builtin ifThenElse)) (con bool True)] (con integer 0)] (delayed error)])

is valid

We've discussed this before (in private) and here's what Michael thought at the time:

I’m increasingly pro “force anything”. It would really allow us to remove a lot of delays, and delays are a shockingly large amount of our programs. It would I think also make it easier to transition to not requiring us to force builtins at all - old programs which still did so would continue to be valid since they’re allowed to force anything.

Not forcing builtins is something that Michele | Harmonic brought up as well.

I'm not sure what my stance on the issue is: on the one hand removing things that don't have to be there is clearly beneficial, on the other hand I'm generally afraid of making the semantics of the language weirder. It would be great to implement this just to see how much performance improvement we get out of it. If it's just a few percent, I'd say it's not worth it.

I'll write to our scientists, maybe they happen to have a bright idea on how the semantics of allowing force on anything is actually fine.

@effectfully effectfully self-assigned this Oct 14, 2024
@github-actions github-actions bot added the status: needs triage GH issues that requires triage label Oct 14, 2024
@effectfully effectfully removed the status: needs triage GH issues that requires triage label Oct 15, 2024
@effectfully effectfully changed the title Allow force on anything Allow force on anything and/or give up forcing builtins Oct 17, 2024
@effectfully
Copy link
Contributor Author

@nau has done some great analysis:

I ran 40,000 scripts by validating transactions of epoch 508 using @Scalus3.

image

Here are some takeaways:

  1. 12% of all CPU budget is spent on Data<=>Uplc conversions, which I consider useless.

  2. ~10% of script space and execution budget is wasted on Force/Delay nodes.

  3. If we had IfThenElse as UPLC term we could remove force/delay and a lot of terms evaluation

  4. Separating Data and UPLC is a costly mistake

Also related to #6578.

@effectfully
Copy link
Contributor Author

Apparently this has been implemented twice: #4241 and #5112. It was an improvement, but not a very significant one in either of the cases.

It is however possible that the way we use UPLC is different to the way others use UPLC (in particular, we do use SOPs and others don't, not to the same extent at least, which means they're going to have much more forces and delays). We should check this hypothesis and run the same experiment but on the scripts submitted to the chain as opposed to our own benchmarks, maybe that'll reveal the usefulness of the optimization.

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

No branches or pull requests

1 participant