-
Notifications
You must be signed in to change notification settings - Fork 3
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
fixedparser optimisation (rewrite rules) is a bit fiddly #11
Comments
actually, the first foo.core (applicative style) output is identical to the core when |
ah, i was missing an INLINE pragma on fixedBigEndianWord64. this fixed the issue in the previous comment about the core being optimal in all cases (it's not now). so, to recap where i am now: foo.hs - optimal |
i'm going to compare across word-types now |
for the word32 type, the monadic style (sans applicative-do) performs better than the word64 type |
https://gist.github.com/chessai/a1090722d0a16d2f9c23e314a5b53a58 this gist is more immediately comprehensive than me talking |
look at the following gist: https://gist.github.com/chessai/39dfce8b2a56a05f3c48bd49ac52d066
it contains pairs of .hs files and their core output as a result of
\module -> ghc module -O2 -ddump-simpl -dsuppress-all -fforce-recomp
each .hs file contains a parser for the 'Foo' datatype, defined as
in foo.hs, we use full applicative style. the core output is completely optimal.
in fooM.hs, we use monadic style. the core output is optimal for the first two parses, but the second two fail to optimise.
in fooA.hs, we use monadic style, but with
-XApplicativeDo
enabled. the core output is optimal for the latter three parses, but the first fails to optimise.The text was updated successfully, but these errors were encountered: