To clarify, I did not write the code (mine is the C version), the results are from the paper. Read it, beat it and post results.
To clarify, I did not write the code (mine is the C version), the results are from the paper. Read it, beat it and post results.
The way you can escape from this performance trap is to (as usual) write explicit state passing instead of direct recursion. GHC can inline and fuse these away much more nicely and often arrives at a very tight, C-like inner loop.
I'm not sure if I call this bending over backwards though since Haskell style has always been to avoid explicit recursion and this kind of state-passing transform can be hidden behind the same set of combinators you're used to.
No, he gives reference.
>Do you know haskell?
Can you support your claims? Surely the burden on proof is on "Haskell is just as fast".
>No, he gives reference.
Why are you speaking to what someone else knows? Your desire to see your own words exceeds your ability to string together words in a constructive manner.
>Can you support your claims? Surely the burden on proof is on "Haskell is just as fast".
I made no such claim. Your dishonesty is appalling.
Those were aimed at me.
And these were aimed at at the parent:
"you don't actually know", "are just repeating the claims made by the authors", "do you know haskell?", "trolling", "you are doing something wrong".
Plus condescending responses like "if you want you code fixed" and "I'm not going to buy a book just so I can spend the time writing code for you to dismiss" -- when given a reference by the parent. I only intervened because I didn't like your constant condescending tone.
Are you actually here to discuss, or you just came to insult people? If it's the second, maybe try Reddit?
And they were questions.
>Are you actually here to discuss
Yes, that is what questions are for. Why are you here? You don't seem to have any intention of trying to contribute in a productive manner.
Then don't make them all be passive agressive.
https://news.ycombinator.com/item?id=8671889
If you avoid recursion and use explicit state passing and create an API with combinators hiding the state passing plumbing you get very fast Haskell.
I believe many people never get to the "write combinators to hide plumbing" part and assume to get very fast Haskell they have to duplicate the explicit state passing everywhere.