3 ms·

At least OCaml and Haskell compile into the native code, thus faster by definition.

by xvilka 6y ago

tw25513397 6y ago
While it may be faster, the "by definition" part hasn't been true for years. The JVM can do some amazing stuff at runtime to outpace statically executed code. Regardless, their principles [1] make the trade-offs clear: - Developer productivity over runtime performance - Correctness over performance [1] https://flix.dev/principles/ https://flix.dev/principles/
jorkadeen 6y ago
I don't think that is true. For example, Java beats OCaml on some benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ocaml-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It seems that the situation is not as clear cut as your post suggests. (I am one of the authors of Flix)
- johnnycerberus 6y ago
  Has anyone tried runnig those benchmarks with AOT Java? Microbenchmarks like these tell absolutely nothing about general performance because they are short-lived. JVM is a beautiful piece of engineering and I believe you guys chose well this platform to host it, always hoped for a ML-inspired language running on the JVM and this looks like it.
  - igouy 6y ago
    > Has anyone tried runnig those benchmarks with AOT Java? Yes. GraalVM CE 20.0.0 and native-image. > …because they are short-lived. https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Because "general performance" is ill-defined. Because tiny tiny programs aren't like other programs.
coldtea 6y ago
At least this compiles to bytecode, so more interopabe with tons of libraries and Java tools and infrastructure by definition. There are lots of different goals and tradeoffs...
hibbelig 6y ago
I’m not an expert but my understanding is that modern JIT can be faster than ahead of time compilation because the JIT has runtime information, so you get profile guided optimization for free. Warm up takes a while but then it can be very fast. For long running servers this works quite well.

At least OCaml and Haskell compile into the native code, thus faster by definition.

by xvilka 6y ago

At least OCaml and Haskell compile into the native code, thus faster by definition.

While it may be faster, the "by definition" part hasn't been true for years. The JVM can do some amazing stuff at runtime to outpace statically executed code. Regardless, their principles [1] make the trade-offs clear: - Developer productivity over runtime performance - Correctness over performance [1] https://flix.dev/principles/ https://flix.dev/principles/

jorkadeen 6y ago

I don't think that is true. For example, Java beats OCaml on some benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ocaml-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It seems that the situation is not as clear cut as your post suggests. (I am one of the authors of Flix)

johnnycerberus 6y ago
Has anyone tried runnig those benchmarks with AOT Java? Microbenchmarks like these tell absolutely nothing about general performance because they are short-lived. JVM is a beautiful piece of engineering and I believe you guys chose well this platform to host it, always hoped for a ML-inspired language running on the JVM and this looks like it.
- igouy 6y ago
  > Has anyone tried runnig those benchmarks with AOT Java? Yes. GraalVM CE 20.0.0 and native-image. > …because they are short-lived. https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#jvm-startup-time https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Because "general performance" is ill-defined. Because tiny tiny programs aren't like other programs.

coldtea 6y ago

At least this compiles to bytecode, so more interopabe with tons of libraries and Java tools and infrastructure by definition. There are lots of different goals and tradeoffs...

hibbelig 6y ago

I’m not an expert but my understanding is that modern JIT can be faster than ahead of time compilation because the JIT has runtime information, so you get profile guided optimization for free. Warm up takes a while but then it can be very fast. For long running servers this works quite well.