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

71–80 of 97 posts

Re: A deep dive into Multicore OCaml garbage collector

#71

Post by jzelinskie »

JacobiX wrote: post #47
atombender wrote: post #42

Earlier quoted context omitted.

In Go you can just do "go doWork()" and the scheduler runs the function as a coroutine on some kernel thread, thus allowing your program to make use of all cores. The ability to just throw goroutines at the scheduler changes how you approach writing programs. For example, say you want to process an input that consists of lots of individual records. You can run the input stream in one goroutine, then spawn a bunch of…

In OCaml there is Lwt. It provides very light-weight cooperative threads. The context switches are very fast and composing cooperative threads allows the writing of highly asynchronous applications. For instance, in the versions of Go prior to 1.5 goroutines used to run on a single core. And as of 1.5 the variable GOMAXPROCS can be set to the number of cores. EDIT:clarify the difference between concurrency and parall…

>For instance, in the versions of Go prior to 1.5 goroutines used to run on a single core. And as of 1.5 the variable GOMAXPROCS can be set to the number of cores.

This is not true. Prior to Go 1.5 GOMAXPROCS defaulted to 1, but could always be set to use any number of cores. In Go 1.5, the default value for GOMAXPROCS was changed to the number of "cores" available on the machine. Prior to then many applications were setting GOMAXPROCS based on CLI flags or just hard-coding the future behavior with `runtime.GOMAXPROCS(runtime.NumCPU())`.

Re: A deep dive into Multicore OCaml garbage collector

#72

Post by CyberDildonics »

rbehrends wrote: post #64
darksaints wrote: post #50

Earlier quoted context omitted.

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.

> even floats get boxed by default, unless the compiler can avoid that.

Yikes, that seems like it would destroy performance.

Re: A deep dive into Multicore OCaml garbage collector

#73

Post by [deleted] »

rbehrends wrote: post #64
darksaints wrote: post #50

Earlier quoted context omitted.

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.

[deleted]

Re: A deep dive into Multicore OCaml garbage collector

#74

Post by the_why_of_y »

ice109 wrote: post #46
mercurial wrote: post #38

Earlier quoted context omitted.

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

I don't know if you've worked with a production Haskell code base but it cannot be over stated what a poor decision operator overloading is. if they got rid of that it would immediately make Haskell an order of magnitude more practical

Haskell doesn't really have the problems that are commonly associated with operator overloading.

Haskell does have type classes, which do allow overloading, even of operators, but the type class uniquely determines the type of the operator - and there can be only one definition of any operator in scope.

Also, you can just define as many new operators as you like.

For these reasons, you can't have the madness of operator<< in C++, or whatever it is that Perl does with the same operator doing 5 completely different things depending on context.

Re: A deep dive into Multicore OCaml garbage collector

#75

Post by ernst_klim »

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 know of any large cleany written codebases from which to study?

* unison (a great file sync tool for win/posix from Benjamin Pierce, the author of Software foundations and TAPL)

https://github.com/bcpierce00/unison

* mirage (which also has a bunch of interesting subprojects, like irmin)

https://github.com/mirage

* coq

https://github.com/coq/coq

* flow

https://github.com/facebook/flow

* CompCert

https://github.com/AbsInt/CompCert

* frama-c

https://github.com/Frama-C

* 0install

https://github.com/0install/0install

Re: A deep dive into Multicore OCaml garbage collector

#76

Post by JacobiX »

jzelinskie wrote: post #71
JacobiX wrote: post #47

Earlier quoted context omitted.

In OCaml there is Lwt. It provides very light-weight cooperative threads. The context switches are very fast and composing cooperative threads allows the writing of highly asynchronous applications. For instance, in the versions of Go prior to 1.5 goroutines used to run on a single core. And as of 1.5 the variable GOMAXPROCS can be set to the number of cores. EDIT:clarify the difference between concurrency and parall…

>For instance, in the versions of Go prior to 1.5 goroutines used to run on a single core. And as of 1.5 the variable GOMAXPROCS can be set to the number of cores. This is not true. Prior to Go 1.5 GOMAXPROCS defaulted to 1, but could always be set to use any number of cores. In Go 1.5, the default value for GOMAXPROCS was changed to the number of "cores" available on the machine. Prior to then many applications were…

My bad, you are correct. I just wanted to point out that one can have concurrency without parallelism.

Re: A deep dive into Multicore OCaml garbage collector

#77

Post by tom_mellior »

the_why_of_y wrote: post #74
ice109 wrote: post #46

Earlier quoted context omitted.

I don't know if you've worked with a production Haskell code base but it cannot be over stated what a poor decision operator overloading is. if they got rid of that it would immediately make Haskell an order of magnitude more practical

Haskell doesn't really have the problems that are commonly associated with operator overloading. Haskell does have type classes, which do allow overloading, even of operators, but the type class uniquely determines the type of the operator - and there can be only one definition of any operator in scope. Also, you can just define as many new operators as you like. For these reasons, you can't have the madness of opera…

> Haskell doesn't really have the problems that are commonly associated with operator overloading.

Nobody said it did. People said that it has its own brand of problems with operators looking something like >>+@*> peppering your code.

Re: A deep dive into Multicore OCaml garbage collector

#78

Post by tom_mellior »

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…

> things like running Quickcheck and Nitpick in a separate thread

In my experience with Isabelle, these tools provide feedback on the order of seconds (because they do expensive things). Maybe several hundreds of milliseconds, for simple cases. At these scales, it makes no noticeable difference what kind of parallelism solution you use. Spawning separate processes and sending messages would work just as well.

So the reason there is no parallel Quickcheck for Coq is more likely due to the fact that there is no Quickcheck for Coq, period.

Re: A deep dive into Multicore OCaml garbage collector

#79

Post by sriram_malhar »

35bge57dtjku wrote: post #12
BoiledCabbage wrote: post #7

Earlier quoted context omitted.

From what I understand F# is a pretty close version of Ocaml, but has the benefit of all the libraries of the full .net ecosystem.

If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.

> it's obvious the F# author blatantly copied

That's a really unfortunate choice of words. It almost makes him look like he stole something in the middle of the night and never gave anyone credit.

Don Syme worked on Project 7 which brought Generics to .NET, and then spoke with Leroy and others to bring OCaml to this environment.

  The next logical step was to implement an OCaml- style language directly,
  and the OCaml designers were very encouraging when we talked to them
  about bringing this class of languages into the .NET space. That led to the
  early versions of F#.
See this interview: http://through-the-interface.typepad.com/through_the_interfa...

Re: A deep dive into Multicore OCaml garbage collector

#80

Post by mixedCase »

mercurial wrote: post #61
pjmlp wrote: post #36

Earlier quoted context omitted.

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.

Tooling is definitely far from mature. It's treated as a second class language in .NET, and on top Linux is treated a second class OS.

I just tried to start a project with F# and ended up abandoning, and am looking into Rust right now. I considered OCaml but its lack of multicore support and the ecosystem situation made me drop it.

Post reply on HN