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

Constant term pre-evaluation #139

Merged
merged 15 commits into from
Apr 24, 2023
Merged

Constant term pre-evaluation #139

merged 15 commits into from
Apr 24, 2023

Conversation

nielstron
Copy link
Contributor

This proposes a single optimization, that improves two things at once:

  • constant complex expressions that work in python are pre-evaluated and will work in OpShin too (i.e. bytes.fromhex("0011") and list(range(0,10,3)))
  • runtime is improved because at a high level constant values are precomputed (i.e. 2**24 is not computed on-chain but at compile time)

One final thing that needs to be addressed here is that we need to keep track of user-defined scopes (potentially re-assigned variables)

@nielstron
Copy link
Contributor Author

@juliusfrost Do you think you can get some numbers on how this affects compile time? And maybe places (i.e. in the pioneer program) that benefit from this? Most likely stuff like hardcoded keys that can now be written as "bytes.fromhex"

@nielstron
Copy link
Contributor Author

I just checked the examples and they have converged to a state where there is almost nothing that could be constant folded (except for some PlutusData constants). Might be a results of this feature missing so far though.

@juliusfrost
Copy link
Contributor

juliusfrost commented Apr 24, 2023

@juliusfrost Do you think you can get some numbers on how this affects compile time? And maybe places (i.e. in the pioneer program) that benefit from this? Most likely stuff like hardcoded keys that can now be written as "bytes.fromhex"

Maybe stuff in the interval api? Would methods like make_from be folded?

@nielstron
Copy link
Contributor Author

As of the current state, thats not the case. I guess constant folding is a bit misleading as we are just preevaluating static expressions. What would be interesting is to propagate/fold properly, but this requires more sophisticated analysis 😅

@nielstron nielstron changed the title Constant folding Constant term pre-evaluation Apr 24, 2023
@nielstron nielstron marked this pull request as ready for review April 24, 2023 17:12
@nielstron
Copy link
Contributor Author

nielstron commented Apr 24, 2023

Since this only adds 0.1s to the testbench, I will merge this feature. Notably, proper constant folding is still a desired feature and may follow later (potentially even based on this implementation).

Hopefully users won't get too confused about the fact that certain statements work as long as they are constant (i.e. bytes.fromhex("00") but not when they are dynamic (i.e. bytes.fromhex(a)). The fact that smart contract authors now don't have to worry about the cost of evaluating constant statements should greatly improve readability though.

@nielstron nielstron merged commit 266b262 into dev Apr 24, 2023
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.

2 participants