Skip to content

Conversation

penelopeysm
Copy link
Member

@penelopeysm penelopeysm commented Jul 6, 2025

Bump compat for AbstractPPL following TuringLang/AbstractPPL.jl#123.

The test failure on 1.10 (CI log here) was, bizarrely, due to Julia inferring Union{Missing,Bool} for all(Base.Fix1(istrans, vi), vns) (inside the definition of istrans):

function istrans(vi::AbstractVarInfo, vns::AbstractVector)

using DynamicPPL
model = DynamicPPL.TestUtils.DEMO_MODELS[1]
vi = VarInfo(model)
vns = keys(vi)

julia> @code_warntype istrans(vi)
MethodInstance for DynamicPPL.istrans(::VarInfo{@NamedTuple{s::DynamicPPL.Metadata{Dict{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}, Int64}, Vector{Distributions.InverseGamma{Float64}}, Vector{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}}, Vector{Float64}}, m::DynamicPPL.Metadata{Dict{VarName{:m, typeof(identity)}, Int64}, Vector{Distributions.DiagNormal}, Vector{VarName{:m, typeof(identity)}}, Vector{Float64}}}, Float64})
  from istrans(vi::AbstractVarInfo) @ DynamicPPL ~/ppl/dppl/src/abstract_varinfo.jl:482
Arguments
  #self#::Core.Const(DynamicPPL.istrans)
  vi::VarInfo{@NamedTuple{s::DynamicPPL.Metadata{Dict{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}, Int64}, Vector{Distributions.InverseGamma{Float64}}, Vector{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}}, Vector{Float64}}, m::DynamicPPL.Metadata{Dict{VarName{:m, typeof(identity)}, Int64}, Vector{Distributions.DiagNormal}, Vector{VarName{:m, typeof(identity)}}, Vector{Float64}}}, Float64}
Body::Union{Missing, Bool}
1%1 = DynamicPPL.keys(vi)::Vector{VarName}%2 = DynamicPPL.collect(%1)::Vector{VarName}%3 = DynamicPPL.istrans(vi, %2)::Union{Missing, Bool}
└──      return %3

This is technically not wrong, because all(f, xs) returns missing if f(x) === missing for any x in xs. The compiler can only infer Bool if it knows that none of the f(x)'s are missing.

So, this suggests that I should check for a loss of type stability in @code_warntype istrans(vi, vns[1]), right? Well, turns out that that's perfectly type stable:

julia> @code_warntype istrans(vi, vns[1])
MethodInstance for DynamicPPL.istrans(::VarInfo{@NamedTuple{s::DynamicPPL.Metadata{Dict{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}, Int64}, Vector{Distributions.InverseGamma{Float64}}, Vector{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}}, Vector{Float64}}, m::DynamicPPL.Metadata{Dict{VarName{:m, typeof(identity)}, Int64}, Vector{Distributions.DiagNormal}, Vector{VarName{:m, typeof(identity)}}, Vector{Float64}}}, Float64}, ::VarName{:s, Accessors.IndexLens{Tuple{Int64}}})
  from istrans(vi::VarInfo, vn::VarName) @ DynamicPPL ~/ppl/dppl/src/varinfo.jl:1011
Arguments
  #self#::Core.Const(DynamicPPL.istrans)
  vi::VarInfo{@NamedTuple{s::DynamicPPL.Metadata{Dict{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}, Int64}, Vector{Distributions.InverseGamma{Float64}}, Vector{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}}, Vector{Float64}}, m::DynamicPPL.Metadata{Dict{VarName{:m, typeof(identity)}, Int64}, Vector{Distributions.DiagNormal}, Vector{VarName{:m, typeof(identity)}}, Vector{Float64}}}, Float64}
  vn::VarName{:s, Accessors.IndexLens{Tuple{Int64}}}
Body::Bool
1%1 = DynamicPPL.getmetadata(vi, vn)::DynamicPPL.Metadata{Dict{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}, Int64}, Vector{Distributions.InverseGamma{Float64}}, Vector{VarName{:s, Accessors.IndexLens{Tuple{Int64}}}}, Vector{Float64}}
│   %2 = DynamicPPL.istrans(%1, vn)::Bool
└──      return %2

# same for vns[2] and vns[3] as well ....... so what on earth is happening?!

Anyway, I fixed this by manually expanding the definition of all. I spent a while looking into this with Cthulhu, but I eventually concluded that it wasn't really worth my time, because it works perfectly fine on 1.11, indicating that this is a Julia issue rather than our code being fundamentally wrong.

I had hoped that we could solve this by bumping the minimum patch version of Julia, but even the latest 1.10.10 release has this 'problem'.

Copy link
Contributor

github-actions bot commented Jul 6, 2025

Benchmark Report for Commit aaa1e8d

Computer Information

Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 4 × AMD EPYC 7763 64-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver3)
Threads: 1 default, 0 interactive, 1 GC (on 4 virtual cores)

Benchmark Results

|                 Model | Dimension |  AD Backend |      VarInfo Type | Linked | Eval Time / Ref Time | AD Time / Eval Time |
|-----------------------|-----------|-------------|-------------------|--------|----------------------|---------------------|
| Simple assume observe |         1 | forwarddiff |             typed |  false |                  9.3 |                 1.6 |
|           Smorgasbord |       201 | forwarddiff |             typed |  false |                745.7 |                36.8 |
|           Smorgasbord |       201 | forwarddiff | simple_namedtuple |   true |                354.6 |                58.4 |
|           Smorgasbord |       201 | forwarddiff |           untyped |   true |               1206.6 |                29.2 |
|           Smorgasbord |       201 | forwarddiff |       simple_dict |   true |               3227.8 |                24.6 |
|           Smorgasbord |       201 | reversediff |             typed |   true |               1466.6 |                28.8 |
|           Smorgasbord |       201 |    mooncake |             typed |   true |                987.1 |                 5.0 |
|    Loop univariate 1k |      1000 |    mooncake |             typed |   true |               5349.2 |                 4.0 |
|       Multivariate 1k |      1000 |    mooncake |             typed |   true |               1000.1 |                 8.9 |
|   Loop univariate 10k |     10000 |    mooncake |             typed |   true |              60486.2 |                 3.9 |
|      Multivariate 10k |     10000 |    mooncake |             typed |   true |               9118.4 |                 9.3 |
|               Dynamic |        10 |    mooncake |             typed |   true |                137.5 |                12.0 |
|              Submodel |         1 |    mooncake |             typed |   true |                 13.8 |                 6.2 |
|                   LDA |        12 | reversediff |             typed |   true |                456.4 |                 5.0 |

Copy link

codecov bot commented Jul 6, 2025

Codecov Report

Attention: Patch coverage is 63.15789% with 7 lines in your changes missing coverage. Please review.

Project coverage is 83.00%. Comparing base (92f6eea) to head (aaa1e8d).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
src/utils.jl 41.66% 7 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #970      +/-   ##
==========================================
+ Coverage   82.98%   83.00%   +0.01%     
==========================================
  Files          36       36              
  Lines        3961     3965       +4     
==========================================
+ Hits         3287     3291       +4     
  Misses        674      674              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@coveralls
Copy link

coveralls commented Jul 6, 2025

Pull Request Test Coverage Report for Build 16114056967

Details

  • 12 of 19 (63.16%) changed or added relevant lines in 3 files are covered.
  • 81 unchanged lines in 11 files lost coverage.
  • Overall coverage increased (+0.02%) to 83.169%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/utils.jl 5 12 41.67%
Files with Coverage Reduction New Missed Lines %
ext/DynamicPPLForwardDiffExt.jl 1 63.64%
src/utils.jl 1 73.97%
src/contexts.jl 2 74.79%
src/experimental.jl 3 0.0%
src/model.jl 3 84.17%
src/compiler.jl 4 85.25%
src/simple_varinfo.jl 4 75.14%
src/varinfo.jl 4 84.14%
ext/DynamicPPLJETExt.jl 16 0.0%
src/test_utils/ad.jl 21 0.0%
Totals Coverage Status
Change from base Build 16056208518: 0.02%
Covered Lines: 3291
Relevant Lines: 3957

💛 - Coveralls

@penelopeysm penelopeysm marked this pull request as draft July 6, 2025 23:31
Copy link
Contributor

github-actions bot commented Jul 7, 2025

DynamicPPL.jl documentation for PR #970 is available at:
https://TuringLang.github.io/DynamicPPL.jl/previews/PR970/

@penelopeysm penelopeysm marked this pull request as ready for review July 7, 2025 00:31
Comment on lines -484 to 493
return !isempty(vns) && all(Base.Fix1(istrans, vi), vns)
# This used to be: `!isempty(vns) && all(Base.Fix1(istrans, vi), vns)`.
# In theory that should work perfectly fine. For unbeknownst reasons,
# Julia 1.10 fails to infer its return type correctly. Thus we use this
# slightly longer definition.
isempty(vns) && return false
for vn in vns
istrans(vi, vn) || return false
end
return true
end
Copy link
Member Author

@penelopeysm penelopeysm Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See main PR comment for rationale (if interested). This is the only meaningful change in this PR, the rest is quite mundane

Copy link
Member

@mhauru mhauru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the AbstractPPL changes, very happy to be rid of the VN comparison bug. By extension of course happy with these changes too. Just one performance related question.

@@ -356,13 +356,15 @@ function BangBang.setindex!!(vi::SimpleVarInfo, vals, vns::AbstractVector{<:VarN
return vi
end

function BangBang.setindex!!(vi::SimpleVarInfo{<:AbstractDict}, val, vn::VarName)
function BangBang.setindex!!(
vi::SimpleVarInfo{<:AbstractDict}, val, vn::VarName{sym}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that VarName{sym} where {sym} function signatures might change performance, because they force specialisation on that argument. If they would, and if they would make it worse, this could always be circumvented with a getsymbol(vn::VarName{sym}) = sym function (probably that exists already).

I tried to compare these two benchmark results to see if there is an effect: #970 (comment) and #966 (comment). It does look like everything has gotten a bit slower, but this could easily be a GHA benchmarking fluctuation. If it's not too much trouble, would you be happy to check the benchmarks locally in a more controlled environment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's a really good catch. I think this is the only function which might be on a performance-sensitive path, but I'll change them all back anyway. The old definition of VarName(vn, optic) was VarName{getsym(vn)}(optic) so sticking to that should preserve exactly the same behaviour as before.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had looked at the benchmarks as I was worried about the type stability thing -- isn't this PR faster on most of them (though I imagine very much within error?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverting this fixed the original istrans type instability, but now there's another one. This might take a while.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the links above this PR is a bit slower on most. I wouldn't put any serious stock into those benchmarks without trying them in a more stable environment first though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also be happy with a conclusion that the VarName{sym} where {sym}signatures have no (noticable) impact on benchmarks and this can be merged as-is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, to my relief, it wasn't a different type stability problem, it was the same one. So the same fix (manually expanding all) still works.

Benchmarked smorgasboard:

using DynamicPPL, Distributions, BenchmarkTools
@model function smorgasbord(x, y, ::Type{TV}=Vector{Float64}) where {TV}
    @assert length(x) == length(y)
    m ~ truncated(Normal(); lower=0)
    means ~ product_distribution(fill(Exponential(m), length(x)))
    stds = TV(undef, length(x))
    stds .~ Gamma(1, 1)
    for i in 1:length(x)
        x[i] ~ Normal(means[i], stds[i])
    end
    y ~ product_distribution(map((mean, std) -> Normal(mean, std), means, stds))
    0.0 ~ Normal(sum(y), 1)
    return (; m=m, means=means, stds=stds)
end
m = smorgasbord(randn(100), randn(100))
vi = VarInfo(m)
ctx_def = DefaultContext()
ctx_spl = SamplingContext()

Main:

julia> @benchmark DynamicPPL.evaluate!!($m, $vi, $ctx_def)
BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min  max):  11.250 μs  52.083 μs  ┊ GC (min  max): 0.00%  0.00%
 Time  (median):     12.292 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   12.525 μs ±  1.371 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

    ▂  ▃▃▃▃▄▄█▂▃▁  ▁
  ▃▇█▆▄███████████▇█▆▅▄▃▂▄▄▃▃▃▂▂▂▂▂▁▁▂▂▁▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ ▃
  11.2 μs         Histogram: frequency by time        16.6 μs <

 Memory estimate: 16.94 KiB, allocs estimate: 321.

julia> @benchmark DynamicPPL.evaluate!!($m, $vi, $ctx_spl)
BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min  max):  20.416 μs  129.583 μs  ┊ GC (min  max): 0.00%  0.00%
 Time  (median):     23.208 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   23.595 μs ±   2.289 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

             ▂▃▆▆█▅▃▃▂
  ▁▁▂▂▃▂▃▄▅▇████████████▆▆▅▅▄▃▃▃▃▂▃▂▂▂▂▂▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ ▃
  20.4 μs         Histogram: frequency by time         30.6 μs <

 Memory estimate: 17.75 KiB, allocs estimate: 333.

This PR:

julia> @benchmark DynamicPPL.evaluate!!($m, $vi, $ctx_def)
BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min  max):  11.375 μs   3.182 ms  ┊ GC (min  max): 0.00%  98.77%
 Time  (median):     12.083 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   12.548 μs ± 31.706 μs  ┊ GC (mean ± σ):  2.50% ±  0.99%

    ▂ ▇█ █▇▇ ▆▄ ▃▁
  ▂▅███████████▆███▄▆▅▃▄▄▄▃▃▃▃▃▂▃▂▂▂▂▂▂▂▂▂▂▂▂▂▂▁▂▂▁▂▂▂▂▂▂▂▂▂▂ ▄
  11.4 μs         Histogram: frequency by time        15.6 μs <

 Memory estimate: 16.94 KiB, allocs estimate: 321.

julia> @benchmark DynamicPPL.evaluate!!($m, $vi, $ctx_spl)
BenchmarkTools.Trial: 10000 samples with 1 evaluation per sample.
 Range (min  max):  21.333 μs   7.169 ms  ┊ GC (min  max): 0.00%  99.12%
 Time  (median):     24.083 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   25.260 μs ± 71.474 μs  ┊ GC (mean ± σ):  2.81% ±  0.99%

             ▁▇▅█▄▆▃▆▁▃▁▂
  ▂▂▁▂▁▂▂▂▃▃▇████████████▇█▅▇▆▇▅▆▄▄▄▄▄▄▄▄▃▃▃▃▃▃▂▃▂▃▂▂▂▂▂▂▂▂▂▂ ▄
  21.3 μs         Histogram: frequency by time        29.9 μs <

 Memory estimate: 17.75 KiB, allocs estimate: 333.

Copy link
Member

@mhauru mhauru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @penelopeysm!

@penelopeysm penelopeysm added this pull request to the merge queue Jul 7, 2025
Merged via the queue into main with commit acac44d Jul 7, 2025
20 of 21 checks passed
@penelopeysm penelopeysm deleted the py/appl0.12 branch July 7, 2025 11:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants