Writing Performance Sensitive OCaml Code | Hacker News Reader

Writing Performance Sensitive OCaml Code

janestreet.github.io

84 pointsamirmc25 comments

Wow, the first 5 comments on this were about should they use LLVM:)

The author is currently writing a book about OCaml that is now available in alpha format from here:

http://www.realworldocaml.org/

I've finished the first part and looked at the compiler section, and I love this book, no affiliation in any way.

On the one hand, OCaml is a very interesting language and I welcome a good book about it in the vein of Real World Haskell. On the other hand, it is the height of treason for O'Reilly to make a book with a camel on the cover that isn't about Perl :v

They're different species of Camel. The Bactrian has two humps and the Dromedary has one (among other differences).

When someone/thing dies, it's ok to reuse their Jersey eventually.

HMMMM.

http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby%2C+...

Nice hand-picked rebuttal. Can I play too?

http://www.indeed.com/jobtrends?q=perl%2C+Java%2C+C%2B%2B%2C...

HMMMM indeed.

You're saying C++ is dying?!

I'm really interested in learning OCaml, but when I tried to view the book it asked for access to read my public information and update my public repositories. Seriously?

Anybody know what that's about?

The book is not finished yet, and right now it is meant for reviewers to comment on the book: "Once authenticated, you will see that every paragraph has a comments link beside it. Simply enter your feedback in there, and a Github issue will automatically be created on your behalf. "

If you simply want to read the book then I suggest you wait until it is finished.

In the meantime I would recommend you start reading the tutorials on the OCaml community site: http://ocaml.org/tutorials/index.html

It does state on the page that when you login with GitHub "..., you temporarily grant us access to your public repositories. However, we do not store your authorization tokens on the server side, and instead use a cookie on your browser. To log out, you simply delete the cookie"

The next paragraph explains why. Essentially, Github issues are being used to track and deal with reviewers' comments.

> The author is currently writing a book about OCaml that is now available in alpha format from here: http://www.realworldocaml.org/

For anyone else trying to take a peek, authorizing github doesn't necessarily grant you access as there is some sort of whitelisting of allowed github handles. They should make it obvious in the copywriting that not all github accounts can take a peek.

"To login and view the book, you will need a free Github account to authenticate with."

This sounds like you just authenticate with github and be on your merry way.

Ah, yes. There is a whitelist. Even though the book website is 'public' it hasn't really been advertised (apart from the initial "Hey, we're writing a book!" announcement [1]). There were already lots of reviewers for the alpha stages so not much need to attract more.

The beta stage might be different as the early 'bugs' will have been squashed so that phase of writing might take a different approach.

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

This book is now in Public beta [1]

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

Jane Street is an established firm with a large OCaml codebase they depend on. Just an FYI.

This is a good collection of performance tips, although I'd use Unix.gettimeofday instead of RDTSC (RDTSC needs additional care on multicore).

Also it is interesting that OCaml's tutorial has a section on performance (that is not something common in other language tutorials): http://ocaml.org/tutorials/performance_and_profiling.html

This is a good overview of performance 'idiosyncrasies'. For profiling, I tend to use valgrind's callgrind which is easier than instrumenting the code by hand.

I'm surprised the compiler goes straight to assembly, rather than targeting LLVM (most native programming languages) or C- (what GHC does/did)

Why? Ocaml was around long before LLVM, and GHC has a mode where you can emit assembly (and one where you can emit LLVM as well).

Most compilers target LLVM? That doesn't sound right. Maybe most compilers written in the last five years or so.

There's an OCaml LLVM backend [1]. The author found a number of issues with LLVM [2] although this could be overcome. The real problem is that the low-level object format is completely different which would break all OCaml extensions written in C (eg. any extension that links to an external C library). Plus the current code generators are really fast and cover all common architectures anyway so there's not much point.

[1] https://github.com/colinbenner/ocamlllvm

[2] http://oud.ocaml.org/2012/abstracts/oud2012-paper7.pdf

FYI, it's C-- (not C-): https://en.wikipedia.org/wiki/C--

> I'm surprised the compiler goes straight to assembly, rather than targeting LLVM (most native programming languages)

Most native programming languages historically don't, and OCaml predates LLVM by a good 7 years.

> or C- (what GHC does/did)

Cmm is an intermediate language specific to GHC before the backend[1], GHC's default backend is a native generator.

[1] or more precisely "an other" intermediate language, since there's also Core.

> , rather than targeting LLVM (most native programming languages)

Native languages targeting LLVM are the exception not the norm. The vast majority of native compilers do emit assembly.

[1] http://llvm.org/ProjectsWithLLVM/

You might be surprised to learn that there are languages that are agnostic in what they target.

Why? Going to llvm constrains you to do llvm's models. (Also, the timing issue mentioned by a sibling.)

Reply on news.ycombinator.com