docs: improve runtime activity FAQ and fix MWE#2559
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2559 +/- ##
=======================================
Coverage 74.92% 74.92%
=======================================
Files 56 56
Lines 17437 17437
=======================================
Hits 13065 13065
Misses 4372 4372 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Running into JuliaDocs/Documenter.jl#1420, will fix |
| Enzyme.autodiff(Forward, g, Const(condition), Duplicated(x, dx), Const(y)) | ||
| x, dx = [1.0], [2.0]; | ||
| y = [3.0]; | ||
| cond = false; # return the constant variable |
There was a problem hiding this comment.
let's still call it condition to not confuse the name of the function parameter from the input to the call
| However, care must be taken to check derivative aliasing afterwards: | ||
|
|
||
| ```@example runtime | ||
| dout === out # if true, the actual derivative is zero |
There was a problem hiding this comment.
add the comment "and pointer-like"
There was a problem hiding this comment.
I wanted to ask: what is the precise definition of "pointer-like" in Julia terms, and what does it mean for two objects to be aliased in that way? I thought that it meant either a === b or pointer(a) == pointer(b), as your docs suggest, but I found out that these conditions are not equivalent, and that the latter can only be checked for Arrays and a few other concrete types. See JuliaDiff/DifferentiationInterface.jl#666 (comment) for details and JuliaDiff/DifferentiationInterface.jl#850 for my current attempt in DI.
There was a problem hiding this comment.
whether the layout of the julia object in memory is a pointer
There was a problem hiding this comment.
Okay, then what is the proper way to test aliasing for Enzyme's runtime activity feature in general? Because === seems wrong based on my tests and pointer works for a very limited set of types
There was a problem hiding this comment.
not sure offhand julia-side, I'm guessing there's some feature for determining type layout
There was a problem hiding this comment.
For instance, in this case, the check a === b doesn't suffice to detect aliasing:
julia> x = [1.0];
julia> mutable struct S
x::Vector{Float64}
end
julia> a = S(x);
julia> b = S(x);
julia> a === b
falseThere was a problem hiding this comment.
convert(LLVMType, julia_type; allow_boxed=true) isa LLVM.PointerType ought work always but not an answer you want @gdalle
There was a problem hiding this comment.
Base.DataTypeFieldDesc may also be helpful here
There was a problem hiding this comment.
convert(LLVMType, julia_type; allow_boxed=true) isa LLVM.PointerType ought work always but not an answer you want @gdalle
How am I supposed to use it?
julia> using LLVM
julia> convert(LLVMType, Vector{Float64}; allow_boxed=true)
ERROR: No LLVM context is active
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35
[2] context(; throw_error::Bool)
@ LLVM ~/.julia/packages/LLVM/UFrs4/src/state.jl:22
[3] context
@ ~/.julia/packages/LLVM/UFrs4/src/state.jl:20 [inlined]
[4] convert(::Type{LLVMType}, typ::Type; allow_boxed::Bool)
@ LLVM.Interop ~/.julia/packages/LLVM/UFrs4/src/interop/base.jl:73
[5] top-level scope
@ REPL[25]:1Base.DataTypeFieldDesc may also be helpful here
I don't know what this does and it seems private?
help?> Base.DataTypeFieldDesc
│ Warning
│
│ The following bindings may be internal; they may change or be removed in future versions:
│
│ • Base.DataTypeFieldDesc
No documentation found for private symbol.Besides, users would also need a way to compare the locations to which these "pointer-like" objects point, in order to detect aliasing
There was a problem hiding this comment.
I'd be happy if Enzyme provided Enzyme.is_pointerlike(x::Any) and Enzyme.are_aliased(x::T, y::T) where {T} with the precise semantics that you want, to use in runtime activity correctness checking. Expecting the users to go through this level of sophistication seems doomed to fail
Have opened #2587 to keep track so that we may merge this docs fix
The function in the MWE was missing an
end, so I made it executable to prevent this kind of bug (I didn't go for a full doctest because of the exception stack trace)