Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A deep dive into Multicore OCaml garbage collector

kcsrk.info

Post reply on HN
Print view View original

61–70 of 97 posts

Re: A deep dive into Multicore OCaml garbage collector

#61

Post by mercurial »

pjmlp wrote: post #36
nv-vn wrote: post #23

Earlier quoted context omitted.

Yeah, I get that those are useful, but things like type providers or units of measure feel pretty useless to me and I'm not really sure if they're supposed to make me want to switch to F# or not. They certainly don't fill the place of OCaml's module system or object system or GADTs, PPXes, polymorphic variants, etc. To me OCaml's abstractions feel much more polished/as if they were all invented to fill some existing…

Well, a big decision point is what one uses as main development platform. Sadly OCaml support on Windows is not great, to put it nicely.

On the other hand, it may be possible to use F# on Linux with .NET Core now.

Re: A deep dive into Multicore OCaml garbage collector

#62

Post by mercurial »

darksaints wrote: post #50
mercurial wrote: post #20

Earlier quoted context omitted.

> Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC. Rust is a really different topic. It's an imperative low-level language with functional trappings, not the reverse. First off, "reasoning about memory access" really means "think…

Idiomatic rust avoids heap allocations, but it very much encourages immutable stack allocation...something that OCaml also tries to encourage. Rust started out a lot like OCaml, and gradually moved away from it whenever they needed to make a compromise to improve its position as a systems language. You start to see it with big things like how the pattern matcher works, but you also notice small things like idiomatic…

> Idiomatic rust avoids heap allocations, but it very much encourages immutable stack allocation...something that OCaml also tries to encourage.

No doubt, but most of your OCaml data structures will, in a typical program, still be on the heap, while idiomatic Rust will avoid Box whenever possible.

Apart from that, I know about the links between the two (and I think the blend between the OCaml/Java (for the generics) and Ruby syntax (lambdas) works really well in practice. But I think the underlying philosophy, and the way of structuring code are really different. This is a much more fundamental concern than surface-level considerations.

Re: A deep dive into Multicore OCaml garbage collector

#63

Post by Alyssa3545 »

kcsrk wrote: post #48
ice109 wrote: post #45

Earlier quoted context omitted.

I whole heartedly agree with you on the convenience of go routines. I haven't been following the ocaml concurrency sorry; are they implementing a similar concurrency model?

Multicore OCaml comes with native support for concurrency through algebraic effect handlers which generalize common control flow abstractions such as exceptions, async/await, generators, non-determinism, backtracking. All of these mechanisms can be implemented directly in OCaml. [0] introduces the model, [1,2] has examples, and for further reading see [3]. [0]: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-mul…

I've made $64,000 so far this year working online and I'm a full time student. Im using an online business opportunity I heard about and I've made such great money. It's really user friendly and I'm just so happy that I found out about it. Heres what I do, •••••••••>> http://www.joinmate2.com

Re: A deep dive into Multicore OCaml garbage collector

#64

Post by rbehrends »

darksaints wrote: post #50
mercurial wrote: post #20

Earlier quoted context omitted.

> Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC. Rust is a really different topic. It's an imperative low-level language with functional trappings, not the reverse. First off, "reasoning about memory access" really means "think…

Idiomatic rust avoids heap allocations, but it very much encourages immutable stack allocation...something that OCaml also tries to encourage. Rust started out a lot like OCaml, and gradually moved away from it whenever they needed to make a compromise to improve its position as a systems language. You start to see it with big things like how the pattern matcher works, but you also notice small things like idiomatic…

> Idiomatic rust avoids heap allocations, but it very much encourages immutable stack allocation...something that OCaml also tries to encourage.

I'm not sure I'm following you here; one of the more common criticisms of OCaml is generally that it (unavoidably) puts too many values on the heap. I mean, even floats get boxed by default, unless the compiler can avoid that.

Re: A deep dive into Multicore OCaml garbage collector

#65

Post by JacobiX »

logicchains wrote: post #44
rixed wrote: post #19

I never managed to understand why so many people were apparently longering for multicore support. I just can't believe many are impatiently waiting for this feature to start using the ocaml language for some projects requiring multicore support, and I became impatient myself just to see what those projects are. In recent years where servers are to scale to many machines I found myself using less and less kennel threa…

Even if a particular application doesn't require any multicore support, usually at work I won't be working on just one application as part of a project, there'll be multiple applications involved, at least some of which will require shared memory parallelism. To me it doesn't make sense to pick a language that can only be used for a few applications not all, as this leads to unnecessary duplication in library code an…

One can have the kind of unsafe shared memory like C++ in OCaml by using a library like netmulticore. But the OCaml formalised memory model is offering the same kind of OCaml safety in multicore programs. For your first point I'm not an advocate of using a single programming language for all kinds of things. But it's just my opinion.

Re: A deep dive into Multicore OCaml garbage collector

#67

Post by amelius »

I'm guessing a lot of other languages could benefit from this. So what I'd like to see is a runtime environment and garbage collector decoupled from the actual language. Something like the LLVM project, except focused on the runtime system (and different variants) rather than code generation.

Re: A deep dive into Multicore OCaml garbage collector

#68

Post by kcsrk »

amelius wrote: post #67

I'm guessing a lot of other languages could benefit from this. So what I'd like to see is a runtime environment and garbage collector decoupled from the actual language. Something like the LLVM project, except focused on the runtime system (and different variants) rather than code generation.

There is already one! See Malfunction [0,1]. There is an Idris and Agda backend for malfunction.

[0]: https://github.com/stedolan/malfunction

[1]: https://www.cl.cam.ac.uk/~sd601/papers/malfunction.pdf

Re: A deep dive into Multicore OCaml garbage collector

#69

Post by mookid11 »

LukaD wrote: post #43
mookid11 wrote: post #27

Earlier quoted context omitted.

> Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. While I find the ocaml syntax very far from perfect, the whitespace sensitivity of Haskell makes it immediately worse. What a silly design.

How does the whitespace sensitivity make it immediately worse?

Unless experienced, you have no clue how a piece of code will be parsed. With ocaml, where is very little ambiguity; and indentation tools can take care of proper formatting, you only need to break lines.

And it can be pretty bad with haskell, which has complex semantics compared to, say, python.

With whitespace sensitive syntax, I feel like in the dark age of manual indentation.

Re: A deep dive into Multicore OCaml garbage collector

#70

Post by pencilhappen »

_ph_ wrote: post #57
rixed wrote: post #19

I never managed to understand why so many people were apparently longering for multicore support. I just can't believe many are impatiently waiting for this feature to start using the ocaml language for some projects requiring multicore support, and I became impatient myself just to see what those projects are. In recent years where servers are to scale to many machines I found myself using less and less kennel threa…

The short answer is: single-core cpu performance is not going up much in the recent years. The core count is still increasing every year. That is why graphics cards still see a strong rise in total performance, their usual work load is inherently parallel. For typical server tasks, like web serving, we can just run several processes. Unix is doing this for decades. But even web serving is often cpu bound, if your SQL…

> but the recent years brought quite some progress. Go makes it easy ...

It actually feels like the recent years have been pretty disappointing. Go is one of the few places where the language developers are making a real effort around multicore. Erlang came with a bunch of opinions about how to do this in the 90s.

But every other mainstream language is taking a head-in-the-sand attitude about this. Python squandered their backwards compatibility break without addressing this at all. The JVM developers are making no effort to get away from the global heap. Ruby and Node are completely ignoring it entirely. PHP from it's request/response web history actually does well, except its non-web story is as dismal as ever. Lua has coroutines, which are a reasonable abstraction, but no multicore VM story...

Post reply on HN