Richard Eisenberg on Jane Street's OCaml Experiments

요약

30초 요약

Richard Eisenberg, a software engineer on Jane Street's compiler team, introduces the OCaml Unboxed video series. He explains why Jane Street values OCaml's strong typing, functional style, and predictable performance, and outlines three areas where the team is working to improve the language.

1Why OCamlJane Street uses OCaml for almost everything. Eisenberg values the assurance of strong typing, a functional style he finds close to how people think, and predictable performance.
2The memory-management tradeoffFloating-point values can require heap allocation and subsequent garbage collection. The team wants OCaml's reasoning power with more of the performance and memory-management characteristics of C, C++, or Rust.
3Unboxed typesUnboxed types would let floating-point values and other types be placed directly on the stack, avoiding separate memory management for those values.
4Locality modesModes controlling locality would allow more allocations to be placed on the stack and automatically released when their lifetimes follow the appropriate stack structure.
5Data-race-free parallelismThe team is adding language features intended to detect and prevent data races, making it possible to write fast parallel code without worrying about conflicting access.

핵심 정리

Jane Street uses OCaml broadly, valuing its strong typing, functional style, and predictable performance.
Heap allocation and garbage collection for values such as floating-point numbers can impose unwanted memory-management costs.
Unboxed types aim to let values such as floating-point numbers be placed on the stack without separate heap allocation.
Locality modes can allow stack allocation when the lifetime of an allocation follows the right stack structure.
The team is exploring language features to detect and prevent data races while enabling fast parallel code.

주제Programming Languages Software engineering

전문

챕터별로 다듬은 전문 읽기

원본 자막과 대조

원본 자막만 보기

Why Jane Street uses OCaml

Eisenberg introduces the compiler team's work and explains the appeal of strong typing, functional programming, and predictable performance. Jane Street uses the language for almost everything.

I'm Richard Eisenberg, a software engineer at Jane Street, where I work on the OCaml compiler. Our compiler team is making a series of videos about some of the things we're working on. We use the OCaml programming language for just about everything at Jane Street.

OCaml is a strongly typed functional programming language. Strong typing gives us a high degree of assurance about the correctness of our programs. Its functional style offers a different way of programming that works well for us and, I think, is closer to the way many people think.

Another nice thing about OCaml is its predictable performance. When we write a program, we know roughly how fast it will run and that it will continue to run that fast. Even so, there are areas where a language that already suits our needs could be a little better.

The case for better memory management

Some floating-point values require heap allocation and garbage collection. The team wants to combine OCaml's ability to support reasoning with performance and memory-management characteristics associated with lower-level languages.

Memory management is one example. A floating-point number can require us to allocate information on the heap and then come back and garbage collect it. We want to combine the power and ability to reason that OCaml gives us with some of the performance and memory-management characteristics of C, C++, or Rust.

Our compiler team is working on improvements in three main areas. The first is unboxed types: these would let us put a floating-point number directly on the stack, without having to manage a separate heap allocation for it. The same idea can apply to many other types as well.

Unboxed types and locality

Unboxed types could put values such as floats directly on the stack. Locality modes would also make more stack allocation possible when allocation lifetimes follow the right structure.

We're also introducing a system of modes, some of which control locality and allow more stack allocation. Even with unboxed types, we may still need to allocate memory. If we know when it should be deallocated and its lifetime follows the right stack structure, that can happen automatically without garbage collection, which can sometimes slow us down.

Parallelism without data races

The team is working on language features to detect and prevent conflicting access between threads. Eisenberg introduces the series as an exploration of these and other innovations.

The third area is data-race-free parallelism. Running multiple threads at once can be dangerous if one thread edits the same data as another and their operations conflict. We want language features that detect and prevent those data races, so we can write fast parallel code without worrying about them.

The OCaml Unboxed series will explain these innovations and others we're working on at Jane Street. I hope you enjoy it.