Comment by eatonphil | Hacker News Reader

Comment by eatonphil | Hacker News Reader

The section on team size and funding w.r.t. Poly/ML, SML/NJ and OCaml is something.

Regarding Poly/ML (I'm quoting):

  * good performance and fantastic debugging tools
  * not merely “saving an image”, but sharable executable units, either including the Read-Eval-Print loop or standalone;
  * support for one hardware architecture after another (including Apple Silicon)
  * support for multi-threading (also here); they say that OCaml is finally catching up, 15 years later, thanks to having 100 times as much funding.

And:

> A mystery I shall never understand is the difference in performance between SML/NJ and Poly/ML. The former enjoyed vastly greater funding and had a strong team of developers compared with DCJM’s one-man show. Benchmarks I ran for my ML book consistently gave SML/NJ a big performance advantage. But with Isabelle, the strong performer was Poly/ML. Once David got parallelism working, Poly/ML’s advantage was so overwhelming that we dropped our long-standing policy of supporting both compilers.

As much of a gem as Poly/ML might be, I just use MLton* exclusively, because its .mlb aka MLBasis build-system seems by far the most sane way to actually make use of multiple source files when writing SML code.

*another gem

MLton also has perhaps the most impressive performance of any existing functional language implementation. It generates code that easily competes with hand-optimized low-level C/C++/whatever.

MLton can't do SIMD auto-vectorisation, which unfortunately gives it a ceiling significantly below C++ compilers for the sort of thing I do. I generally use FFI calls for chunky, frequently-used vector stuff. It's a good compiler generally.

http://mlton.org/LLVMCodegen

MLton can do it's whole program optimization then output to LLVM which I believe should then be able to do auto-vectorization.

It can also output to C, similarly. But vectorisable code isn't recognisable as such in the output. I'm pretty sure the compiler that handles MLton's output never sees anything to vectorise.

What's the FFI overhead like? And can you pass SML function pointers into C code as callbacks?

> What's the FFI overhead like?

I don't have measurements to hand, but vaguely speaking, low. Low enough to be worth using for even quite modest calls into vector functions or optimised libraries.

> And can you pass SML function pointers into C code as callbacks?

Yes. At least, you can declare a function statically for export as a callback. You can't pass arbitrary function values.

You can call C/C++ from SML, and call SML from C/C++ from SML - though some neat potential uses are ruled out as MLton (unlike Poly/ML) doesn't support native threads and you can't call back from a different thread from the caller.

You can also compile to a library using MLton and use that from a C/C++ program - again only from a single thread, but it doesn't have to be the program's main thread.

I also use .mlb files exclusively and agree with your general point - but I do make use of Poly/ML and occasionally SML/NJ against the same sources, using scripts to drive them from .mlb files: https://github.com/cannam/sml-buildscripts

These scripts are really limited. They only support the simplest .mlb files that are really just lists of other files, and the semantics are technically incorrect because they have no way to reset the environment when beginning each new .mlb file in, as the spec says they should. I use them scrappily during development and then generally use MLton for production builds. But you can get quite a lot done within those limitations, and it's very nice to have the faster compilation of Poly/ML, as well as the option of seeing error messages from more than one compiler.

I have always done the opposite using SML/NJ's CompilationManager, then deriving mlb with cm2mlb -D MLton (in the mlton repo), with mlton specific code then wrapped in #if (defined(MLton)).

That you can use CM as a library has always been really handy, but otherwise the same, using MLton for production builds.

And you offer a nice selection of SML libraries on your GitHub https://github.com/cannam?tab=repositories&type=source&langu... - Thanks for that!

> support for multi-threading (also here); they say that OCaml is finally catching up, 15 years later, thanks to having 100 times as much funding.

Yeah, because OCaml has millions of lines of production code in many deployments (including Xen i.e. Amazon EC2) so it can't just break backward-compatibility to introduce multicore, nor can it afford to slow down existing code. These are constraints that the various MLs don't have :-)

Reply on news.ycombinator.com