7 ms·

By definition OCaml's entire userbase consists of programs that run on a single core, so a 10% regression in single core performance is going to be a pretty har

By definition OCaml's entire userbase consists of programs that run on a single core, so a 10% regression in single core performance is going to be a pretty hard sell.

nerpderp82 7y ago
I would argue that single core only OCaml could be released in parallel (heh) with a multicore OCaml. Legacy users could opt for the single core runtime distribution. As soon as you get parallel gc, MPMC queues, parallel sorting, set intersection, etc. Many programs will see about a 1.x speed up making the point moot. Erlang went through this same transition.
- YawningAngel 7y ago
  Maintaining two parallel distributions is a lot of work for a relatively niche language with a small community.
  - nerpderp82 7y ago
    One build has locks, the other does not. If OCaml wants to remain somewhat viable it will need to be able to use more than one core. The most users of OCaml is always right now. This won't always be the case if they cannot go multicore.
- pdimitar 7y ago
  Can you expand on the Erlang history? Really interesting.
monadic2 7y ago
Presumably if performance were a key concern you wouldn't have used OCaml to begin with.
- LeonidasXIV 7y ago
  Curious claim, considering OCaml fares pretty well in many language comparison benchmarks.
  - jfkebwjsbx 7y ago
    Language comparison benchmarks are a tiny part of actual performance in the real world.
    - LeonidasXIV 7y ago
      They do translate into real-life performance though and unlike many other languages, for the most part without "writing C in language X".
      - jfkebwjsbx 7y ago
        Extraordinary claims require extraordinary evidence. Claiming a functional language is as performant as a systems language is a very big claim.
        patrec 7y ago
        What's a "systems language"? Someone recently posted "awk as a major systems programming language". Ocaml is used in many performance and latency sensitive domains as a minimal amount of research would show you. Here's an example: https://www.janestreet.com/tech-talks/building-an-exchange/ https://www.janestreet.com/tech-talks/building-an-exchange/ It's also got a reputation for pretty predictable performance characteristics, fast compilation and ease of writing correct and concise code, properties C++, for example, does not necessarily share. Part of this is because the compiler is comparatively straightforward in what it does (and same for standard library), with the flip side that you leave some performance on the table. But that might not be a bad trade-off given that ocaml generally seems to be within a factor of ~3x of C++ (which can probably easily baloon up for specific problems, given that ocaml has e.g. poor SIMD and machine size int support). So you probably wouldn't want to write AAA game engines, crypto libs or numerical kernels in it. But my guess is that a language with those characteristics (and much faster iteration times) translates to better real world performance for many other types of tasks.

By definition OCaml's entire userbase consists of programs that run on a single core, so a 10% regression in single core performance is going to be a pretty hard sell.

nerpderp82 7y ago

I would argue that single core only OCaml could be released in parallel (heh) with a multicore OCaml. Legacy users could opt for the single core runtime distribution. As soon as you get parallel gc, MPMC queues, parallel sorting, set intersection, etc. Many programs will see about a 1.x speed up making the point moot. Erlang went through this same transition.

YawningAngel 7y ago
Maintaining two parallel distributions is a lot of work for a relatively niche language with a small community.
- nerpderp82 7y ago
  One build has locks, the other does not. If OCaml wants to remain somewhat viable it will need to be able to use more than one core. The most users of OCaml is always right now. This won't always be the case if they cannot go multicore.
pdimitar 7y ago
Can you expand on the Erlang history? Really interesting.

monadic2 7y ago

Presumably if performance were a key concern you wouldn't have used OCaml to begin with.

LeonidasXIV 7y ago
Curious claim, considering OCaml fares pretty well in many language comparison benchmarks.
- jfkebwjsbx 7y ago
  Language comparison benchmarks are a tiny part of actual performance in the real world.
  - LeonidasXIV 7y ago
    They do translate into real-life performance though and unlike many other languages, for the most part without "writing C in language X".
    - jfkebwjsbx 7y ago
      Extraordinary claims require extraordinary evidence. Claiming a functional language is as performant as a systems language is a very big claim.
      - patrec 7y ago
        What's a "systems language"? Someone recently posted "awk as a major systems programming language". Ocaml is used in many performance and latency sensitive domains as a minimal amount of research would show you. Here's an example: https://www.janestreet.com/tech-talks/building-an-exchange/ https://www.janestreet.com/tech-talks/building-an-exchange/ It's also got a reputation for pretty predictable performance characteristics, fast compilation and ease of writing correct and concise code, properties C++, for example, does not necessarily share. Part of this is because the compiler is comparatively straightforward in what it does (and same for standard library), with the flip side that you leave some performance on the table. But that might not be a bad trade-off given that ocaml generally seems to be within a factor of ~3x of C++ (which can probably easily baloon up for specific problems, given that ocaml has e.g. poor SIMD and machine size int support). So you probably wouldn't want to write AAA game engines, crypto libs or numerical kernels in it. But my guess is that a language with those characteristics (and much faster iteration times) translates to better real world performance for many other types of tasks.