Skip to content

Cache and Scratch #1138

Open
Open
@Affie

Description

@Affie

So I really like:

  • Cache: operational memory used by default solver routines during compute in hot-loops etc for maximizing performance of source code. E.g. storing calculated gradients, hypothesis recipes, or ode-solutions. Good solver will keep this isbitstype == true. Any non-standard in-memory objects should instead use the "scratch" field.
  • Scratch: Custom in-memory location generally associated with the loading or saving of objects, for holding case-by-case in-memory values that accelerate the compute tasks. "Scratch" is available for custom designs of e.g. factors whereby the developer wishes to manually craft in-place objects to optimize compute operations - e.g. loading lidar blobs from storage into a factor scratch as well as faster rigid transform registration compute techniques. Up to user to be good developer and eventually get .scratch to isbitstype == true, but doesn't have to be on day one. In contrast, solver default routines should instead use the "cache" field.

This means that any time a sampler or residual function runs, the user will have access to the CalcFactor object's mutable memory:

  • calcfactor.scratch: here user/developer does their custom work to make the machine go. Also whatever the user setup on factor load/add.
  • calcfactor.cache: in-place solver stored values such as gradients or whatever else happens per default.

Remember the solver design is going down road of always creating a new CalcFactor object for each independent thread. I.e. calcfactor.* only lasts as long as the thread/hot-loop used to compute with it.

Then there is also the issue of parching, e.g. load a FactorCompute from DBDFG or FileDFG such as lidar registration where .laz files representing two point clouds are stored as blobs. Then the preambleScratch function would run once and a user is responsible for something like scratch.pc1 = getBlob(parchedfactor.pointcloud1blobid,...). We have a first example of this, let me see if I can find... yes all the ObjectAffordSubcloud stuff: https://github.com/JuliaRobotics/Caesar.jl/blob/9df2df54d4a1bc271afafd5730d35c95af4c67f5/src/objects/ObjectAffordanceSubcloud.jl#L241

Originally posted by @dehann in #1127 (comment)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions