Jane Street and the OCaml Compiler (2018) [video]

Re:Jane Street and the OCaml Compiler (2018) [video] by jnordwick on Thursday March 26, 2020 @03:13AM (#22691288)

Ive worked a couple java based hft platforms at major firms. You write code that never gcs after startup. That means not using certain language constructs and rewriting almost every library along with using off heap memory.

I have personally worked on systems that would run an entire week between deployments and never gced.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by giu on Thursday March 26, 2020 @05:08AM (#22691721)

Could you maybe elaborate more on how to achieve this with Java, i.e., run an entire week and never get GCed? I would imagine that using immutable types is one of the tricks used in such a scenario.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by Pepe1vo on Thursday March 26, 2020 @05:31AM (#22691861)

You would (among other techniques) use something like Stormpot to maintain Object pools to release and acquire instances from.

Object pools typically can't match the GC on latency and throughput, however they do provide a lot more predictable and stable performance.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by mlrtime on Thursday March 26, 2020 @07:54AM (#22692587)

You basically write Java as C++, you don't use any builtins, write everything yourself from pure java.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by spugody on Thursday March 26, 2020 @09:12AM (#22693198)

I know you said "almost" but you don't have to re-write huge amounts to achieve zero gc and very low latency. There are open source tools, eg. agrona, aeron, that get you a lot of the way there.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by dirtydroog on Thursday March 26, 2020 @09:05AM (#22693132)

And I'd imagine sun.misc.Unsafe is used quite often too.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by zerr on Thursday March 26, 2020 @05:11AM (#22691740)

Why would you do that? Why not use C++? Especially, as you say, when memory management is ignored...

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by throwaway720348 on Thursday March 26, 2020 @05:34AM (#22691881)

You can use a language like OCaml without allocating and still capture huge benefits over C++, like a decent type system, ADTs, and better abstractions than templates (modules in OCaml's case).

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by zerr on Thursday March 26, 2020 @05:39AM (#22691905)

What about multicore? :)

Nowadays Rust seems to cover all those features with zero-cost abstractions.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by p_l on Thursday March 26, 2020 @06:09AM (#22692076)

You still need to write non-consing code to avoid memory allocation/deallocation latency, just as if you were working in Java, Lisp or OCaml.

(In fact, GCs can often give you better latency than malloc/free unless you go into custom allocators with object pools... which is part of writing non-consing code in GCed languages)

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by throwaway720348 on Thursday March 26, 2020 @06:38AM (#22692218)

Ah you're right, I forgot about OCaml's ass-tier multicore support. Rust is definitely better there.

[ Parent | on HN ]