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

31–40 of 97 posts

Re: A deep dive into Multicore OCaml garbage collector

#31

Post by kcsrk »

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…

Multicore support isn't for every one, but there are some important use cases where multicore support is very useful. One example is Facebook's Hack language type checker [0] which offers good opportunity for parallelism, but the lack of multicore support in OCaml means that they had to implement a custom off-heap lock free hash table shared by multiple processes. There are many industrial uses of OCaml including static type checkers (FB's Hack, Flow, Infer, etc), program verification tools (Coq, why3), math libraries (Owl) [1] etc., all of which benefit from multicore support.

[0]: https://www.youtube.com/watch?v=uXuYVUdFY48

[1]: https://news.ycombinator.com/item?id=14751236

Re: A deep dive into Multicore OCaml garbage collector

#32

Post by rbehrends »

axaxs wrote: post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

I think as a computer scientist you should really have at least some familiarity with both Haskell and one of the ML languages, just because it'll expand your thinking. Whether to invest deeply in one of them is a matter of whether you have the time (especially if it's just as a hobby) and how well one or the other matches your preferences.

I don't generally evangelize OCaml – because as a language it can be a bit of a mixed bag – but end up using it a lot because in the end it's a pragmatic language and a really solid workhorse. The niche that it fills for me is that of a statically typed language with native compilation and a GC, a niche that has historically not been served all that well.

Things I like:

* The language itself is not too opinionated. It's a multi-paradigm, functional-first language, that allows me to use imperative or OO styles when that's the best fit.

* The compiler is fast.

* While the ecosystem has some gaps, it's very solid in those areas that I need (such as systems programming or language tooling).

* The language does not prioritize speed at the expense of correctness; this includes the compiler. There are languages where, let's say, I have trust issues. Code quality is still pretty darn good.

* I really like ML functors for parametric polymorphism. While more verbose than other approaches, they are simple and powerful.

* Having a time-traveling debugger can occasionally be very helpful.

* For all their warts, the language and the compiler are mature.

Re: A deep dive into Multicore OCaml garbage collector

#33

Post by openplatypus »

trishume wrote: post #11
axaxs wrote: post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

You might want to check out https://reasonml.github.io/ . It's a new syntax and set of tools for OCaml that are better in many ways but compatible with the existing ecosystem and tools.

DON'T! Check the Facebook licensing issues (HN is full of them today). Stay away from all-Facebook things.

Re: A deep dive into Multicore OCaml garbage collector

#34

Post by pjmlp »

vog wrote: post #15
flunhat wrote: post #5

Earlier quoted context omitted.

IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the lan…

> you can cheat a little and write imperative code if you really need to I'm not sure if this is cheating. Yes, this can be misused to introduce side-effects where there should be none. However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter…

Personally I think it is a mistake to use Rust instead of OCaml if the use case doesn't require the tight memory management that Rust supports.

If the target domain can be done in a language with GC, enjoy productivity with sails taking full wind, instead of having to deal with lifetime annotations.

Now if the GC induced delays are too much for the target domain, then for all means use Rust.

After all, the tool for reasoning about performance is a profiler, not the compiler itself.

Re: A deep dive into Multicore OCaml garbage collector

#35

Post by [deleted] »

mercurial wrote: post #13
logicchains wrote: post #6

Earlier quoted context omitted.

OCaml has many of the good qualities people attribute to Go (simplicity, speed, relatively low-latency GC, well-engineered compiler&runtime) and none of the downsides. Its weakness is terrible support for multithreading (like CPython it has a global lock, such that only one thread can execute OCaml code at a time), but there's work in progress to fix that. Personally I'm of the opinion that if the developers had take…

People often don't like the syntax too much (which is why Facebook invented Reason). There are other weaknesses as well: - the stdlib is good for data structures and not much else, which in turn gave rise to at least three different stdlib extensions - it does not have typeclasses, so implementing a generic "to_string" for your data type is not a thing - it has some really unfortunate ideas like "universal compare" -…

[deleted]

Re: A deep dive into Multicore OCaml garbage collector

#36

Post by pjmlp »

nv-vn wrote: post #23
mercurial wrote: post #22

Earlier quoted context omitted.

I can imagine the .NET interop is a big deal, especially if you need to do anything on Windows. Also, parallelism can be occasionally useful.

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.

Re: A deep dive into Multicore OCaml garbage collector

#37

Post by fulafel »

0xcde4c3db wrote: post #3
axaxs wrote: post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

As far as I know, Jane Street is the go-to example for commercial users. It's also unsurprisingly used within INRIA itself (for e.g. Coq).

Docker too. https://github.com/moby/datakit https://github.com/moby/vpnkit

Re: A deep dive into Multicore OCaml garbage collector

#38

Post by mercurial »

mookid11 wrote: post #27
tom_mellior wrote: post #26

Earlier quoted context omitted.

> or why I should try Haskell instead Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example. Still, it makes some things (like having a mutable variable, or a hash table) much harder than they should be. It's worthwhile looking at both over some rainy weekends. Whichever you end up preferring, you'll have learned useful things about both languages. (OCaml is better, though ;-)) >…

> 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.

IMHO, it's not so much that as the ASCII operator galore. $, , the horrible lambda syntax... Sometimes it looks an opinionated Perl.

Re: A deep dive into Multicore OCaml garbage collector

#39

Post by rixed »

rbehrends wrote: post #30
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 most common reasons for requiring shared memory concurrency (instead of message passing) are: 1. It's just plain easier to write a lot of stuff with a shared memory approach. 2. There are algorithms where you get the best speedup using shared memory. But yes, there are also downsides. 1. Shared memory concurrency can be a lot harder on the runtime. In particular, writing an efficient single-threaded GC is an orde…

Indeed I welcome the option as well. If it doesn't make the runtime noticably slower for non concurrent programs, of course, but I'm confident the authors will make all this a no-op in that case.

Re: A deep dive into Multicore OCaml garbage collector

#40

Post by kcsrk »

rixed wrote: post #39
rbehrends wrote: post #30

Earlier quoted context omitted.

The most common reasons for requiring shared memory concurrency (instead of message passing) are: 1. It's just plain easier to write a lot of stuff with a shared memory approach. 2. There are algorithms where you get the best speedup using shared memory. But yes, there are also downsides. 1. Shared memory concurrency can be a lot harder on the runtime. In particular, writing an efficient single-threaded GC is an orde…

Indeed I welcome the option as well. If it doesn't make the runtime noticably slower for non concurrent programs, of course, but I'm confident the authors will make all this a no-op in that case.

Performance backwards compatibility has been a key goal in the Multicore OCaml project. Currently, the overhead for running legacy sequential OCaml programs on the multicore GC is a few percentage points on average. The overhead is low enough that we may not need to provide a "sequential-only" compilation flag.
Post reply on HN