Brian,
Thanks for your response. I realize that the cost will be very
application-dependent, which is why I'm seeking other's practical
experience programming with these techniques, particularly for stacked
monad transformers involving simple monads (e.g. for interpreted
languages).
I can relay a little of my own practical experience in writing a
monadic parser for a character-oriented grammar -- it is not
practical. The performance was at least an order-of-magnitude worse
than the yacc-based parser I later wrote. (Although the idea I was
just pointed at of using metaocaml for this would seem to offer the
best of both worlds: http://www.cas.mcmaster.ca/~carette/publications/scp_metamonads.pdf)
Warren
On Jun 21, 2008, at 7:32 PM, Brian Hurt wrote:
On Sat, 21 Jun 2008, Warren Harris wrote:
I'm considering writing a moderate sized program with high
performance needs in a monad / monad transformer style in ocaml.
Although I believe that this abstraction will offer me benefits in
hiding some complexity, some of the monad transformers I would like
to "stack" are quite simple (e.g. a state-transition monad), and
I'm concerned that my program will be paying a high performance
cost due to high function call overhead -- ones which cannot be
optimized away due to module boundaries.
The performance hit of monads are two-fold: 1) generally, bind
requires an allocation, and 2) functorization and partial
application defeat inlining, and require more expensive call
semantics (basically, you end up having to call caml_applyn where
normally you'd just directly call, or even jump to, the function in
question).
How much of a penalty this is depends upon how often the monad layer
is invoked, or how much work is performed per bind. If the cost of
a bind is, say, 10 clocks, and on average you're doing a bind every
20 clocks, that's a huge hit- perfomance just dropped by a factor of
50%. But if you only bind every 200 clocks, then it's only a 5%
hit, and it is much less a big deal. I pull these numbers out of me
rear end, but they're probably vaguely close to correct.
The point is that it's impossible to generally state what the
performance hit of monads are, because that's dependent upon how
they're used.
For performance-sensitive code, I'd probably stay away from higher
level abstractions. On the other hand, I'd also consider how
performance sensitive the code really is- we programmers have a bad
habit of wanting to assume that all code needs to be tuned to within
an inch of it's life- but the reality is hardly any code needs to be
tuned at all (witness the popularity of languages like Ruby, Python,
and PHP- all of which make Java look like greased lightning).
Brian
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs