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

21–30 of 97 posts

Re: A deep dive into Multicore OCaml garbage collector

#21

Post by nv-vn »

davidgl wrote: post #17
mercurial wrote: post #14

Earlier quoted context omitted.

F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).

F# has added some new features on top of OCaml like: - Lightweight syntax - Active Patterns to extend pattern matching - Type Providers to make it easy to interact with json/sql in a type safe way It's a joy to work in https://stackoverflow.com/questions/179492/f-changes-to-ocam...

F#'s features don't feel that useful after working in OCaml though. I've tried it for various projects, but OCaml is honestly just as good in all those situations. I wonder if there's some specific type of project where F#'s features will really shine.

Re: A deep dive into Multicore OCaml garbage collector

#22

Post by mercurial »

nv-vn wrote: post #21
davidgl wrote: post #17

Earlier quoted context omitted.

F# has added some new features on top of OCaml like: - Lightweight syntax - Active Patterns to extend pattern matching - Type Providers to make it easy to interact with json/sql in a type safe way It's a joy to work in https://stackoverflow.com/questions/179492/f-changes-to-ocam...

F#'s features don't feel that useful after working in OCaml though. I've tried it for various projects, but OCaml is honestly just as good in all those situations. I wonder if there's some specific type of project where F#'s features will really shine.

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.

Re: A deep dive into Multicore OCaml garbage collector

#23

Post by nv-vn »

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

Earlier quoted context omitted.

F#'s features don't feel that useful after working in OCaml though. I've tried it for various projects, but OCaml is honestly just as good in all those situations. I wonder if there's some specific type of project where F#'s features will really shine.

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 hole in the language and work together (rather than some random "cherry on top" feature that doesn't fix anything for me and is rarely useful).

Re: A deep dive into Multicore OCaml garbage collector

#24

Post by microtonal »

nv-vn wrote: post #4
0xcde4c3db wrote: post #3

Earlier quoted context omitted.

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

Facebook and Bloomberg are both industrial users as well.

And Citrix for XenServer and xapi:

https://github.com/xapi-project

Re: A deep dive into Multicore OCaml garbage collector

#25

Post by seanwilson »

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?

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

You should just spend a few hours and try it. Once you get used to inductive types, pattern matching, immutability and recursion over for loops there really isn't a lot of syntax to learn before you can be productive. Either way, it'll teach you to be a better coder in other languages.

Re: A deep dive into Multicore OCaml garbage collector

#26

Post by tom_mellior »

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?

> 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 ;-))

> any large cleany written codebases from which to study?

There is a big list of projects using OCaml at https://github.com/rizo/awesome-ocaml

Obviously, I can't vouch for cleanly-writtenness of any of them. Whichever you study would presumably depend on your area of expertise. There are packages there for anything from theorem proving to bioinformatics to web development. If you're into compilers, you could look at the OCaml compiler itself...

Re: A deep dive into Multicore OCaml garbage collector

#27

Post by mookid11 »

tom_mellior wrote: post #26
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?

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

Re: A deep dive into Multicore OCaml garbage collector

#28

Post by girvo »

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…

So about the only reason I have for it is some certain parallel algorithms I'd love to use, that are mostly best done at the thread level.

But, these days using unix sockets with some cute flags letting multiple proceeds binding to the same listening sockets means it's sort of less needed!

Though, doing a lot of work with Nim lately and exposing thread pools via Futures makes for some pretty lovely easy parallel code, so I dunno. Not a deal breaker but a nice to have, and having threads in OCaml will make things just that bit nicer

Re: A deep dive into Multicore OCaml garbage collector

#29

Post by beeforpork »

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.

Youmeanwhitespaceisbad?C64basicrules!

Re: A deep dive into Multicore OCaml garbage collector

#30

Post by rbehrends »

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 order of magnitude easier than an efficient concurrent GC.

2. You eventually run into scaling issues with shared memory only (number of cores, limited memory bandwidth). That said, a hybrid shared memory/message passing solution can still be superior to a pure message passing one, and for "desktop" parallelism that's not an issue.

3. Shared memory concurrency requires programming language support (at least if you want to keep a modicum of sanity), whereas message passing concurrency can be done as a library. And many languages have really, really screwed up their handling of shared memory concurrency where it's extremely difficult to reason about correctness.

My perceptions may be colored here because I did cut my teeth learning about parallel programming with distributed computing in the 1990s, but I also find that lack of shared memory concurrency less of an issue in actual practice (though, obviously, I'd hardly pass up on having the option).

Post reply on HN