5 ms·

> not wanting to impact single core performance That seems like an over burdensome requirement given that we are swimming in cores. A 10% loss in single core p

> not wanting to impact single core performance That seems like an over burdensome requirement given that we are swimming in cores. A 10% loss in single core performance vs 1.2x-Nx multicore performance increase would be an adequate tradeoff. The only other option I can think of is having two different backends, one that is entirely single threaded and doesn't incur any multicore performance penalty.

dna_polymerase 7y ago
But I'd have to adapt my old code to more cores, and it isn't always easy to just split and distribute a workload onto more cores.
YawningAngel 7y ago
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.
owl57 7y ago
OCaml has an unusual share of latency-sensitive stakeholders, probably only comparable with Go of all garbage-collected languages. As far as I heard, optimizing Go's GC for latency has been an awful lot of work.
- dan-robertson 7y ago
  Any reasonably widely used language will have users who care about latency. People write user interfaces in Java so clearly it’s users care about latency. Similarly for JavaScript except I would expect a react user interface to produce a lot more allocation pressure than a java one (and so gc latency and throughput both matter). Even emacs lisp cares about latency (the main user visible improvement was not printing “garbage collected” each time the gc ran). For things like servers, latency can matter to some extent because of the resource usage of in-flight requests. It is desirable to serve requests quickly to free up resources on the server and any clients too. Similarly one will find plenty of apps which care about throughput too.
  - mumblemumble 7y ago
    > Any reasonably widely used language will have users who care about latency. Right, but, to the parent's point, OCaml, with its HFT pedigree, has an unusual level of latency sensitivity in its userbase. I can't speak for Jane Street, but, at the prop shop where I did my time, nobody found it all that peculiar to have major cross-company initiatives to, e.g., shave a couple bytes off a datagram format just to reduce some message's average latency by a fraction of a millisecond.
  - lmm 7y ago
    > People write user interfaces in Java so clearly it’s users care about latency. GUIs in Java are notoriously bad, and tend to only be used for internal tools (where good UX is not a priority), complex professional tools where functionality was a higher priority than UX, or open-source programs where the same thing is true. Another example is that Java is still an unpopular language for command-line tools that can be used from the shell, whereas OCaml is pretty popular in that use space. Any reasonably popular language will have someone using it for any given thing, sure - I'm sure there are people out there writing webapp backends in C or numerical batch processes in Ruby - but the core constituency can differ a lot between different languages, and that can (and should!) affect that language's priorities.
c-cube 7y ago
You don't just wave a magic wand and get your code parallelized, though. Some algorithms are quite hard to parallelize (and it seems OCaml's user base is full of these, like theorem provers and compilers). Remember Amdahl's law.

dna_polymerase 7y ago

But I'd have to adapt my old code to more cores, and it isn't always easy to just split and distribute a workload onto more cores.

YawningAngel 7y ago

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.

owl57 7y ago

OCaml has an unusual share of latency-sensitive stakeholders, probably only comparable with Go of all garbage-collected languages. As far as I heard, optimizing Go's GC for latency has been an awful lot of work.

dan-robertson 7y ago
Any reasonably widely used language will have users who care about latency. People write user interfaces in Java so clearly it’s users care about latency. Similarly for JavaScript except I would expect a react user interface to produce a lot more allocation pressure than a java one (and so gc latency and throughput both matter). Even emacs lisp cares about latency (the main user visible improvement was not printing “garbage collected” each time the gc ran). For things like servers, latency can matter to some extent because of the resource usage of in-flight requests. It is desirable to serve requests quickly to free up resources on the server and any clients too. Similarly one will find plenty of apps which care about throughput too.
- mumblemumble 7y ago
  > Any reasonably widely used language will have users who care about latency. Right, but, to the parent's point, OCaml, with its HFT pedigree, has an unusual level of latency sensitivity in its userbase. I can't speak for Jane Street, but, at the prop shop where I did my time, nobody found it all that peculiar to have major cross-company initiatives to, e.g., shave a couple bytes off a datagram format just to reduce some message's average latency by a fraction of a millisecond.
- lmm 7y ago
  > People write user interfaces in Java so clearly it’s users care about latency. GUIs in Java are notoriously bad, and tend to only be used for internal tools (where good UX is not a priority), complex professional tools where functionality was a higher priority than UX, or open-source programs where the same thing is true. Another example is that Java is still an unpopular language for command-line tools that can be used from the shell, whereas OCaml is pretty popular in that use space. Any reasonably popular language will have someone using it for any given thing, sure - I'm sure there are people out there writing webapp backends in C or numerical batch processes in Ruby - but the core constituency can differ a lot between different languages, and that can (and should!) affect that language's priorities.

c-cube 7y ago

You don't just wave a magic wand and get your code parallelized, though. Some algorithms are quite hard to parallelize (and it seems OCaml's user base is full of these, like theorem provers and compilers). Remember Amdahl's law.