mpl VS completely-unscientific-benchmarks

I'm one of the authors of this work -- I can explain a little.

"Provably efficient" means that the language provides worst-case performance guarantees.

For example in the "Automatic Parallelism Management" paper (https://dl.acm.org/doi/10.1145/3632880), we develop a compiler and run-time system that can execute extremely fine-grained parallel code without losing performance. (Concretely, imagine tiny tasks of around only 10-100 instructions each.)

The key idea is to make sure that any task which is *too tiny* is executed sequentially instead of in parallel. To make this happen, we use a scheduler that runs in the background during execution. It is the scheduler's job to decide on-the-fly which tasks should be sequentialized and which tasks should be "promoted" into actual threads that can run in parallel. Intuitively, each promotion incurs a cost, but also exposes parallelism.

In the paper, we present our scheduler and prove a worst-case performance bound. We specifically show that the total overhead of promotion will be at most a small constant factor (e.g., 1% overhead), and also that the theoretical amount of parallelism is unaffected, asymptotically.

All of this is implemented in MaPLe (https://github.com/mpllang/mpl) and you can go play with it now!

Maple is a fork of MLton: https://github.com/MPLLang/mpl

Some of us are still using SML for research and teaching, e.g. https://github.com/mpllang/mpl

Not true. Visit the repositorium and see the benchmark results: https://github.com/frol/completely-unscientific-benchmarks

Well we had some fun with https://github.com/frol/completely-unscientific-benchmarks. Although that's a while ago and it seems like the C versions have managed to pull ahead since then.