6 ms·

OCaml compile speeds are not particularly fast.

by fnord123 5y ago

yawaramin 5y ago
Compared to what?
- fnord123 5y ago
  On par with Java but without maven startup time.
  - yawaramin 5y ago
    Admittedly I’m not citing actual numbers (but then again neither is anyone else here), but subjectively based on past experience, I highly doubt that. The OCaml compile is super parallelizable, with no forward references i.e. potential dependency cycles like in Java. My feeling is it blows Java out of the water.
  - pjmlp 5y ago
    You don't need Maven to compile Java code, additionally when using Eclipse incremental compiler, files are compiled on save.
dwohnitmok 5y ago
I'm curious do you have concrete data for this? I would love to see compile times for representative codebases of various sizes across languages and how they've changed across compiler versions. From anecdotal experience I view OCaml's bytecode compile speeds to be on par with Go's (as a rule of thumb I expect about 1 second per 10k lines). Far slower than something like TCC, but quite fast among other languages.
- fnord123 5y ago
  I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, running on identical machines. As for your view of OCaml byte code compilation speed being on par with Go seems rather unlikely or I'm misunderstanding what you mean. Go is not dealing with anywhere as near a complex type system as OCaml and generates a lot more potato machine code (usually not using -mnative so you can know you can copy a binary to arbitrary machines).
  - EduardoRFS 5y ago
    OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.
    - reecko 5y ago
      > OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
      - pjmlp 5y ago
        Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.
  - dwohnitmok 5y ago
    Hindley-Milner typechecking in practice is quite fast (as evidenced by ocamlc and Elm's compiler) and easily on par or faster than Go's typechecker (my rule of thumb for Elm code is usually 1 second per 100k lines). In general HM-based type systems are both conceptually quite simple and can have quite fast implementations. What makes them seem "complex" is that languages with HM-based type systems also tend to make it hard to "go around" the type system and enforce much more rigid discipline around how your code can be written.
    - throwaway894345 5y ago
      Isn’t pattern-matching alone combinatorial?
      - dwohnitmok 5y ago
        There's all sorts of terrifying exponential things that affect HM typechecking in theory (e.g. pattern matching exhaustivity checking as you mention is directly equivalent to SAT, although this is technically not a part of HM typechecking, it is a feature in practice for most HM-inspired languages). In practice it is actually very rare that they significantly affect compile times because it is very rare for the `n`-size to increase as the size of your codebase increases (these exponential blowups are generally limited to a single expression) for non-pathological code. Basically while you can have exponential blowups inside a single expression, I can't think of a time where you'll have exponential blowups across multiple expressions, which is what counts in a large codebase. One of the times where big-O analysis doesn't accurately predict real-world runtimes.
EduardoRFS 5y ago
OCaml is really good at building in parallel. So even without that many files it can still compile using 32 threads. Making so that a project with 20k loc is less than a second in debug mode. And recompile time in native(debug) mode is almost 100% linking time. For bytecode you can have wild rebuild times, in the milisecond range.
- fnord123 5y ago
  Pyre[1] is about 20k loc of ocaml[2]. $ time make -C source -j8 make: Entering directory '/home/fnord123/src/download/pyre-check/source' ../scripts/setup.sh --configure Build info: Linux x86_64 @ Mon Aug 23 2021 (development build) abort: no repository found in '/home/fnord123/src/download/pyre-check/source' (.hg not found)! Git commit: 1e4dd5a39db1631fd13a3a8df74d6e0f5d801fbc dune build @install -j auto --profile dev menhir parser/generator.{ml,mli} Warning: 31 states have shift/reduce conflicts. Warning: 5 states have reduce/reduce conflicts. Warning: 77 shift/reduce conflicts were arbitrarily resolved. Warning: 75 reduce/reduce conflicts were arbitrarily resolved. make: Leaving directory '/home/fnord123/src/download/pyre-check/source' real 0m43.700s user 4m3.030s sys 0m41.005s I must be doing something wrong. [1] https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [2] $ tokei ------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ------------------------------------------------------------------------------- Autoconf 2 235 204 3 28 C 15 242641 165361 60669 16611 C Header 10 14267 2617 11094 556 Coq 10 2391 1968 220 203 CSS 5 713 540 44 129 Dockerfile 2 71 42 11 18 HTML 2 35 30 0 5 INI 1 12 9 0 3 Java 31 2654 2080 267 307 JavaScript 7 867 752 61 54 JSON 17 939 939 0 0 Makefile 5 229 145 45 39 Markdown 47 7213 7213 0 0 OCaml 791 229096 198302 10455 20339 Python 398 61909 50119 2917 8873 Shell 5 111 59 34 18 SVG 2 2 2 0 0 TeX 4 929 642 129 158 Plain Text 5 457 457 0 0 TOML 1 2 2 0 0 TypeScript 2 130 84 20 26 ------------------------------------------------------------------------------- Total 1362 564903 431567 85969 47367 -------------------------------------------------------------------------------
zem 5y ago
compared to what? it's definitely one of the fastest-compiling languages i use.

OCaml compile speeds are not particularly fast.

yawaramin 5y ago

Compared to what?

fnord123 5y ago
On par with Java but without maven startup time.
- yawaramin 5y ago
  Admittedly I’m not citing actual numbers (but then again neither is anyone else here), but subjectively based on past experience, I highly doubt that. The OCaml compile is super parallelizable, with no forward references i.e. potential dependency cycles like in Java. My feeling is it blows Java out of the water.
- pjmlp 5y ago
  You don't need Maven to compile Java code, additionally when using Eclipse incremental compiler, files are compiled on save.

dwohnitmok 5y ago

I'm curious do you have concrete data for this? I would love to see compile times for representative codebases of various sizes across languages and how they've changed across compiler versions. From anecdotal experience I view OCaml's bytecode compile speeds to be on par with Go's (as a rule of thumb I expect about 1 second per 10k lines). Far slower than something like TCC, but quite fast among other languages.

fnord123 5y ago
I do not have concrete data for a comparison of like for like projects being compiled with comparable lines of code, and complexity of the type system usage, running on identical machines. As for your view of OCaml byte code compilation speed being on par with Go seems rather unlikely or I'm misunderstanding what you mean. Go is not dealing with anywhere as near a complex type system as OCaml and generates a lot more potato machine code (usually not using -mnative so you can know you can copy a binary to arbitrary machines).
- EduardoRFS 5y ago
  OCaml is much faster than Go in the bytecode mode, as you have interfaces files which drastically simplify the typing process. The compiling pipeline of bytecode is basically typing -> lambda -> bytegen Bytegen is really close to what Zinc does.
  - reecko 5y ago
    > OCaml is much faster than Go in the bytecode mode But doesn't the compiled code run slower in bytecode mode? I think that counts.
    - pjmlp 5y ago
      Sure it does, bytecode is meant for development not for production builds. The healthy mix of interpreter/JIT/AOT backends is what many languages miss on their toolchains.
- dwohnitmok 5y ago
  Hindley-Milner typechecking in practice is quite fast (as evidenced by ocamlc and Elm's compiler) and easily on par or faster than Go's typechecker (my rule of thumb for Elm code is usually 1 second per 100k lines). In general HM-based type systems are both conceptually quite simple and can have quite fast implementations. What makes them seem "complex" is that languages with HM-based type systems also tend to make it hard to "go around" the type system and enforce much more rigid discipline around how your code can be written.
  - throwaway894345 5y ago
    Isn’t pattern-matching alone combinatorial?
    - dwohnitmok 5y ago
      There's all sorts of terrifying exponential things that affect HM typechecking in theory (e.g. pattern matching exhaustivity checking as you mention is directly equivalent to SAT, although this is technically not a part of HM typechecking, it is a feature in practice for most HM-inspired languages). In practice it is actually very rare that they significantly affect compile times because it is very rare for the `n`-size to increase as the size of your codebase increases (these exponential blowups are generally limited to a single expression) for non-pathological code. Basically while you can have exponential blowups inside a single expression, I can't think of a time where you'll have exponential blowups across multiple expressions, which is what counts in a large codebase. One of the times where big-O analysis doesn't accurately predict real-world runtimes.

EduardoRFS 5y ago

OCaml is really good at building in parallel. So even without that many files it can still compile using 32 threads. Making so that a project with 20k loc is less than a second in debug mode. And recompile time in native(debug) mode is almost 100% linking time. For bytecode you can have wild rebuild times, in the milisecond range.

fnord123 5y ago
Pyre[1] is about 20k loc of ocaml[2]. $ time make -C source -j8 make: Entering directory '/home/fnord123/src/download/pyre-check/source' ../scripts/setup.sh --configure Build info: Linux x86_64 @ Mon Aug 23 2021 (development build) abort: no repository found in '/home/fnord123/src/download/pyre-check/source' (.hg not found)! Git commit: 1e4dd5a39db1631fd13a3a8df74d6e0f5d801fbc dune build @install -j auto --profile dev menhir parser/generator.{ml,mli} Warning: 31 states have shift/reduce conflicts. Warning: 5 states have reduce/reduce conflicts. Warning: 77 shift/reduce conflicts were arbitrarily resolved. Warning: 75 reduce/reduce conflicts were arbitrarily resolved. make: Leaving directory '/home/fnord123/src/download/pyre-check/source' real 0m43.700s user 4m3.030s sys 0m41.005s I must be doing something wrong. [1] https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [2] $ tokei ------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ------------------------------------------------------------------------------- Autoconf 2 235 204 3 28 C 15 242641 165361 60669 16611 C Header 10 14267 2617 11094 556 Coq 10 2391 1968 220 203 CSS 5 713 540 44 129 Dockerfile 2 71 42 11 18 HTML 2 35 30 0 5 INI 1 12 9 0 3 Java 31 2654 2080 267 307 JavaScript 7 867 752 61 54 JSON 17 939 939 0 0 Makefile 5 229 145 45 39 Markdown 47 7213 7213 0 0 OCaml 791 229096 198302 10455 20339 Python 398 61909 50119 2917 8873 Shell 5 111 59 34 18 SVG 2 2 2 0 0 TeX 4 929 642 129 158 Plain Text 5 457 457 0 0 TOML 1 2 2 0 0 TypeScript 2 130 84 20 26 ------------------------------------------------------------------------------- Total 1362 564903 431567 85969 47367 -------------------------------------------------------------------------------

zem 5y ago

compared to what? it's definitely one of the fastest-compiling languages i use.