Incremental – A library for incremental computations

https://github.com/janestreet/incremental

340 68 2 days ago

Kobe!

mempko• 2 days ago

I have built something similar like this for my fund 7 years ago. We were doing parametric optimization on large computational graphs. I have never programmed Ocaml but my understanding is introspection is kind of a weak spot for the language. Curious language choice! I know Ocaml is fast, about 1-2x speed of C, on par with Java.

hankbond• 2 days ago

Not trying to be pedantic but do you mean half the speed of C?

RandomBK2• 2 days ago

One thing I've never fully grokked is how this differs from an observable pattern where one can publish new values to inputs, propagate that through the computation, and push newly computed values to listeners.

I guess there's probably optimizations around change detection and stopping the propagation if there's no change (though observables can do that as well). The stabilize command also makes things interesting as a way to batch changes together before recomputing (but again, doable with observables too).

Is the delta primarily coming from introspection and automatically building the compute graph? Or is there something more fundamental that I'm missing?

blovescoffee• 2 days ago

Roughly, you subscribe and listen to an observable. Incrementals are more like a cache across some DAG of computation + state that lets you optimize by only recomputing what needs to be recomputed.

There's a really good talk from Ron Minsky here: https://www.janestreet.com/tech-talks/seven-implementations-...

Onavo• 2 days ago

Must make building backpropation algorithms really easy.

runtime_lens2• 2 days ago

That's how I was thinking about it too. At first glance it feels very close to reactive programming with dependency tracking. I'm curious whether the real advantage is the API ergonomics or if there are optimizations under the hood that wouldn't be practical with a typical observable implementation.

Eliah_Lakhin3• 2 days ago

It depends on how you define the observable pattern.

The fundamental components here are laziness and weak connections between graph nodes. Node values are getting materialized only when you observe them, and the system is flexible for live structural changes.

Usually, you don't need to materialize the entire graph when you need to observe just some nodes. Additionally, you can halt computations at any point in time leaving the graph in semi-actualized state, make extra changes to the inputs, and continue materialization of the nodes of interest. The algorithm will sort out all changes for you.

Essentially, incremental computations is just a term covering these features. You can organize the same system in terms of observers and subscribers.

Perhaps, classical Excel spreadsheets is the best illustration of the idea. Also, see my article on the topic: https://medium.com/@eliah.lakhin/salsa-algorithm-explained-c...

RandomBK2• 2 days ago

Laziness and weak connections makes sense as differentiators.

However I'm not sure Excel is such a great illustration in that case, as it's neither lazy nor weakly connected; at least at the surface.

geysersam• 2 days ago

What does weak connections mean in this context?

WorldMaker• 1 day ago

You can organize the same system in terms of observers and subscribers.

Also, the differences between "hot" and "cold" observers and the use of schedulers.

I like that about the observable pattern that while hot versus cold is confusing, it is generally "explicit" in the dance of observers/subscribers. I also tend to like the way that observable schedulers and scheduling operators are often usefully explicit in halting computations while still being largely automated in the time domain.

Certainly my gut instinct with this specific library is seeing if the stuff being done with it might be a cleaner fit in something like RxOcaml, but I realize I'm in something of a minority in preferring explicit observable operators over implicit "computation signals".

AlotOfReading• 2 days ago

I mean, it's fundamentally just a graph, but it's a way of correctly and efficiently computing changes in massive, dynamic graphs. Let's imagine you have a diamond shaped subgraph that fans out to hundreds of intermediary nodes before collapsing down again via and paths with different "lengths". And what if some of those paths have e.g. min(A, B) where the max side is the only one changing?

A naive observer approach will 1) compute that potentially exponential blow-up very inefficiently and 2) probably have "concurrency" issues. This library will be close to optimal and correct, even if you start dynamically changing the graph structure.

But yes, you can achieve the same thing with observers and other kinds of approaches. Most of them just a lot harder to get right while avoiding performance cliffs.

iamwil2• 2 days ago

https://www.scattered-thoughts.net/writing/an-opinionated-ma...

Can help map out the landscape.

fadesibert• 2 days ago

Goldman took the same approach with instrument pricing ~30 years ago. I recall long discussions about "Node Purpling" in my ~13 year tenure there.

Computer Science has evolved, and AFAICT this is not a graph approach, but things like differentiation are computationally expensive, and therefore you want to minimize the number of times you do it to as close to the theoretical minimum.

Edit: Related HN discussion https://news.ycombinator.com/item?id=36006737

zitterbewegung2• 2 days ago

Yea and this created "bank python" informally a good article is here.

https://calpaterson.com/bank-python.html

The best description about how it became a problem is one of the paragraphs.

"New starters take an exceptionally long time to get up to speed - and that's if they don't resign in fit of pique as soon as they see the special, mandatory, in-house IDE (as I nearly did). Even months in, new starters are still learning quite fundamental new things: there is a lot that is different."

I think it took me til I was there around two and a half years to fully comprehend it when I was working on it. Not much modern training til they figured out they had to teach it again that was better. The worst part is to make an UI around it coding it and it wasn't approved for new projects.

rwmj• 1 day ago

That article was fascinating, thanks for sharing it. I wonder if all banks use the same "bank Python" or if they all forked it in different ways?

27183• 1 day ago

Wow thanks for the link. My first reaction was "that's the jankiest thing I've ever heard of" but on reflection the author is correct about it being a fairly optimally fit predator. When the benchmark is .xlsx files on a shared drive things are bound to get pretty weird.

runtime_lens2• 2 days ago

One thing i have always linked about Jane street projects is that they tend to package ideas that have existed in research or niche system into something developers can actually use. Even if you never adopt the library, the design docs are usually worth reading.

raphinou• 2 days ago

I think websharper's Var are similar to this, and it is really great to develop dynamic web interfaces (in fsharp).

dh2022• 2 days ago

In C# a dependency graph that automatically updates only the affected dependencies can be implemented using events and/or functors and/or data binding.

I do not understand what is the big deal with Increment. Is it more efficient because it is written in OCaml rather than C#?

djtango• 2 days ago

I was very curious about Dataflow programming years ago - I think a lot of people were coming at this problem from various angles. This specific library immediately reminded me of Javelin from Clojure [0]

[0] https://github.com/hoplon/javelin

jitl3• 2 days ago

This style of reactive programming is quite popular in JavaScript UI frameworks these days under the moniker “signals”, with a proposal for standardization here: https://github.com/tc39/proposal-signals#-javascript-signals...

It’s used by frameworks Vue, SolidJS, Svelte, Ember, Angular, and there’s a few different implementations for React like Mobx and Jotai. There’s a few different algorithms for how to propagate changes and evaluate the DAG, I believe SolidJS2 uses a height-based algorithm similar to Incremental.

I’ve been fooling around with an implementation that uses an Int32Array arena to allocate nodes and link them together with linked lists without paying O(dependency edges) GC load: https://github.com/justjake/dalien-signals/tree/dalien-signa...

There are a few of these for Rust as well, Leptos is an example in UI frameworks, and Salsa is an example in general incremental computing, used in rust-analyzer.

Another way to look at this sort of thing is as a build system with automatically tracked dependencies. One such build system is tup, which instruments build jobs to detect what files they read to establish dependency relationships. Interesting reading from the author: https://gittup.org/tup/build_system_rules_and_algorithms.pdf, see also the classic Build Systems à la Carte https://www.microsoft.com/en-us/research/wp-content/uploads/...

avallach• 2 days ago

Another notable example: JetBrains Noria ( https://blog.jetbrains.com/fleet/2023/02/fleet-below-deck-pa... ).

As the authors highlight: "Noria is not a UI framework at its core. Instead, it’s a platform for incremental computations.". But currently they happen to use it to optimize gui rendering in JetBrains Air IDE.

tgv• 1 day ago

It looks as if there is a significant difference in treating updates to complex objects, and probably scheduling as well.

seanmcdirmid2• 1 day ago

You can build some lightweight dependency graphs that flush out quickly. You don’t need to describe how the signal has changed, just that it might have changed, then flush dependencies on change (some listeners might be notified of a change they don’t care about anymore) and re-register them when they come back for fresh data again.

But incremental computation isn’t exactly functional reactive programming. They are different domains in practice that often get thrown together because the problem they address can overlap. Incremental computation explicitly derives a function that can operate on deltas, FRP might just use damage and repair instead.

jitl3• 1 day ago

my understanding of FRP is the inverse of your description, I use the same definition of “functional reactive programming” as in this Jane Street blog post on the subject https://blog.janestreet.com/breaking-down-frp/ : FRP is history sensitive and wants to compute over some stream of events explicitly - and the sort of events we expect the system to handle are UI events like mouse motions, clicks, and FRP is expected to turn those into application semantics. Self-adjusting computation (like Incremental or js “signals” like alien-signals) is mostly history-insensitive by default because it’s lazy and seeks to recompute a node once during stabilize() no matter how many times an input changed since the last stabilize(). I definitely do not think “signals” in the JS/TC39 formulation of the concept is FRP: not nearly enough attention paid to first-class events.

but yeah to zoom out, the semantic boundaries and even definitions of terms in this area are kind of fuzzy and i don’t think it’s interesting to try too hard to sort stuff into a taxonomy unless you’re going to define all the parts of your taxonomy and provide a bunch of examples; these terms are not well-defined enough otherwise and arguing about ill-defined semantics is not my idea of a good time.

For example how to taxonomize something like Signia, which has fair bit of history sensitivity but is mostly concerned with diffs (https://signia.tldraw.dev/docs/incremental#using-diffs-in-co...), like Incremental uses logical clocks for validation, but is much more “pull” oriented in its recomputation/“stabilize” algorithm? To me it sounds like you’d put it in the “incremental computation” bucket because deltas; but Incremental itself doesn’t seem too concerned with deltas at the root of the library, i didn’t find any mention of them in the into docs and think it sounds more like js “signals”. https://github.com/janestreet/incremental/blob/master/src/in...

curtisblaine• 2 days ago

This reminds me of https://github.com/electric-sql/d2ts. Not sure they're comparable, but they seem to be aiming at the same problem.

geoHeil• 2 days ago

I maintain a similar library more focused on data engineering needs: https://docs.metaxy.io/ maybe it is useful for more people.

ronfriedhaber3• 2 days ago

This is cool.

As far as I can tell, incremental the library aims to solve the problem of partially hydrating a computation graph when source data is altered. This approach is similar to the one pursued by (well designed) build systems and is common in the FP world. [2] This has many use cases and is very cool.

In addition, in the sphere of incremental computation, there exists Differential Dataflow, Timely Dataflow (adjacent), and DBSP. Systems like Feldera are built on DBSP. Materialize is lead by some DD guys.

Personally, I am pursuing an orthogonal approach specifically for the problem of financial data and financial workloads, There exists huge, very important problems to solve! [1]

[1] https://modolap.com

[2] Signals And Threads episode on the subject https://signalsandthreads.com/build-systems/

valzam• 2 days ago

https://modolap.com

Redirect to a 2k USD stripe payment with no explanation when clicking on the main callout button is a pretty baller move.

ronfriedhaber3• 2 days ago

One man's baller is another man's insufficiently baller.

Email me for details, pricing & installations, or your target use case, would love to talk. In addition, if you have any feedback.

ron at modolap dot com

hantusk• 1 day ago

Check out https://github.com/ila/openivm which implements a very large scope of aggregations as incremental operations in an SQL-to-SQL compiler, and extension for duckdb that automatically maintains a materialized view

arthurbrown• 2 days ago

Another related but semantically distinct package with great developer ergonomics is the FRP library React -- https://erratique.ch/software/react/doc/React/index.html

Very satisfying to use when you manage to find a problem that is suited to this type of approach.

geokon• 2 days ago

Where is it actually explained how it works..?

Usually these kinds of systems either don't scale dynamically or have caching issues. The first example, a spreadsheet, is "easy" because there are a fixed amount of cells to track. A GUI can be a lot harder (imagine sub windows and sub-sub windows dynamically popping up and tracking some redundant and some unique "computations". Entities can appear and then be removed at random). Though the wording carefully says "constructing views" so maybe it doesn't handle dynamism

Balinares• 2 days ago

Whenever I see something in OCaml I assume it's Jane Street and that ends up correct a surprising amount of the time.

shikck200• 2 days ago

Jane street was/is a top user of ocaml, they kind of flushed their reputation down the toilet with they massive fraud in the asian markets. IIRC the entire company got banned from trading inside India, hongkong etc.

After they got caught most of their online posts/videos either got deleted, or locked so you could not comment on them.

I had hoped their front guy for ocaml, Ron Minsky had atleast made some sort of statement. Currently no ones know how deep that fraud went, but what we know ocaml was used in the fraud, damagine ocaml ecosystem too.

iamwil2• 2 days ago

For those interested in incremental systems, I recommend checking out DBSP. I thought it was pretty neat.

evomassiny• 2 days ago

Can't you solve it using hash trees (or Merkle trees) ?

You tag each computation nodes with a hash of its dependencies and some constant salt, that gives you an ID which identifies the results that the computation node would produce; before running it.

You can then use those IDs to index the computations results in a cache; whenever you query a computation results, as long as you update the IDs of each leaf of the computation graph, you will only re-compute the nodes that need to be updated

SkiFire13• 1 day ago

What you're describing is akin to a basic pull-based incremental engine, akin to salsa. The base design is straightforward, but you need some additional logic to avoid following the whole execution tree when hashing. Their downsides is that sometimes you do have to follow the whole execution tree, even if nothing changed.

Push-based designs instead "push" changes to their dependants, which can be quite efficient especially in the case where the update doesn't propagate much. However it has the downside of potentially requiring to update nodes that are no longer used, or updating nodes multiple times.

pgt• 2 days ago

Electric Clojure does incremental rendering that crosses the client/server boundary: http://electric.hyperfiddle.net/

The closest thing to Electric (IMO) is SolidJS, but frontend only: https://www.solidjs.com/

srean• 2 days ago

It might be worth reading this in concert with

https://hn.algolia.com/?q=flow+based+programming+

osener• 1 day ago

If you find this interesting, also check out their UI library called Bonsai that built on top of Incremental: https://github.com/janestreet/bonsai/

Libraries like React are pretty efficient with skipping work by using Virtual Dom, but constructing this vdom still takes time. Bonsai makes the vdom incremental and it is pretty fun to work with.

I built a desktop UI library with it by targeting (now unmaintained) Revery. It is using a much older version of Bonsai however: https://github.com/ozanvos/bonsai_revery

xiaodai• 1 day ago

pardon my ignorance but is Ocaml performant enough? Why isn't something like this coded in say, C++?

klibertp• 3 hours ago

It tends to be. While it does use a GC, it has both bytecode and native AOT compilers. When compiled to native, it's closer in performance to C++ and Rust than to C# or Java. It's a reasonable middle ground in PL design that Nim also tries to occupy. In recent years, OCaml's runtime also shed the GIL, making it a good solution for parallelizable, CPU-bound tasks. As a language, OCaml is one of the most impressive ones (in terms of features and capabilities), yet it still provides strong, practical tooling, good performance, and access to low-level-ish features.

TL;DR: OCaml is usually going to be a bit slower than C++, but faster than Java, while rivaling Rust and Haskell in terms of expressive power.

Caveat: a lot of the power comes from the tooling. Last I checked, syntax extensions were external preprocessors, just with standardized APIs. And you need those extensions for things that are handled by (in-language) macros in Rust (like deriving string representation for a record). Without the tooling, OCaml can get a bit tedious/boilerplate-y. OTOH, after a period of instability and competing solutions, the tooling mostly settled down, and enabling the important parts is often a single line in the config. It's not a situation unique to OCaml, but if you look at the language docs only, you'll miss half of what OCaml development normally offers.

lsuresh• 1 day ago

Over at Feldera, we focus on IVM for SQL, but incremental computing problems show up far and wide: UIs, spreadsheets, control planes, compilers and more.

shortercode• 1 day ago

Oh cool I was working on something similar awhile back and couldn’t find much precedent. The project got retired as our use case went away. But I’d love to revisit it. It’s still on npm as “data-rambler”.

Idea was a DSL that could be loaded into a JS runtime, then fed data streams. Your module would transform that data into various output streams which could then be fed to a separate reporting library. Powering dynamic reports based on a template.

Our first iteration was already pretty powerful but I had some big plans to bring it into a more JS feeling syntax to reduce complexity.

erichocean2• 1 day ago

Parallel Self-Adjusting Computation[0] is a fun entry in this genre.

[0] https://github.com/cmuparlay/psac

atombender• 1 day ago

This library is based in part on that same paper.

jimaway1233• 1 day ago

Is anyone aware of a version of this focused on very speed sensitive, low-level incremental computation? Like perhaps a compiler that generated a kernel for doing an incremental computation on a static graph?

tempfile• 1 day ago

Given this is a Jane Street library, I would be surprised if it were not very speed-sensitive already.

erichocean2• 1 day ago

https://github.com/cmuparlay/psac is extremely fast, I use it to recompute sculpting topology updates (think: Zbrush DynaMesh) at 60 fps.

jimaway1233• 1 day ago

Yes I can see it would be pretty fast, but the computation is defined at run time and its evaluation uses pointers to the various nodes of the computation graph. This limits what optimizations be applied (ie inlining, vectorization, reordering, etc). I'm just curious if anyone has taken this a step further and written something like PSAC except with a code-generation step that creates an optimized implementation of psac_propagate() for the specific computation graph.

eyupucmaz• 1 day ago

Interesting to see JaneStreet's take on incremental computation. As a frontend engineer working with React state management (Zustand, Jotai), the concept of granular re-computation is very familiar — though the OCaml type system gives this a level of correctness guarantees that JS solutions can only dream of.

Magicrafter13• 1 day ago

I don't understand how to use this library, as it doesn't seem to indicate what language it is for, but the concept sounds very cool.

woggy• 24 hours ago

OCaml

lilactown• 1 day ago

One of my favorite tech talks is "Seven implementations of incremental": https://www.janestreet.com/tech-talks/seven-implementations-...

Incremental – A library for incremental computations

Related Stories