Why are monads so slow?

Why are monads so slow?

Just to get a taste of this Haskell fad, I conjured up this little benchmark:
http://pastebin.com/qgxnGaj6
It increments an integer ten thousand times in three different monads and then in a pure function.
First of all I must say that monad transformers are a bitch. It was really confusing to figure out what to lift, what not to lift, and in what order to unwrap them.
Second: I expected monad transformers to be slow, but I had hoped that at least the monads in GHC were optimized by now. After all, every Haskell program is a monad, how can you not make sure they're as tight as possible?


benchmarking Foo:
mean: 54.06153 us,
benchmarking Bar:
mean: 59.34639 us
benchmarking Baz:
mean: 392.4655 us
benchmarking Pure:
mean: 5.737042 us

The results are very dissatisfying. Monads are not only ugly and hard to work with, but they're also slow. IO-monadic code is approx. 10 times slower than pure code. Adding a StateT doesn't make things much worse, but a RWST more and your code is 6 more times slower, for a total of 60x slowdown over non-monadic code! Haskell is simply pathetic.

http://www.youtube.com/watch?v=zMTbFSJ_Tr4

>>2
Meet Tesak, a kike who used to pose as an antisemite, then posed as an antipedophile, then as an anti-gay. A professional Jew fascist, in other words.
He was recently arrested on Cuba, by the way. I hope he rots in jail.

>>1`
>2015-1
>not embracing the monomorphism restriction
back to /g/

>>3
who's beating the faggot is irrelevant. The faggot got what he deserved. Kikes, sandniggers, niggers, everybody is welcome in this game.

http://carlo-hamalainen.net/blog/2011/2/11/parsing-with-monads-can-be-slow

http://www.valuedlessons.com/2008/03/why-are-my-monads-so-slow.html

Well, I've improved my program, adding another test for a pure computation with an ST mutable state inside:

http://ideone.com/xFLDoE

You can compile it with "ghc -O2 --make Main.hs" and then run with "./Make -t win -u res.csv".

The results are appalling. The ST monad, which was supposed to be all about mutable speed without any IO overhead, turned out to be even slower than IO!

IO                  51 us
IO with StateT      57 us
IO + StateT + RWST 352 us
Pure                 6 us
Pure with ST         199 us

That's about 33x slowdown just for using mutable state! Haskell is really amazing at avoiding success.

>>6
>>7
Those examples are about slow code that uses monads. My benchmark is about how all code that uses monads is slow, i.e. about the inevitable overhead of using monads.

Increased the number of iterations tenfold and the IO monad got 50 times slower! The monadic overhead has a larger than linear complexity! All of that without me using any complex control patterns or custom monads, just the standard library functions, monads and monad transformers.
Dang, Haskell was really created for idiots.

>>8
Supposedly, GHC 7.8 (RC) fixes a lot of IO overhead, especially for mulithreaded programs.

"avoid $ success at all costs"

http://www.youtube.com/watch?v=6zWf39lEkng&t=1m5s

Why is abstraction slow
Because it makes the CPU spend time executing a ton of unnecessary instructions.

>>1
Holy fuck that code is a clusterfuck. Literally what are you doing?

After all, every Haskell program is a monad,

Sounds like you don't know what a monad is.

>>13
Every Haskell program must contain a function "main" of type "IO a", IO is a monad, hence every Haskell program is a monad. He's right.

>>14
But not every monad is an IO monad. Under the hood, the IO data type is obviously treated differently than pure data types like Maybe.

You really should be bitching about the lazy IO not monads.

>>14
‘IO’ forms an instance of a monad given an appropriate definition of return and >>=. ‘IO a’ does not form an instance of a monad. ‘IO’ ≠ ‘IO a’. He's wrong. Also the main type is ‘IO ()’ which also makes you wrong.

Wow, Haskell is garbage.  Thank you for shining a light on this critical and under-reported issue, OP.

>>18
No, Haskell is king, and OP is a faggot.
A language without laziness is a language without abstractions.
A language without purity is a language where mutability and effects cannot be reasoned about.

>>19
Haha, look at this dumb who can't reason about mutable state!

>>19
purity
Shalom!

>>20
And neither can you, because it's imporrible. That's why imperative shit doesn't have any reasonable concurrency or parallelism.

>>22
Hello there, my name is FORTRAN and I think that you are a little wrong sir, me and my sisters ada and Oz have very good concurrency and parallelism!
also as far as I know erlang, a language with very good concurrency is not pure!

>>23
Just whom do you think you're kidding here? Fortran uses OpenMP crap, Ada uses semaphores and Erlang doesn't have shared state.

I've actually whipped out a book on parallel Ada and finding proof that it is a piece of shit was a snap:

"""
When the task currently executing within the protected object completes the body of the protected procedure, it will leave the object and the read/write lock will become inactive. At that point one of the other tasks will start its desired operation and activate a lock. Which of those many delayed tasks is selected is not defined by the core language.
"""

"""
The two locks provide mutually exclusive read/write access and mutually exclusive read access to the data within the protected object. As tasks may be delayed by these locks, it is important to keep the code in the bodies of protected procedures and functions (the critical sections) as short as
possible. Locks do not provide any synchronization. It is possible, therefore, that a group of reader tasks executing protected functions can starve writer tasks wanting to execute protected procedures. One can imagine from Figure 4.2
the possibility of newly arriving reader tasks replacing departing reader tasks, delaying those tasks that need the read/write access provided by the protected procedures.
"""

>>24
Just whom do you think you're kidding here?
Ada allows message passing, most compilers for Fortran make automatic paralelisation and why should I care about shared state?

I forgot to add that mutable state is not the same as shared state so >>24 is wrong

>>26
Obviously, mutable shared state is what the problem of concurrency is about. If the state is immutable, or not shared, then there is no problem, but that's not a solution, just an evasion..

>>27
In erlang there is mutable state but there is not shared state (actor models is awesome!), so there is not really a problem

>>22
concurrent ml is pretty reasonable :'(

i typed sage in the wrong box guys

>>29-30
>le pedophile fail sage

>>22
Look, it's simple. You have a variable, and you update it, and now it has a different value. Kid's level stuff.
Then you fire up a couple of threads, and boom! Concurrency and parallelism!