4 ms·
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 debugg
by eatonphil 4y ago
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.
- frou_dh 4y agoAs 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
- shwestrick 4y agoMLton 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.
- cannam 4y agoMLton 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.
- hajile 4y agohttp://mlton.org/LLVMCodegen 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.
- cannam 4y agoIt 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.
- hawk_ 4y agoWhat's the FFI overhead like? And can you pass SML function pointers into C code as callbacks?
- cannam 4y ago> 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.
- cannam 4y agoI 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 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.
- ratmice 4y agoI 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.
- frou_dh 4y agoAnd you offer a nice selection of SML libraries on your GitHub https://github.com/cannam?tab=repositories&type=source&language=standard+ml https://github.com/cannam?tab=repositories&type=source&langu... - Thanks for that!
- yawaramin 4y ago> 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 :-)