Sam Westrick
@shwestrick.bsky.social
assistant professor @NYU Courant CS :: programming languages :: parallel computing :: music :: lead dev of the MaPLe compiler (https://github.com/mpllang/mpl)
https://cs.nyu.edu/~shw8119/
https://cs.nyu.edu/~shw8119/
for even more context: Laxman has been exploring the limits of what is possible on single-node parallel machines. This talk is about a recent SPAA paper.
They’re getting great scalability up to 8TB on a single node
They’re getting great scalability up to 8TB on a single node
October 22, 2025 at 11:22 PM
for even more context: Laxman has been exploring the limits of what is possible on single-node parallel machines. This talk is about a recent SPAA paper.
They’re getting great scalability up to 8TB on a single node
They’re getting great scalability up to 8TB on a single node
the famous Nissan Leaf slide returns!
Laxman Dhulipala emphasizes the benefits of single-node, shared memory parallelism
Laxman Dhulipala emphasizes the benefits of single-node, shared memory parallelism
October 22, 2025 at 9:50 PM
the famous Nissan Leaf slide returns!
Laxman Dhulipala emphasizes the benefits of single-node, shared memory parallelism
Laxman Dhulipala emphasizes the benefits of single-node, shared memory parallelism
one day, my apartment will look like this
October 18, 2025 at 1:31 AM
one day, my apartment will look like this
Martin Elsman wraps up the day with Compositional Deep Argument Flattening, a method for summarizing flattening transformations to enable optimizations across compilation unit boundaries
October 16, 2025 at 1:36 PM
Martin Elsman wraps up the day with Compositional Deep Argument Flattening, a method for summarizing flattening transformations to enable optimizations across compilation unit boundaries
Yanni Lefki (together with Arthur Charguéraud) develop “Binding Boolean Expressions”, a core calculus for generalized pattern matching, guards, and case statements
October 16, 2025 at 1:33 PM
Yanni Lefki (together with Arthur Charguéraud) develop “Binding Boolean Expressions”, a core calculus for generalized pattern matching, guards, and case statements
Samuel Vivien presents his recent work (together with Didier Rémy) on Implicit Modules, an important step towards the long-standing Modular Implicits proposal for OCaml: a way to get the compiler to insert the function you need, automatically
October 16, 2025 at 1:26 PM
Samuel Vivien presents his recent work (together with Didier Rémy) on Implicit Modules, an important step towards the long-standing Modular Implicits proposal for OCaml: a way to get the compiler to insert the function you need, automatically
Yong Kiam overviews the design of CakeML and all of the successes of the project over the years!
October 16, 2025 at 1:15 PM
Yong Kiam overviews the design of CakeML and all of the successes of the project over the years!
October 16, 2025 at 9:09 AM
Wenhao Tang motivates “Freezing Bidirectional Typing”, a new type inference scheme with some cool 🧊 and spooky 👻 features
October 16, 2025 at 9:05 AM
Wenhao Tang motivates “Freezing Bidirectional Typing”, a new type inference scheme with some cool 🧊 and spooky 👻 features
54 bit integers by default on the JavaScript backend! What a cool trick
October 16, 2025 at 8:59 AM
54 bit integers by default on the JavaScript backend! What a cool trick
Mizuki Arata presents LunarML — an impressive implementation!! It compiles standard ML down to either Lua or JavaScript. Tons of features. Check it out! github.com/minoki/LunarML
October 16, 2025 at 5:23 AM
Mizuki Arata presents LunarML — an impressive implementation!! It compiles standard ML down to either Lua or JavaScript. Tons of features. Check it out! github.com/minoki/LunarML
John presents new compiler optimization work inside of SML/NJ —
October 16, 2025 at 3:08 AM
John presents new compiler optimization work inside of SML/NJ —
Dave is up! Calling in all the way from the Oregon coast
October 16, 2025 at 2:38 AM
Dave is up! Calling in all the way from the Oregon coast
finally, to close the day, we have Samuel Vivien, Yanni Lefki, and Martin Elsman
October 16, 2025 at 12:12 AM
finally, to close the day, we have Samuel Vivien, Yanni Lefki, and Martin Elsman
next up, right after lunch, we have Wenhao Tang, Viviana Bono, and Yong Kiam Tan
October 16, 2025 at 12:12 AM
next up, right after lunch, we have Wenhao Tang, Viviana Bono, and Yong Kiam Tan
in the first session, presentations from Dave MacQueen, John Reppy, and Mizuki Arata
October 16, 2025 at 12:12 AM
in the first session, presentations from Dave MacQueen, John Reppy, and Mizuki Arata
the ML Family Workshop begins in just a few hours! Come find us in Peony NE at 10:30, right next to the dining hall
We have a great program with 9 talks!
If you are curious about compilers, type systems, module systems, formal proofs, and typed domain modeling, then this is the place for you
We have a great program with 9 talks!
If you are curious about compilers, type systems, module systems, formal proofs, and typed domain modeling, then this is the place for you
October 16, 2025 at 12:12 AM
the ML Family Workshop begins in just a few hours! Come find us in Peony NE at 10:30, right next to the dining hall
We have a great program with 9 talks!
If you are curious about compilers, type systems, module systems, formal proofs, and typed domain modeling, then this is the place for you
We have a great program with 9 talks!
If you are curious about compilers, type systems, module systems, formal proofs, and typed domain modeling, then this is the place for you
One of the surprising things we discovered is that this "backwards-in-time" / "up-pointer invariant" concept can be very elegantly encoded in the type system as a form of subtyping that we call subtiming.
The whole system is essentially just standard unification + subtiming
⬇️
The whole system is essentially just standard unification + subtiming
⬇️
October 3, 2025 at 7:15 PM
One of the surprising things we discovered is that this "backwards-in-time" / "up-pointer invariant" concept can be very elegantly encoded in the type system as a form of subtyping that we call subtiming.
The whole system is essentially just standard unification + subtiming
⬇️
The whole system is essentially just standard unification + subtiming
⬇️
Yes! enter TypeDis
similar to region types, TypeDis associates a task identifier or "timestamp", δ, with every allocation.
e.g. the type string@δ indicates that the string was allocated at time δ
Unboxed types don't need these annotations (e.g. raw integers, booleans, etc)
⬇️
similar to region types, TypeDis associates a task identifier or "timestamp", δ, with every allocation.
e.g. the type string@δ indicates that the string was allocated at time δ
Unboxed types don't need these annotations (e.g. raw integers, booleans, etc)
⬇️
October 3, 2025 at 7:15 PM
Yes! enter TypeDis
similar to region types, TypeDis associates a task identifier or "timestamp", δ, with every allocation.
e.g. the type string@δ indicates that the string was allocated at time δ
Unboxed types don't need these annotations (e.g. raw integers, booleans, etc)
⬇️
similar to region types, TypeDis associates a task identifier or "timestamp", δ, with every allocation.
e.g. the type string@δ indicates that the string was allocated at time δ
Unboxed types don't need these annotations (e.g. raw integers, booleans, etc)
⬇️
parallel Boyer-Moore majority selection is a nice bit of code; here it is in MaPLe.
this algorithm seems to be folklore -- the original Boyer-Moore algorithm is sequential, but I've found at least two mentions of the parallel algorithm in the wild: ⬇️
this algorithm seems to be folklore -- the original Boyer-Moore algorithm is sequential, but I've found at least two mentions of the parallel algorithm in the wild: ⬇️
September 19, 2025 at 1:15 PM
parallel Boyer-Moore majority selection is a nice bit of code; here it is in MaPLe.
this algorithm seems to be folklore -- the original Boyer-Moore algorithm is sequential, but I've found at least two mentions of the parallel algorithm in the wild: ⬇️
this algorithm seems to be folklore -- the original Boyer-Moore algorithm is sequential, but I've found at least two mentions of the parallel algorithm in the wild: ⬇️
August 27, 2025 at 5:55 PM
when I first moved to NYC I started making two lists — places to go, and places I’ve been 🚶🏼♂️
now, almost exactly a year later, I’ve been to ~250 places and counting
love this city… so much to see
now, almost exactly a year later, I’ve been to ~250 places and counting
love this city… so much to see
August 13, 2025 at 6:29 PM
when I first moved to NYC I started making two lists — places to go, and places I’ve been 🚶🏼♂️
now, almost exactly a year later, I’ve been to ~250 places and counting
love this city… so much to see
now, almost exactly a year later, I’ve been to ~250 places and counting
love this city… so much to see
Alright so here we have two versions of the same loop, compiled on ARM.
The loops are identical except for the spilled locations for temps x10 and x11.
On the left, they are non-adjacent (see: two `str` near bottom).
On the right, they happen to be adjacent (see: `stp`)
The loops are identical except for the spilled locations for temps x10 and x11.
On the left, they are non-adjacent (see: two `str` near bottom).
On the right, they happen to be adjacent (see: `stp`)
July 24, 2025 at 10:09 PM
Alright so here we have two versions of the same loop, compiled on ARM.
The loops are identical except for the spilled locations for temps x10 and x11.
On the left, they are non-adjacent (see: two `str` near bottom).
On the right, they happen to be adjacent (see: `stp`)
The loops are identical except for the spilled locations for temps x10 and x11.
On the left, they are non-adjacent (see: two `str` near bottom).
On the right, they happen to be adjacent (see: `stp`)
oof, yep, looks like the (seemingly unrelated) compiler optimization somehow caused a temporary to be reassigned from register to stack, with ~20% additional spilling cost
July 24, 2025 at 2:57 PM
oof, yep, looks like the (seemingly unrelated) compiler optimization somehow caused a temporary to be reassigned from register to stack, with ~20% additional spilling cost
I wonder how it compares to MaPLe (github.com/mpllang/mpl)?
Here's an equivalent program in MaPLe, and corresponding timings for 1-8 threads.
Out of the box, MaPLe is ~2.5x faster here, pretty consistently across thread counts.
Here's an equivalent program in MaPLe, and corresponding timings for 1-8 threads.
Out of the box, MaPLe is ~2.5x faster here, pretty consistently across thread counts.
June 19, 2025 at 10:39 PM
I wonder how it compares to MaPLe (github.com/mpllang/mpl)?
Here's an equivalent program in MaPLe, and corresponding timings for 1-8 threads.
Out of the box, MaPLe is ~2.5x faster here, pretty consistently across thread counts.
Here's an equivalent program in MaPLe, and corresponding timings for 1-8 threads.
Out of the box, MaPLe is ~2.5x faster here, pretty consistently across thread counts.