You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found two issues when looking at the generated code in patternMatching.pir.golden
x, y, z, w are all non-strict bindings. This causes their bodies to be evaluated every time they are referenced, which is why patternMatching is slower than recordFields. If CSE is turned on, then patternMatching does become much cheaper, because force x, force y etc. are considered common subexpressions and are factored out. However, it is not great to have to rely on CSE, which is unreliable. Can we generate more strict code from AsData?
The use of Tuple4 also has some overhead. Is it possible to generate code that doesn't use tuples? Ideally it should look like this:
@ana-pantilie I looked a bit into this, and wrote a more efficient pattern synonym by hand: see IntsManualPattern in b31eab9.
To answer the two questions above:
I don't think there's an easy way to make x etc. strict, since that's just how GHC handles pattern synonyms - arguably it is a GHC bug. So, we should advise users to strictify them by binding each of them to another strict variable - see patternMatchingManual.
I also don't think there's an easy way to avoid the Tuple4 - as you can see, I had to use a 4-tuple even in my hand written pattern synonym.
That said, the hand written pattern synonym is more efficient than the TH generate one, and we should modify the TH to generate the more efficient version.
So, we should advise users to strictify them by binding each of them to another strict variable - see patternMatchingManual.
There's actually a much simpler solution: use case ... of IntsManualPattern x y z w instead of let (IntsManualPattern x y z w) = .... The latter somehow doesn't work, even with bang patterns all over the place (let !(IntsManualPattern !x !y !z !w) = ...).
I found two issues when looking at the generated code in
patternMatching.pir.golden
x
,y
,z
,w
are all non-strict bindings. This causes their bodies to be evaluated every time they are referenced, which is whypatternMatching
is slower thanrecordFields
. If CSE is turned on, thenpatternMatching
does become much cheaper, becauseforce x
,force y
etc. are considered common subexpressions and are factored out. However, it is not great to have to rely on CSE, which is unreliable. Can we generate more strict code fromAsData
?Tuple4
also has some overhead. Is it possible to generate code that doesn't use tuples? Ideally it should look like this:The text was updated successfully, but these errors were encountered: