Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Haskell is beautiful and mind-bending, but to get close to C in any non-trivial problem, you will end up writing imperative code. We have 4 implementations of a graph algorithm:

a) Idiomatic Haskell takes ~25 minutes

b) Monadic Haskell takes 11 seconds

c) C++ takes 3 seconds

d) C takes 1 seconds (5x less memory than b))

If you look at all the micro-benchmarks, C uses far less memory than Java or Haskell and the memory is the bottleneck in the most cases.

This is the reason why HPC is FORTRAN, C and C++.

Reference: Computational Topology via Functional Programming: A Baseline Analysis



2 Things.

1. I don't think Monadic == Imperative...

2. Can you post the Haskell code?


>but to get close to C in any non-trivial problem, you will end up writing imperative code.

I know that's not true because I do it on a regular basis. For problems that require writing imperative code you end up writing imperative code. This is not a problem, writing imperative code in haskell is far nice than writing it in C.

>Monadic Haskell takes 11 seconds

"Monadic Haskell" is meaningless when making performance claims. If you want help fixing your code, you need to post it. And idiomatic haskell uses monads all the time. Is this another case of the common "I am pretending that deliberately doing things the slowest way possible is the definition of idiomatic" trolling?

>C takes 1 seconds

If your C++ is taking 3x as long as your C you are doing something wrong.


Can you give an example of the code you write which is on par with C in terms of speed and is non-trivial? Did you look up the algorithm? (it is perfectly defined recursively) Arguing what is nicer is subjective.

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.


Often obvious recursive algorithms aren't well-optimized by GHC. This might be the kind of "bend over backwards" coding you're talking about, though.

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.


I'm not going to go buy a book just so I can spend the time writing code for you to dismiss as "oh that's not idiomatic haskell". Are you saying you don't actually know and are just repeating the claims made by the authors? Do you know haskell?


>* Are you saying you don't actually know and are just repeating the claims made by the authors?*

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".


I believe the answer to your question lies in what Tel said:

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.


Wow, I just noticed the name and saw that all these empty shitposts are the same person.

>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.


"shitposts", "appaling dishonesty", "desire to see my own words", no "ability to sting words in a constructive manner", etc.

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 these were aimed at at the parent:

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.


>Yes, that is what questions are for.

Then don't make them all be passive agressive.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: