Use Cases

[jrevels]

I've talked to a lot of nice folks recently about the potential Cassette use cases. Here's are the ones I remember:

• chain-rule + primitive based
  • disciplined convex programming (e.g. Convex.jl)
  • differentiation (e.g. ForwardDiff, ReverseDiff)
  • subdifferentiation (subgradients)
  • interval constraint programming (primitive = inverse, chain rule = set intersection) (e.g. IntervalConstraintProgramming.jl)
• dynamic analysis/optimization
  • memoization (types/storage/values) (@juan-pablo-vielma has applications for randomized algorithms)
  • serial memory/operation scheduling
  • parallel memory/operation scheduling
  • computation graph rewriting (e.g. CSE)
  • profiling (call counts, memory usage, etc.)
  • debugging
  • fuzzing
  • stochastic arithmetic (numeric fuzzing)
• coprocessor usage/management (e.g. GPUArrays.jl, CUDANative.jl)

[willow-ahrens]

Unless I am mistaken, it is also possible to use casette as an alternative to subtyping concrete types, right? I would like to add my reproducible floating point type to the possible list of applications, as well as others who would like to create types which are identical to concrete types except for a few modifications of how certain functions dispatch on the types.

[jrevels]

Unless I am mistaken, it is also possible to use casette as an alternative to subtyping concrete types, right?

It depends on what you mean. I wouldn't call it an "alternative to subtyping concrete types", since the latter is ambiguous/ill-defined.

as well as others who would like to create types which are identical to concrete types except for a few modifications of how certain functions dispatch on the types.

This isn't what Cassette is doing, but if I understand you correctly, then yes - Cassette enables a different approach that should let you achieve the same goal (hijacking dispatch for only a subset of operations without worrying about implementing a full type interface).

[cstjean]

What's the short summary of how Cassette works? Which function is the one that drills into Julia's entrails?

[jrevels]

What's the short summary of how Cassette works?

Once my JuliaCon 2017 talk is up on YouTube, that should be an okay resource (near the end of the talk). Otherwise, the entry point for the actual tracing mechanism is in src/tracing.jl. Note that actually running Cassette relies on JuliaLang/julia#22440, and there are still a bunch of bugs.

Everything is in a very early stage - we still require some core Julia development before a truly robust Cassette implementation can exist. Cassette code is subject to drastic change, which is why I haven't documented anything and only have some minor smoke tests.

[maleadt]

coprocessor usage/management (e.g. GPUArrays.jl, CUDANative.jl)

Definitely keeping my eye on this for multiple use cases. Primary one, as discussed on juliacon, altering dispatch: eg. calls to Base.sin -> CUDAnative.sin if executing on the GPU.
Maybe also for users to define multiple methods based on the hardware generation (could also apply to CPU programs, eg. dispatching to cache-optimized implementations).

A second use case I thought about: dynamic parallelism, aka. kernels launching kernels. For example:

# from CPU
@cuda kernel()

function kernel()
    # from GPU
    @cuda another_kernel()
end

As @cuda doesn't boil down to regular function calls, the inner @cuda would need to record exactly which method is called and propagate that to the outermost @cuda, where all method chains can be compiled to PTX and linked together. And inference edges need to be added from another_kernel to kernel.
Would that be possible with Cassette.jl?

[jrevels]

As @cuda doesn't boil down to regular function calls, the inner @cuda would need to record exactly which method is called and propagate that to the outermost @cuda, where all method chains can be compiled to PTX and linked together. And inference edges need to be added from another_kernel to kernel.
Would that be possible with Cassette.jl?

I think so, but it depends on what you mean w.r.t. to adding inference edges. Cassette doesn't expose any type inference facilities - it only uses the normal Julia reflection capabilities (well, they will be "normal" by Julia 1.0, hopefully) - so it doesn't provide any new way to manually add inference edges. Of course, you can replace function calls with other function calls, and type inference runs normally on all of this code, such that any necessary new edges should be added automatically via type inference.

Note that Cassette specifically intercepts lowered code, so macros like e.g. @cuda will have been expanded by that point. All the "interception pass" does is wrap subcalls in the CodeInfo with a calling context; the context creator decides (via normal method dispatch) what it means to call something with that context.

Not sure if this is valuable to you, but you can certainly use macros to drop "markers" into your code for Cassette to pick up (e.g. in order to cue specialized processing).

[maleadt]

it doesn't provide any new way to manually add inference edges

Oh yeah I know, but Cassette.jl would give me all the necessary information to call jl_method_*_add_backedge or smth.

you can certainly use macros to drop "markers" into your code for Cassette to pick up (e.g. in order to cue specialized processing).

That would be valuable indeed, the macro's are just how I'd like to model the user-facing API, regardless of what they boil down to.

[jw3126]

Could I implement a @inbounds and @boundscheck like mechanism using Cassette?
How would I drop a boundscheck marker for Cassette to pick up?
Would I use Expr(:meta, :my_boundscheck_marker) or is there another mechanism?

[jrevels]

Yes, you could just drop a meta Expr node (e.g. using some source code annotation), and then you should be able to pick it back up again in your Cassette pass. That's currently how the front end usually passes messages to the compiler.

[lstagner]

I've been looking into probabilistic programming and I think Cassette could be used. There seems to be two approaches to probabilistic programming languages. The approach taken by Stan and Turing.jl is by specify the log likelihoods and doing Hamiltonian Monte Carlo. An alternative approach taken by Anglican and others is to do Sequential Monte Carlo(and others) with the execution trace of the program. This strategy is described in [1] and [2]

[1] Wingate, David, Andreas Stuhlmüller, and Noah Goodman. "Lightweight implementations of probabilistic programming languages via transformational compilation." Proceedings of the Fourteenth International Conference on Artificial Intelligence and Statistics. 2011. [PDF]

[2] Accelerating Data Science with HPC: Probabilistic Programming [YouTube]

[datnamer]

@jrevels Do you have any ballpark idea how far off a cassette based autodiff is?

[jrevels]

See https://github.com/JuliaDiff/Capstan.jl for an initial proof-of-concept; once Cassette is release-ready, however, my approach in Capstan may look drastically different, since the approach currently there was just to test out some basic ideas.

For example, one of the main motivators for Cassette's pass injection mechanism was to allow the use of Julia IR + native language constructs to build the tape rather than be limited to a non-code graph data structure. However, Capstan doesn't show any of that off yet, since that's just an implementation detail compared to the stuff I needed to demo at the time I made the package.

Also, I haven't been bothering to keep Capstan up-to-date with Cassette, and won't be concerned with doing so until I can tag a Cassette release.

The plan since last year has been to have an initial Capstan release around JuliaCon 2018, but we'll see how it goes. The big blocker right now to even working on Capstan is JuliaLang/julia#25492, and the bulk of my day-to-day Julia coding right now is plugging away at that issue. If progress continues the current trend (i.e. I don't run into too many big unexpected items), we should be on track.

[jrevels]

Closing since this was just an early discussion issue, and has no action items. Feel free to keep discussing here though.

[datnamer]

@jrevels Thanks, doesn't sound too far off. This is all really exciting!