6 ms·

I got exited about OCaml when I tried to solve my performance issues in Python, but then realised OCaml didn't have a good multi core story either... Any progr

I got exited about OCaml when I tried to solve my performance issues in Python, but then realised OCaml didn't have a good multi core story either... Any progress in that area? Given that rust has picked up a lot in terms of typing and even syntax from OCaml, is OCaml still worth investigating?

joshmarlow 10y ago
There's work on multicore doing on right now; IIRC, there was a possibility that it could've shipped in the 2015 December release, but didn't make it. So I think/hope it should be available in the near future.
cm3 10y ago
Rust took affine substructural types and integrated them into a language that looks as similar to C and C++ as possible, to make it not seem foreign to your average programmer. You can think of Rust as a focused version of ATS2 with less features for practical reasons. Rust is for building lower-level code which you would have written in C or C++ before. The comfort features and type system plus compiler support make it more amenable to writing application code as well, which would have been written in Java, C++ or Python out of comfort, so it's used for that, too. OCaml is still relevant and they complement each other. Rust is decidedly not a functional programming language, so its type system isn't going to magically support expressing the kind of constraints and abstractions (for more maintainable and less bug-prone code) you're able to in OCaml, Haskell, or even ATS2. It's not Rust vs OCaml but Rust and OCaml. The selling point of Rust over ATS2 or OCaml is the popularity and resulting ecosystem around it, just like the JVM. OCaml's existing multicore story is practical with async and friends, but they're about to land the low-level framework that allows one to build various concurrency abstractions on top. That one's based on KC's research and is pretty cool, actually.
- catnaroek 10y ago
  async is for concurrent I/O, not parallel processing.
  - gpderetta 10y ago
    I don't know about ocaml, but in general async is also about parallelism as it exposes concurrency opportunities. See cilk spawn for example.
    - catnaroek 10y ago
      Parallelism and concurrency are fundamentally different things. Parallelism is running independent computations simultaneously. Concurrency control is managing the use of shared resources by temporarily granting exclusive access to them to individual computations. Imperative languages tend to blur the distinction between parallelism and concurrency, because the global state of a process by itself can be considered a shared resource. But in functional languages, it's natural to expect a sharper distinction: Because most data structures are logically immutable, the primary use for concurrency control is managing the interaction between the program and the “outside world”. On the other hand, parallelism is a powerful tool for speeding up the program's own internal calculations, even when no interaction with the “outside world” is involved.
      - gpderetta 10y ago
        Concurrency is a property of the software (i.e. the problem domain): i.e. having multiple independent control flows. Parallelism is a property of the hardware, i.e. having the capability of running multiple operations (be it pure computation, memory access or IO). To make use of parallel hardware you need concurrent software. Async is a way of exposing additional concurrency, thus enabling parallelism, to the hardware.
        catnaroek 10y ago
        > Parallelism is a property of the hardware, i.e. having the capability of running multiple operations (be it pure computation, memory access or IO). Parallelism is a property of the program too: if it doesn't have independent subcomputations, the program is going to run sequentially even in hardware that supports parallelism. > To make use of parallel hardware you need concurrent software. Parallel Haskell shows otherwise.
- dorfsmay 10y ago
  Is ATS used at all outside academia?
  - zem 10y ago
    yeah, here are some good posts on using ATS2 for internet-of-things applications http://metasepi.org/en/tags/ats.html http://metasepi.org/en/tags/ats.html
bad_user 10y ago
If you're looking for exhausting your CPU cores, you can do it with Python as well, by using multiple processes, like when using "multiprocessing". What Python and (currently) Ocaml won't do is being able to run in parallel multiple OS-managed threads that share the same address space. The approach in Ocaml is thus to use multiple processes instead of threads and do message passing between them and if you need to share some memory, you can do that too, although it gets tricky. In terms of performance, inability to do in-process threads-based parallelism isn't Python's biggest problem though. Good throughput is generally achieved by avoiding indirection and by being able to control the memory layout. Because Ocaml is static, because Ocaml code isn't heavy on OOP and because Ocaml also gives you low level tools allowing you to control the memory layout, you can have code that's "as fast as C". > Given that rust has picked up a lot in terms of typing and even syntax from OCaml, is OCaml still worth investigating? Rust and Ocaml are very different programming languages. Rust does not have a GC and that changes its nature completely. For example Rust could be used for real-time systems where garbage collected languages would struggle. Another consequence for example is that Rust isn't a functional programming language.
- catnaroek 10y ago
  You can do functional programming without garbage collection. The problem is social: few people in the functional programming community are interested in substructural types.
  - bogomipz 10y ago
    Can you elaborate on how a FP language might be implemented without a garbage collector? How do things like closure/lambdas wok without GC? I tried to lookup "substructural types" but wasn't able to find anything.
    - catnaroek 10y ago
      > I tried to lookup "substructural types" but wasn't able to find anything. A substructural type system lets you express constraints on how many times a value can be used. More precisely: (0) An object of an affine type cannot be used more than once. This is enforced by not allowing the same object to exist in multiple environments. Affinely typed objects can be moved (in the Rust sense) from one environment to another, but as soon as this happens, the object ceases to exist in the original environment. Affinely typed objects can be reclaimed as soon as they are first used (since they can't be used again) or go out of scope (since no other scope has access to them), so no dynamic garbage collection is necessary for them. (1) An object of a relevant type has to be used at least once. This is enforced by requiring the result of every computation to be fed into some other computation. In lazy languages, relevant types can be used for strictness optimizations: if the result of a computation is guaranteed to be used, then computing the result upfront eliminates the overhead of creating lazy suspensions. (2) An object of a linear type has to be used exactly once. A linear type is just a type that is both affine and relevant, so everything mentioned above applies. > How do things like closure/lambdas wok without GC? A closure has its own environment. With affine types, when a closure captures an object from the outer context, the object ceases to exist in the outer environment. This is how move closures already work in Rust. --- A digression: This is why I find GHC's plethora of type system extensions utterly disappointing. They marginally increase Haskell's expressiveness in areas where the language is already very expressive, but they don't address the language's limitations w.r.t. resource management. For instance, Haskell is incapable of statically enforcing that file handles won't leak.
joseraul 10y ago
OCaml is GCed and can infer more type annotations than Rust, so its code feels closer to Python. Rust is best for complex systems where tight control of resources is required.
desireco42 10y ago
Look at Erlang / Elixir for that specific feature.
ihodes 10y ago
Can't say I've tried it, but this approach looks very promising and has a nice, very composable API https://github.com/ocamllabs/reagents https://github.com/ocamllabs/reagents Regarding Rust v OCaml, Rust is a nice language but solving a very different problem. The type system is far weaker than that of OCaml's, it's less expressive (more verbose) by virtue of its sometimes-GCless GC. Rust is meant for system programming, and OCaml is rather more general purpose and pleasant to write in, while remaining incredibly performant.

joshmarlow 10y ago

There's work on multicore doing on right now; IIRC, there was a possibility that it could've shipped in the 2015 December release, but didn't make it. So I think/hope it should be available in the near future.

cm3 10y ago

Rust took affine substructural types and integrated them into a language that looks as similar to C and C++ as possible, to make it not seem foreign to your average programmer. You can think of Rust as a focused version of ATS2 with less features for practical reasons. Rust is for building lower-level code which you would have written in C or C++ before. The comfort features and type system plus compiler support make it more amenable to writing application code as well, which would have been written in Java, C++ or Python out of comfort, so it's used for that, too. OCaml is still relevant and they complement each other. Rust is decidedly not a functional programming language, so its type system isn't going to magically support expressing the kind of constraints and abstractions (for more maintainable and less bug-prone code) you're able to in OCaml, Haskell, or even ATS2. It's not Rust vs OCaml but Rust and OCaml. The selling point of Rust over ATS2 or OCaml is the popularity and resulting ecosystem around it, just like the JVM. OCaml's existing multicore story is practical with async and friends, but they're about to land the low-level framework that allows one to build various concurrency abstractions on top. That one's based on KC's research and is pretty cool, actually.

catnaroek 10y ago
async is for concurrent I/O, not parallel processing.
- gpderetta 10y ago
  I don't know about ocaml, but in general async is also about parallelism as it exposes concurrency opportunities. See cilk spawn for example.
  - catnaroek 10y ago
    Parallelism and concurrency are fundamentally different things. Parallelism is running independent computations simultaneously. Concurrency control is managing the use of shared resources by temporarily granting exclusive access to them to individual computations. Imperative languages tend to blur the distinction between parallelism and concurrency, because the global state of a process by itself can be considered a shared resource. But in functional languages, it's natural to expect a sharper distinction: Because most data structures are logically immutable, the primary use for concurrency control is managing the interaction between the program and the “outside world”. On the other hand, parallelism is a powerful tool for speeding up the program's own internal calculations, even when no interaction with the “outside world” is involved.
    - gpderetta 10y ago
      Concurrency is a property of the software (i.e. the problem domain): i.e. having multiple independent control flows. Parallelism is a property of the hardware, i.e. having the capability of running multiple operations (be it pure computation, memory access or IO). To make use of parallel hardware you need concurrent software. Async is a way of exposing additional concurrency, thus enabling parallelism, to the hardware.
      - catnaroek 10y ago
        > Parallelism is a property of the hardware, i.e. having the capability of running multiple operations (be it pure computation, memory access or IO). Parallelism is a property of the program too: if it doesn't have independent subcomputations, the program is going to run sequentially even in hardware that supports parallelism. > To make use of parallel hardware you need concurrent software. Parallel Haskell shows otherwise.
dorfsmay 10y ago
Is ATS used at all outside academia?
- zem 10y ago
  yeah, here are some good posts on using ATS2 for internet-of-things applications http://metasepi.org/en/tags/ats.html http://metasepi.org/en/tags/ats.html

bad_user 10y ago

If you're looking for exhausting your CPU cores, you can do it with Python as well, by using multiple processes, like when using "multiprocessing". What Python and (currently) Ocaml won't do is being able to run in parallel multiple OS-managed threads that share the same address space. The approach in Ocaml is thus to use multiple processes instead of threads and do message passing between them and if you need to share some memory, you can do that too, although it gets tricky. In terms of performance, inability to do in-process threads-based parallelism isn't Python's biggest problem though. Good throughput is generally achieved by avoiding indirection and by being able to control the memory layout. Because Ocaml is static, because Ocaml code isn't heavy on OOP and because Ocaml also gives you low level tools allowing you to control the memory layout, you can have code that's "as fast as C". > Given that rust has picked up a lot in terms of typing and even syntax from OCaml, is OCaml still worth investigating? Rust and Ocaml are very different programming languages. Rust does not have a GC and that changes its nature completely. For example Rust could be used for real-time systems where garbage collected languages would struggle. Another consequence for example is that Rust isn't a functional programming language.

catnaroek 10y ago
You can do functional programming without garbage collection. The problem is social: few people in the functional programming community are interested in substructural types.
- bogomipz 10y ago
  Can you elaborate on how a FP language might be implemented without a garbage collector? How do things like closure/lambdas wok without GC? I tried to lookup "substructural types" but wasn't able to find anything.
  - catnaroek 10y ago
    > I tried to lookup "substructural types" but wasn't able to find anything. A substructural type system lets you express constraints on how many times a value can be used. More precisely: (0) An object of an affine type cannot be used more than once. This is enforced by not allowing the same object to exist in multiple environments. Affinely typed objects can be moved (in the Rust sense) from one environment to another, but as soon as this happens, the object ceases to exist in the original environment. Affinely typed objects can be reclaimed as soon as they are first used (since they can't be used again) or go out of scope (since no other scope has access to them), so no dynamic garbage collection is necessary for them. (1) An object of a relevant type has to be used at least once. This is enforced by requiring the result of every computation to be fed into some other computation. In lazy languages, relevant types can be used for strictness optimizations: if the result of a computation is guaranteed to be used, then computing the result upfront eliminates the overhead of creating lazy suspensions. (2) An object of a linear type has to be used exactly once. A linear type is just a type that is both affine and relevant, so everything mentioned above applies. > How do things like closure/lambdas wok without GC? A closure has its own environment. With affine types, when a closure captures an object from the outer context, the object ceases to exist in the outer environment. This is how move closures already work in Rust. --- A digression: This is why I find GHC's plethora of type system extensions utterly disappointing. They marginally increase Haskell's expressiveness in areas where the language is already very expressive, but they don't address the language's limitations w.r.t. resource management. For instance, Haskell is incapable of statically enforcing that file handles won't leak.

joseraul 10y ago

OCaml is GCed and can infer more type annotations than Rust, so its code feels closer to Python. Rust is best for complex systems where tight control of resources is required.

desireco42 10y ago

Look at Erlang / Elixir for that specific feature.

ihodes 10y ago

Can't say I've tried it, but this approach looks very promising and has a nice, very composable API https://github.com/ocamllabs/reagents https://github.com/ocamllabs/reagents Regarding Rust v OCaml, Rust is a nice language but solving a very different problem. The type system is far weaker than that of OCaml's, it's less expressive (more verbose) by virtue of its sometimes-GCless GC. Rust is meant for system programming, and OCaml is rather more general purpose and pleasant to write in, while remaining incredibly performant.