
A better inliner for OCaml, and why it matters - ch
https://blogs.janestreet.com/flambda/
======
vegabook
I love Ocaml but have ditched it for Erlang/Elixir, losing a lot of elegance
on the way, but massively gaining on horizontal scalability and pragmatism. I
would love to stay with Ocaml but there just isn't enough of a clear roadmap
to it on multicore (seemingly fraught with controversy within the community),
or even multi-node distributed computing that does not require me to reverse
engineer someone's 10-year-old, badly documented thesis project. I almost feel
like the Ocaml project is stuck optimizing a single-core past, and that it
might be better to devise a new Ocaml-based language altogether, designed from
the ground up for distributed computing. I'd be there immediately.

~~~
rixed
This is not clear. Multicore and distributed computing are unrelated at best.
To make it clearer, can you explain what you are doing in erlang that you
couldn't do in ocaml?

~~~
vegabook
I am message passing thousands of financial ticks per second to hundreds of
terminal-user consumers, each of which may wish to preselect filters that they
wish applied to each series, or combinations of series. This is trivially easy
to organize in Erlang/OTP, it is trivially easy to scale, and I have no clue
how I would organize it in Ocaml without going to message passing first
principles, and in which case I would have to build the entire load balancing,
PID and security infrastructure from scratch. Moreover I do not see how you do
not see that multicore and multi-node are related. On Erlang, having two
8-core boxes is almost the same as having one 16-core box. Again, if there is
something I am missing about the Ocaml environment I would be happy to know
about it.

~~~
wyager
You may be interested in Cloud Haskell. It's basically Erlang networking
nicely re-implemented in Haskell with the strong static typing you expect from
Haskell. Gets you some of the advantages of both erlang and ocaml.

~~~
elihu
For what it's worth, "Cloud Haskell", the project, corresponds to the
distributed-process library, which may be easier to search for than cloud
Haskell. The API is described in chapter 14 of Parallel and Concurrent
Programming in Haskell, by Simon Marlow. (I haven't been paying close
attention to the distributed-process library, so I don't know whether that
chapter is up-to-date with recent versions of the library.)

~~~
wyager
Interesting. I actually have that book on my shelf, but haven't gotten around
to reading it yet. I'll check it out.

------
mwcampbell
I wonder what kind of impact this will have on the performance of Mirage. It
seems to me that whole-program optimization is potentially a great benefit for
a unikernel written almost entirely in a high-level language like OCaml.

~~~
wk_end
To be clear, I don't believe flambda is providing anything on the scale of
whole program optimization; it inlines more aggressively, but not the entire
program.

~~~
Drup
That is not exactly correct, it also does cross module inlining. Now, suppose
you tweak a bit your parameters to inline ... liberally. It's going to inline
all the mirage functors directly into your main, which enables various things.

Of course, that's going to take a bit of time to compile.

Also, IIRC, all the ingredients are in place for link time optimizations, but
they were not developed for ocaml 4.03.

------
cm3
What about dead code elimination? A simple executable using Core is >20MB.

~~~
lpw25
The size of Core executables is mostly addressed by module aliases.
Unfortunately the public release of Core still uses packing instead of module
aliases because oasis/ocamlbuild don't easily support them.

~~~
cm3
Slightly off-topic, but will there be a consolidation of oasis, ocamlbuild,
corebuild, to go with opam?

------
tempodox
I'm really looking forward to modular implicits. Having something like Haskell
type classes is a great tool for abstraction.

