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

Re:Jane Street and the OCaml Compiler (2018) [video] by QuinnWilton on Wednesday March 25, 2020 @09:00PM (#22689957)

I don't know what Jane Street does, and can't speak for them. That being said, I've heard of some firms using the JVM that just tune things such that the garbage collector will never trigger, and then they restart the VM every night.

Unfortunately I don't have a citation for that. I think I've seen it talked about before here on HN before.

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by Reelin on Wednesday March 25, 2020 @09:14PM (#22690011)

I'm not entirely clear on the use case, but Disruptor by LMAX Exchange is for the JVM and seems very concerned with latency. (https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...)

[ Parent | on HN ]

Re:Jane Street and the OCaml Compiler (2018) [video] by imglorp on Wednesday March 25, 2020 @09:22PM (#22690058)

Here's the backstory, worth a good read in general. https://martinfowler.com/articles/lmax.html

I suspect at least one use case has gone away since the Fowler wrote that: wanting to saturate the write channel into a database in general. Consistent hashing document DBs like DynamoDB, Cassandra, etc. are basically infinitely scalable for writes. It's not clear to me if LMAX still makes sense if you want to assemble the db writes into a strongly ordered stream.

[ Parent | on HN ]

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

"wanting to saturate the write channel into a database in general. Consistent hashing document DBs like DynamoDB, Cassandra, etc. are basically infinitely scalable for writes."

I don't really understand what are you are saying there ?

But we use disruptors for processing millions of messages/events as quickly as possible, with a variety of different consumers.

[ Parent | on HN ]