-
Notifications
You must be signed in to change notification settings - Fork 476
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
PLT-1566 Add cost semantics for basic builtins #5679
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
-- Any number of variables | ||
constantCost : ∀{n} → CostingNat → CostingModel n | ||
linearCostIn : ∀{n} → Fin n → Intercept → Slope → CostingModel n | ||
-- at least two arguments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aren't these exactly two arguments? or have you just generalised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This a generalisation. As for higher number of arguments, constant and linear-on-a-single variable seem to be the used models. In this way I only need to provide semantics for these two models.
BStartup : ExBudgetCategory | ||
record BuiltinModel (b : Builtin) : Set where | ||
field | ||
costingCPU costingMem : CostingModel (arity b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't seem right, isn't arity here counting the type arguments too? whereas I think the model arguments are only the value arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure if this is a problem or not, you might be getting away with it because you're using the constant model for all the builtins that have type arguments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have type arguments per se, so this is the number of value arguments. In the formalisation, all signatures have the type quantifiers at the beginning, so we only record them with a number (actually two numbers, so we know how many * and how many # variables there are). See the definition of signature.
``` | ||
|
||
We will represent costs with Naturals. In the implementation `SatInt` is used, (integers that don't overflow, but saturate). | ||
As long as the budget is less than the maxInt then the result should be the same. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some point we'll want to do a version with something like SatInt
and I guess prove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. That is something we can do to be more certain about this. However, I don't think it matters for the purposes of analysing different cost models.
Co-authored-by: Michael Peyton Jones <michael.peyton-jones@iohk.io>
Cost semantics in the metatheory for the following builtin functions, and their corresponding costing models.