[Caml-list] Performance penalty for using monad

[Caml-list] Performance penalty for using monad

[Helmut Brandl]

I want to restructure my project using monads (reader, state, option, etc.) in order to get cleaner code.

Is there any performance penalty to pay. From my understanding there shouldn’t be any or only very little since aggressive inlining should be able to compile the monads away.

Is there any experience on how the optimizing ocaml compiler is able to optimize monadic code?

Regards
Helmut

Re: [Caml-list] Performance penalty for using monad

[Yotam Barnoy]

You might find this
(https://discuss.ocaml.org/t/ann-monads-the-missing-monad-transformers-library/830/8)
discussion relevant.

On Mon, Sep 18, 2017 at 11:23 AM, Helmut Brandl <helmut.brandl@gmx.net> wrote:
> I want to restructure my project using monads (reader, state, option, etc.) in order to get cleaner code.
>
> Is there any performance penalty to pay. From my understanding there shouldn’t be any or only very little since aggressive inlining should be able to compile the monads away.
>
> Is there any experience on how the optimizing ocaml compiler is able to optimize monadic code?
>
> Regards
> Helmut
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Performance penalty for using monad

[Helmut Brandl]

Thanks for the hint

Helmut
> On Sep 18, 2017, at 10:31, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> 
> You might find this
> (https://discuss.ocaml.org/t/ann-monads-the-missing-monad-transformers-library/830/8)
> discussion relevant.
> 
> On Mon, Sep 18, 2017 at 11:23 AM, Helmut Brandl <helmut.brandl@gmx.net> wrote:
>> I want to restructure my project using monads (reader, state, option, etc.) in order to get cleaner code.
>> 
>> Is there any performance penalty to pay. From my understanding there shouldn’t be any or only very little since aggressive inlining should be able to compile the monads away.
>> 
>> Is there any experience on how the optimizing ocaml compiler is able to optimize monadic code?
>> 
>> Regards
>> Helmut
>> 
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Performance penalty for using monad

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

It was some time ago, but I was toying with an encoder/decoder for the
"Transit" format (of Clojure/Cognitect fame). That decoder used monads
heavily as well, and flambda provided roughly an order of magnitude speedup
(and a lower GC pressure as well in addition). It was enough that I made a
mental note of using flambda if this ever went into a system with high
throughput requirements.

On Tue, Sep 19, 2017 at 2:47 PM Helmut Brandl <helmut.brandl@gmx.net> wrote:

> Thanks for the hint
>
> Helmut
> > On Sep 18, 2017, at 10:31, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> >
> > You might find this
> > (
> https://discuss.ocaml.org/t/ann-monads-the-missing-monad-transformers-library/830/8
> )
> > discussion relevant.
> >
> > On Mon, Sep 18, 2017 at 11:23 AM, Helmut Brandl <helmut.brandl@gmx.net>
> wrote:
> >> I want to restructure my project using monads (reader, state, option,
> etc.) in order to get cleaner code.
> >>
> >> Is there any performance penalty to pay. From my understanding there
> shouldn’t be any or only very little since aggressive inlining should be
> able to compile the monads away.
> >>
> >> Is there any experience on how the optimizing ocaml compiler is able to
> optimize monadic code?
> >>
> >> Regards
> >> Helmut
> >>
> >> --
> >> Caml-list mailing list.  Subscription management and archives:
> >> https://sympa.inria.fr/sympa/arc/caml-list
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 3526 bytes --]

Re: [Caml-list] Performance penalty for using monad

[Helmut Brandl]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

One more question: It seems that flambda is necessary in order to optimize monadic code. Is there a plan that flambda will be included in a base release of ocaml? 

Up to now all base releases like 4.03.0, 4.04.0, etc. do not include flambda. I have to request the extension if I want it.

Helmut


> On Sep 19, 2017, at 08:24, Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:
> 
> It was some time ago, but I was toying with an encoder/decoder for the "Transit" format (of Clojure/Cognitect fame). That decoder used monads heavily as well, and flambda provided roughly an order of magnitude speedup (and a lower GC pressure as well in addition). It was enough that I made a mental note of using flambda if this ever went into a system with high throughput requirements.
> 
> On Tue, Sep 19, 2017 at 2:47 PM Helmut Brandl <helmut.brandl@gmx.net <mailto:helmut.brandl@gmx.net>> wrote:
> Thanks for the hint
> 
> Helmut
> > On Sep 18, 2017, at 10:31, Yotam Barnoy <yotambarnoy@gmail.com <mailto:yotambarnoy@gmail.com>> wrote:
> >
> > You might find this
> > (https://discuss.ocaml.org/t/ann-monads-the-missing-monad-transformers-library/830/8 <https://discuss.ocaml.org/t/ann-monads-the-missing-monad-transformers-library/830/8>)
> > discussion relevant.
> >
> > On Mon, Sep 18, 2017 at 11:23 AM, Helmut Brandl <helmut.brandl@gmx.net <mailto:helmut.brandl@gmx.net>> wrote:
> >> I want to restructure my project using monads (reader, state, option, etc.) in order to get cleaner code.
> >>
> >> Is there any performance penalty to pay. From my understanding there shouldn’t be any or only very little since aggressive inlining should be able to compile the monads away.
> >>
> >> Is there any experience on how the optimizing ocaml compiler is able to optimize monadic code?
> >>
> >> Regards
> >> Helmut
> >>
> >> --
> >> Caml-list mailing list.  Subscription management and archives:
> >> https://sympa.inria.fr/sympa/arc/caml-list <https://sympa.inria.fr/sympa/arc/caml-list>
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners <http://groups.yahoo.com/group/ocaml_beginners>
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs <http://caml.inria.fr/bin/caml-bugs>
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list <https://sympa.inria.fr/sympa/arc/caml-list>
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners <http://groups.yahoo.com/group/ocaml_beginners>
> > Bug reports: http://caml.inria.fr/bin/caml-bugs <http://caml.inria.fr/bin/caml-bugs>
> 
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list <https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners <http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-bugs <http://caml.inria.fr/bin/caml-bugs>

[-- Attachment #2: Type: text/html, Size: 4986 bytes --]

RE: [Caml-list] Performance penalty for using monad

[David Allsopp]

Helmut Brandl wrote:
> One more question: It seems that flambda is necessary in order to optimize
> monadic code. Is there a plan that flambda will be included in a base 
> release of ocaml? 
> 
> Up to now all base releases like 4.03.0, 4.04.0, etc. do not include
> flambda. I have to request the extension if I want it.

flambda work is still ongoing (work-in-progress sounds a bit mean - it's more that it's still evolving!) and it's not yet in a position to be enabled by default. This is the ultimate plan, though there is no nominated version at which we yet expect to make it the default.

Jesper Louis Anderson wrote:
> That decoder used monads heavily as well, and flambda provided roughly 
> an order of magnitude speedup (and a lower GC pressure as well in addition).
> It was enough that I made a mental note of using flambda if this ever went
> into a system with high throughput requirements.

Just for added interest, there are things being worked on in opam 2 which should allow you to be able to declare such a package as either needing an OCaml compiler with flambda enabled or which would let you display a warning message if the package is installed in a compiler which doesn't have flambda enabled.


David

Re: [Caml-list] Performance penalty for using monad

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On Sun, Sep 24, 2017 at 5:22 AM, David Allsopp <dra-news@metastack.com>
wrote:

> Helmut Brandl wrote:
> > One more question: It seems that flambda is necessary in order to
> optimize
> > monadic code. Is there a plan that flambda will be included in a base
> > release of ocaml?
> >
> > Up to now all base releases like 4.03.0, 4.04.0, etc. do not include
> > flambda. I have to request the extension if I want it.
>
> flambda work is still ongoing (work-in-progress sounds a bit mean - it's
> more that it's still evolving!) and it's not yet in a position to be
> enabled by default. This is the ultimate plan, though there is no nominated
> version at which we yet expect to make it the default.


For what it's worth, the main blocker for us turning Flambda on by default
in classic mode is getting build artifact size and compilation speed down
basically to the same level as closure-compilation. We're getting pretty
close to that goal, though it will take a bit more time to get the
improvements in question upstreamed.

So getting Flambda enabled by default isn't that far away (though most of
the real benefits will require -O3, which will still lengthen compilation
by quite a bit.)


>
> Jesper Louis Anderson wrote:
> > That decoder used monads heavily as well, and flambda provided roughly
> > an order of magnitude speedup (and a lower GC pressure as well in
> addition).
> > It was enough that I made a mental note of using flambda if this ever
> went
> > into a system with high throughput requirements.
>
> Just for added interest, there are things being worked on in opam 2 which
> should allow you to be able to declare such a package as either needing an
> OCaml compiler with flambda enabled or which would let you display a
> warning message if the package is installed in a compiler which doesn't
> have flambda enabled.
>
>
> David
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3102 bytes --]

Re: [Caml-list] Performance penalty for using monad

[Josh Berdine]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Sep 24, 2017, at 12:28 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
> For what it's worth, the main blocker for us turning Flambda on by default in classic mode is getting build artifact size and compilation speed down basically to the same level as closure-compilation. We're getting pretty close to that goal, though it will take a bit more time to get the improvements in question upstreamed.
> 
> So getting Flambda enabled by default isn't that far away (though most of the real benefits will require -O3, which will still lengthen compilation by quite a bit.)

Another data point on this: at facebook we recently switched the production infer binaries over to flambda -O3 (https://github.com/facebook/infer/commit/f8d7c810452ce3a4d2e7027e38f5d00426a2a917 <https://github.com/facebook/infer/commit/f8d7c810452ce3a4d2e7027e38f5d00426a2a917>). For local builds during development, we usually build without flambda, or actually even just bytecode. But for infer, flambda -O3 is worth 15-20% elapsed (~25% cpu) time, so it does not take an abnormal analysis run before that pays off the ~5x compile time deficit. (Given that we have to distribute a custom clang with the analyzer, build artifact size is basically in the noise.)

Cheers, Josh


[-- Attachment #2: Type: text/html, Size: 1868 bytes --]

Re: [Caml-list] Performance penalty for using monad

[Mark Shinwell]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

I would also point out that Facebook's experience with compilation speed
under Flambda is actually rather worse than what we've found at Jane
Street.  We are typically seeing closer to 2.5x rather than 5x at -O3.
However we are working to reduce this further.

Mark

On 24 September 2017 at 21:04, Josh Berdine <josh@berdine.net> wrote:

> On Sep 24, 2017, at 12:28 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
>
> For what it's worth, the main blocker for us turning Flambda on by default
> in classic mode is getting build artifact size and compilation speed down
> basically to the same level as closure-compilation. We're getting pretty
> close to that goal, though it will take a bit more time to get the
> improvements in question upstreamed.
>
> So getting Flambda enabled by default isn't that far away (though most of
> the real benefits will require -O3, which will still lengthen compilation
> by quite a bit.)
>
>
> Another data point on this: at facebook we recently switched the
> production infer binaries over to flambda -O3 (
> https://github.com/facebook/infer/commit/f8d7c810452ce3a4d2e7027e38f5d0
> 0426a2a917). For local builds during development, we usually build
> without flambda, or actually even just bytecode. But for infer, flambda -O3
> is worth 15-20% elapsed (~25% cpu) time, so it does not take an abnormal
> analysis run before that pays off the ~5x compile time deficit. (Given that
> we have to distribute a custom clang with the analyzer, build artifact size
> is basically in the noise.)
>
> Cheers, Josh
>
>

[-- Attachment #2: Type: text/html, Size: 2327 bytes --]

Re: [Caml-list] Performance penalty for using monad

[Josh Berdine]

On Sep 25, 2017, at 9:32 AM, Mark Shinwell <mshinwell@janestreet.com> wrote:
> 
> I would also point out that Facebook's experience with compilation speed under Flambda is actually rather worse than what we've found at Jane Street.  We are typically seeing closer to 2.5x rather than 5x at -O3. 

Good point. We have some generated code that might be a bit pathological, and basically compile everything together, which might be suboptimal.

The main point is that the performance gains are so substantial that everyone with code whose performance matters owes it to themselves to try flambda -O3 and see what the trade-off is for them.

Cheers, Josh