#@Erik Sipsma speaking of egraph.

1 messages · Page 1 of 1 (latest)

sly nest
#
  1. A lot, things that come to mind right away:
    • A robust + high performance remote caching system
    • User-facing tools for understanding when and why cache hits do or don't happen
    • More flexible module execution models that would get us better performance while retaining cache-ability
  1. The scenario in 8955 is a good example
  1. Here's the funny thing, I didn't actually look into it yet because I didn't have to. I just removed the buildkit caching logic and replaced it with our new one and the problem disappeared spontaneously.

I can tell you that it makes perfect sense for the scenario there to be cached because it's executing the same step twice. In our new caching system, there is a single place where we calculate the cache key for the operation and do a lookup. It's simple and possible to understand.

When we were using buildkit, there were two caching systems (dagql and buildkit) tied together in confusing ways. And in the buildkit cache specifically the logic is extremely complex and convoluted.

The point here is that one of the biggest benefits is just having a cache system that's understandable and robust. When it's possible to understand the caching logic, you will have less bugs. And when there are bugs, they are much easier to de-bug.

  1. Remote caching is my top priority, but improving user-facing cache observability is a close second and also something that will be a continuous effort as part of any other work
sly nest
#

@ripe wind to be clear, this isn't merged yet, so shouldn't go in v0.20.1 changelog.

ripe wind