tag:blogger.com,1999:blog-8761623568109455093.post6585223192287466071..comments2013-05-03T22:31:38.253+04:00Comments on Bits and Bytes: binary 0.7Lennart Kolmodinhttp://www.blogger.com/profile/11472900998358020886noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8761623568109455093.post-12773673218249978882013-05-03T22:31:38.253+04:002013-05-03T22:31:38.253+04:00Thanks for such a complete answer, it seems that y...Thanks for such a complete answer, it seems that you have tried all the possibilities. I'll look at them and specially the arrows tutorial.<br />fmastehttps://www.blogger.com/profile/05489262070099785692noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-73307850579946909692013-05-03T22:00:54.841+04:002013-05-03T22:00:54.841+04:00It's not possible to build a monadic parser th...It's not possible to build a monadic parser that statically can determine how much input it'll require, so the binary package is not able to do this.<br />It does not matter whether it's a deep or shallow embedding, it just can't be done with a monad.<br />To statically determine the required input, I've found the best way is to use arrows.<br />Read about the limitation of the monads, and why arrows can solve this, here's a great tutorial I found: http://ertes.de/new/tutorials/arrows.html<br /><br />You can find my binary-arrow experiment here;<br />https://github.com/kolmodin/binary-arrow<br />However, it seems that it does not always result in a great speedup, it seems that doing allocation is more expensive than boundary checks, and therefore there is little to save by eliminating the boundary checks.<br />Also, the way I wrote the arrow library, it's not possible to have recursive parsers due to the very agressive inlining that it does.<br />Next, I wanted to rewrite it into CPS in hope that GHC can optimise better, but I have not yet come around to doing it.<br />If you come to a different conclusion about the efficiency of statically knowing more about the parser, I'm of course interested to hear :)Lennart Kolmodinhttps://www.blogger.com/profile/11472900998358020886noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-6540880147983967302013-05-03T20:45:10.375+04:002013-05-03T20:45:10.375+04:00Do you think that knowing in advance how many byte...Do you think that knowing in advance how many bytes a monadic function like for example {getWord8 >> getWord8 >> getWord8} needs will provide a significant speed improvement?<br /><br />Is it possible to do this with the kind of deep embedding you have now?<br /><br />If yes to the first question and no to the second I can try building a wrapper package using the operational or free package to see how it works.<br />fmastehttps://www.blogger.com/profile/05489262070099785692noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-39817700868360668182013-04-30T15:14:40.440+04:002013-04-30T15:14:40.440+04:00'operational' looks like deep embedding of...'operational' looks like deep embedding of a dsl.<br />binary indeed does something similar. However, binary is shipped together with GHC, so I don't want to add dependencies which are not strictly required.Lennart Kolmodinhttps://www.blogger.com/profile/11472900998358020886noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-16004038615294638912013-04-30T07:01:41.826+04:002013-04-30T07:01:41.826+04:00Have you thought of using the operational package ...Have you thought of using the operational package to solve the problem of the sufficient input left? You could reify the monad and obtain something like an AST of the parser. Although I don't know about the performance of the solution.<br />fmastehttps://www.blogger.com/profile/05489262070099785692noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-42994993195897505162013-03-03T20:50:27.797+04:002013-03-03T20:50:27.797+04:00binary is now using continuation-passing style, wh...binary is now using continuation-passing style, which GHC can generate efficient code from. The old binary was a state monad.<br /><br />binary-0.7 seems to be as fast as binary-0.5, never slower, and at times up to 5x faster (or even more in some extreme cases).<br />Of course, to see a large speedup it requires that your code is already quite tuned. If the biggest cost in your decoder is not the code from binary, then even binary-0.7 won't make it faster.<br /><br />So, it seems the error reporting comes for free.Lennart Kolmodinhttps://www.blogger.com/profile/11472900998358020886noreply@blogger.comtag:blogger.com,1999:blog-8761623568109455093.post-39985999189538275802013-03-03T17:56:59.696+04:002013-03-03T17:56:59.696+04:00How does the performance compare to binary-0.5? is...How does the performance compare to binary-0.5? is the better error reporting costing much?Andrea Vezzosihttps://www.blogger.com/profile/07314943153376710289noreply@blogger.com