-
Notifications
You must be signed in to change notification settings - Fork 479
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
Renamed to ASTSize, changed to Maybe CoverageIndex #6081
base: master
Are you sure you want to change the base?
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.
I changed this because I was compiling with -O0 , and it complained that there was no unfolding for GHC.++ in quickSort. Turns out this module was using too much of ghc stdlib. Is it good that I changed it @kwxm?
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.
Hmmm. The Haskell programs that these are based on are about 30 years old and are probably a bit old-fashioned to modern eyes: a lot of stuff that's commonly used these days just didn't exist when they were written. I just ported them with minimal changes and resisted the temptation to start "improving" them. My inclination would be to leave them as they are because changing the source makes it harder to see what changes are due to changes in our compiler: the differences in this file (which are quite small!) seem to have made the PIR for the whole program quite significantly different (current version, new version), which presumably accounts for the budget changes that show up later. Unless the programs stop working completely it's probably better not to change them.
@@ -99,9 +101,9 @@ randomIntegers s1 s2 = | |||
if 1 <= s2 && s2 <= 2147483398 then | |||
rands s1 s2 | |||
else | |||
error "randomIntegers: Bad second seed." | |||
error () -- "randomIntegers: Bad second seed." |
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.
Is there a reason not to use traceError "randomIntegers: Bad second seed."
?
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.
Good idea
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.
Is there a reason not to use traceError "randomIntegers: Bad second seed."?
I think the reason for that is that traceError
didn't exist when these were written (or more accurately, were stolen from here). I don't think that error will ever occur anyway.
({cpu: 2556922462 | ||
| mem: 8409416}) |
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.
Given the changes above, do you have an idea why did the budget go up?
@@ -0,0 +1,66 @@ | |||
module PlutusCore.ASTSize |
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.
Since this module is new I suggest to use:
- 2 space indentation, as per the CODESTYLE.adoc
- Explicit imports.
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.
About the 2space I agree, but about the explicit imports I kind of disagree.
I used to be back in the days also a proponent of explicit imports, but thanks to mpj I learned that managing and constantly editing the import list is a burden, even with hls helping you out (when it works).
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 learned that managing and constantly editing the import list is a burden
I agree that its a burden for a writer, but its a relief for a reader. Wildcard import shift the effort away from writers to readers. Since code is read more times that its written, I'd argue that we should optimise for reading.
@@ -0,0 +1,25 @@ | |||
module PlutusIR.ASTSize |
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.
Same comment about 2-space indentation and explicit imports.
SerializedCode | ||
BS.ByteString -- ^ UPLC.Program flat-encoded | ||
(Maybe BS.ByteString) -- ^ PlutusIR.Program flat-encoded | ||
(Maybe BS.ByteString) -- ^ CoverageIndex flat-encoded |
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.
Thanks for the comments!
getCovIdx wrapper = case wrapper of | ||
SerializedCode _ _ idx -> idx | ||
SerializedCode _ _ idx -> unsafeFromEither . unflat <$> idx |
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.
The error emitted by unsafeFromEither
is not telling what invariant was violated, its too generic.
I suggest to pattern match and throw a more explanatory error, e.g. "SerializedCode was expected to contain information about CodeCoverage because of ... but it doesn't"
@@ -29,7 +29,7 @@ loadFromFile fp = TH.liftSplice $ do | |||
-- We don't have a 'Lift' instance for 'CompiledCode' (we could but it would be tedious), | |||
-- so we lift the bytestring and construct the value in the quote. | |||
bs <- liftIO $ BS.readFile fp | |||
TH.examineSplice [|| SerializedCode bs Nothing mempty ||] | |||
TH.examineSplice [|| SerializedCode bs Nothing Nothing ||] |
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 this point I am wondering if there are any reasons not to make SerializedCode
a record with fields and use them to increase readability?
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 this point I am wondering if there are any reasons not to make
SerializedCode
a record with fields and use them to increase readability?
That might indeed be helpful.
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 left some suggestions but they aren't critical.
/benchmark nofib |
Click here to check the status of your benchmark. |
Failed :( |
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 looks basically OK, but I'm not too keen on modifying the nofib Knights example if we can avoid it.
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.
Hmmm. The Haskell programs that these are based on are about 30 years old and are probably a bit old-fashioned to modern eyes: a lot of stuff that's commonly used these days just didn't exist when they were written. I just ported them with minimal changes and resisted the temptation to start "improving" them. My inclination would be to leave them as they are because changing the source makes it harder to see what changes are due to changes in our compiler: the differences in this file (which are quite small!) seem to have made the PIR for the whole program quite significantly different (current version, new version), which presumably accounts for the budget changes that show up later. Unless the programs stop working completely it's probably better not to change them.
@@ -99,9 +101,9 @@ randomIntegers s1 s2 = | |||
if 1 <= s2 && s2 <= 2147483398 then | |||
rands s1 s2 | |||
else | |||
error "randomIntegers: Bad second seed." | |||
error () -- "randomIntegers: Bad second seed." |
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.
Is there a reason not to use traceError "randomIntegers: Bad second seed."?
I think the reason for that is that traceError
didn't exist when these were written (or more accurately, were stolen from here). I don't think that error will ever occur anyway.
import Control.Lens | ||
import Data.Monoid | ||
|
||
newtype ASTSize = ASTSize |
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.
Just to be annoying, maybe ASTSize
isn't as informative as it could be: there might be lots of different ways you could measure the size of an AST and the name doesn't make it obvious what's actually being measured. Something likeNumberOfASTNodes
might be more informative. I don't mind all that much though.
@@ -29,7 +29,7 @@ loadFromFile fp = TH.liftSplice $ do | |||
-- We don't have a 'Lift' instance for 'CompiledCode' (we could but it would be tedious), | |||
-- so we lift the bytestring and construct the value in the quote. | |||
bs <- liftIO $ BS.readFile fp | |||
TH.examineSplice [|| SerializedCode bs Nothing mempty ||] | |||
TH.examineSplice [|| SerializedCode bs Nothing Nothing ||] |
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 this point I am wondering if there are any reasons not to make
SerializedCode
a record with fields and use them to increase readability?
That might indeed be helpful.
a161078
to
db5cabb
Compare
My initial intentions was to stop using ast size in
Code.sizePlc
because it may be confusing,but use flat byte size instead.
Instead I renamed Size related functions and modules to ASTSize to make it more clear what this size is supposed to be.
I will do the real switch to flat/cbor size in another PR.
Also CoverageIndex had 2 problems:
Pre-submit checklist: