A new AD interface in AbstractPPL

Most of our time went into reorganising how automatic differentiation works. It now goes through a small interface in AbstractPPL, rather than each package calling DifferentiationInterface (DI) directly. ForwardDiff and Mooncake get native paths, and everything else still goes through DI.

• AbstractPPL@0.15 adds the prepared-evaluator interface, and fixes a Mooncake reverse-mode correctness bug (#1238).
• DynamicPPL@0.42 moves onto this interface and drops DI as a hard dependency, so DI-routed backends such as ReverseDiff now need using DifferentiationInterface (changelog).
• Bijectors@0.16 moves ChainRulesCore and EnzymeCore to weak dependencies.
• AdvancedVI@0.7 follows suit. AutoReverseDiff(; compile=true) is no longer accepted for VI (changelog).
• Turing@0.46 brings this together (changelog).

DoodleBUGS is now DoodlePPL

DoodleBUGS has a new name. It’s now DoodlePPL, and you can try it here. It generates Stan code from a graph now, as well as BUGS and JuliaBUGS, and you can embed it in any page as a web component.

MCMC.js

The editor is developed in MCMC.js (npm i -g mcmcjs), a set of TypeScript command-line tools for running and diagnosing Bayesian models across Turing.jl, JuliaBUGS, and Stan. It’s early alpha and the CLI isn’t stable yet, so do have a play with it, but don’t build anything important on it just yet.

As always we’re a small team with a long to-do list, so if any of this is useful, or if you hit rough edges, do get in touch!

That said, this time there are plenty of interesting stuff! We’ve rewritten quite a lot of things from scratch and now released them.

• AbstractPPL@0.14 has a completely new VarName data structure. The high-level interface is still the same @varname(x[a].b) but you can now represent richer variable names, most notably begin and end indices, as well as keyword indices.

• Bijectors@0.15.17 has a new interface for converting samples from distributions to/from vectors. This is a slightly less pretty interface than the old Bijectors interface (which still exists), but is more tailored towards Turing’s needs and as a result you’ll get a nice performance boost from it (some benchmarks here), as well as fixing a number of bugs with unusual product distributions and LKJCholesky. This is bundled into the latest Turing release, no need to do anything on your end.

• DynamicPPL@0.40 is the one we’ve been going on about for a while now: VarInfo and its internal data structures have been completely reworked. You mostly get better performance from this, but also a much richer representation of random variables and their values. I can’t do it justice here, please see the full changelog for details!

• Turing@0.43 essentially brings all of that together into your favourite probprog framework. On top of all of the above, the optimisation interface has also been completely rewritten; it’s now more high-level and the inputs and outputs will be easier to work with (see the new version’s docs for more info).

In recent versions of Turing one of the major focuses has been performance optimisations. I’m therefore very pleased to report now that running a couple of benchmarks on the eight-schools models, we find now that Turing + Mooncake/Enzyme has equivalent or better performance to Stan (code is here; do note that these aren’t very scientific!).

Moving forward, on top of core improvements to DynamicPPL we’re also keen to look into other ways to interact with Turing instead of just via the Julia REPL, such as a CLI, or possibly even tools for coding agents. We are quite limited by the number of people on the project (which is too low), but if you’d be interested in that or have an idea or use case do get in touch!

For GSoC 2026 we offer projects from core AD work to scalable inference and user-facing tools.

If a project interests you, contact the mentors listed below or open a discussion on the relevant GitHub repo. Please drop a short introduction message in the #turing channel on the Julia Slack and feel free to ping Shravan Goswami there. Mentors will be happy to discuss project details, scope, and expectations, and you can find mentor contacts at team page.

Also cross-posted on Julia’s GSoC page.

We have been working on a really complete overhaul of the internal VarInfo data structure (several thousand lines of code changes). Pretty much the entire thing has been rewritten from scratch. There are still a number of kinks to iron out, but CI is passing, so there is nothing really fundamental blocking it, just more test coverage and handling of edge cases, and checking that it doesn’t break anything in Turing.

What you’ll get out of it:

• More internally consistent indexing behaviour: if you have something like x ~ MvNormal(zeros(2), I) and you condition your model on Dict(@varname(x[1]) => 1.0, @varname(x[2]) => 2.0) it will now behave correctly (previously the conditioning would have no effect). Colons also benefit a lot from this. Essentially, if I’m not wrong, every item in the table in this issue will more or less become true.

• Generic AbstractArray support: you should be able to use OffsetArrays, DimArrays, etc. and have them ‘just work’ the way you expect them to. For example you should be able to do dimarr[X(1), Y(2)] ~ dist and it should behave just as if you wrote arr[1, 2] ~ dist.

• Much improved performance on many common operations (see this PR for some benchmarks).

• If you develop against DynamicPPL, all our VarInfo subtypes are unified now, there’s no longer a distinction between ‘typed’, ‘untyped’, or ‘simple’ VarInfo.

If you’re interested in a behind-the-scenes look at why and how we did this, there are some docs here (still in progress, but a lot of the basics are covered)! The performance aspects will mostly affect non-HMC/NUTS samplers (since Turing@0.42 / DynamicPPL@0.39, HMC and NUTS almost completely don’t use VarInfo anymore), although the correctness aspects will apply to every Turing model.

Turing v0.42

A new version of Turing was released yesterday — there is no way we can do justice to the changes in one paragraph so please check out the changelog for full details. Of note are:

• Threadsafe evaluation is now opt-in, if you have tilde-statements inside threaded blocks you must now write model = setthreadsafe(model, true). Confused? Don’t worry, there’s a new docs page that fully explains when and why you need this (and when you don’t)
• Changes in DynamicPPL should mean that lots of things are now faster, mostly HMC/NUTS, Prior, and returned / predict. (Personally we also really recommend trying FlexiChains if performance with chains is an issue and your model has lots of vector parameters; there are a growing number of issues on Turing/DynamicPPL where half of the solution is to use FlexiChains)
• MCMCChains now stores the log-joint as chn[:logjoint] rather than chn[:lp] — the latter was really a remnant carried over from the times when Turing didn’t track prior and likelihood separately
• The VI interface has been changed a fair bit but in return you now have access to a whole host of new VI algorithms including natural gradient VI, batch-and-match, and Wasserstein
• Implementing external samplers for Turing should now be much easier, you should only need to depend on AbstractMCMC and not Turing (see the external sampler docstring and docs page for examples)
• GibbsConditional is back after a long hiatus: the interface is slightly different to before, please see the docstring for usage examples!

Docs

Apart from the threadsafe evaluation page we also did a refresh of Bijectors.jl’s docs including a new page with some examples of how to define your own bijector. And on top of that, on the main TuringLang docs page there are also new shiny links that let you download each docs page as a notebook, or open it as a notebook in Google Colab. Look out for the links in the right sidebar of the page!

DoodleBUGS

Now has a refreshed and much slicker UI: check it out @ https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/

This PR makes Turing faster by about 2-10x depending on the size of the model. (Not kidding, see the PR for examples!) Smaller models benefit the most, larger models less so because for those a larger proportion of your time is spent just calculating logpdf.

The main impact is probably in inference. The PR contains an example where NUTS sampling on eight-schools is cut from ~ 8 seconds to ~ 1.5 seconds. The general strategy should lead to speedups for other operations as well such as returned and predict, although those will be less marked as reading from / constructing a chain will be the main bottlenecks.

It’s not released yet, but should hopefully be in the near future!

Mooncake @ 1.12

Just a note to say that there is now a newly released version of Mooncake that works on 1.12, and Turing should be perfectly compatible with it!

The big news item this week is that we’ve just released new (twinned) versions of Turing + DynamicPPL! Many of the changes are under the hood: you might see better performance on some functions like predict for example.

The main breaking change comes with the initial_params keyword argument: previously this was supplied as a vector (or vector of vectors for multiple chains). The problem with this is that the meaning of this vector depended on DynamicPPL internals, in a way that users shouldn’t be exposed to. Now, it should be an AbstractInitStrategy (or vector thereof). Essentially, instead of saying “what are the parameters are”, you now specify “how do I get parameters”. This will give you more ways to initialise parameters, and also clearer code.

Docs for the new version are already live! In the meantime, you can read more details in our release notes.

ProductNamedTupleDistribution

…can (mostly) be used in Turing now! You’ll need to upgrade to v0.41. I say mostly because there is a fairly niche edge case, where product_distribution of Array inside product_distribution of NamedTuple will fail. If you run into this, please feel free to open an issue!

Particle samplers in Julia 1.12

Particle samplers were broken by changes in Julia 1.12’s internals. Over the past few months several fixes have been introduced and you should be able to use these again now! You will need to make sure to upgrade Libtask.jl to 0.9.6, which was just released today.

With the release of 1.12 comes some very nice things and some broken things. Particle samplers (SMC and PG) currently do not work on 1.12, and Enzyme and Mooncake will both not run. Fixes are being worked on, but it may well take until 1.12.1 before everything is in order. If you use any of the above three, you may want to stay with 1.11 for now.

JuliaCon

We were at JuliaCon Paris last week (thanks to the organising team for a wonderful conference)! If you didn’t get the chance to say hi, feel free to take a look at the poster we did here on GitHub. It very briefly summarises what we’ve been up to in the last few months, what our current priorities are, and what’s likely to come in the future.

MCMCChains plots + stats

In the past few months there have been a number of new plot types added to MCMCChains. You can see examples of energy plots, violin plots, and posterior predictive plots in the docs. Also, you can now use MCMCDiagnosticTools.bfmi(::Chains) to calculate the Bayesian fraction of missing information.

Docs

There’s a new page explaining in more detail all the options you can use when sampling: https://turinglang.org/docs/usage/sampling-options/, suggestions for additions are always welcome!

JuliaCon Local Paris 2025

Markus and Penny will be in Paris next week for JuliaCon! We have a poster on Friday morning about all the latest developments in Turing.jl, so please feel free to come and say hi and chat about anything :)

Google Summer of Code projects

We have recently wrapped up our two GSoc projects and the reports are available to read. There is Mateus Maia’s work on RJuliaBUGS – as the name suggests this is an R interface to JuliaBUGS.jl; and also Shravan Goswami’s DoodleBUGS – a web frontend for creating and editing BUGS models (you can also try it out here!).

Core updates

Our refactoring of DynamicPPL internals continues: DynamicPPL v0.37 / Turing v0.40 was quite a major release (for us!) and in particular overhauls the way that log-probabilities are tracked when evaluating a model. For the regular Turing.jl user you will hopefully find quite little difference, but one bonus is that in MCMC sampling log-probabilities are now correctly tracked in the returned chain: you can access chn[:lp] for the log-joint, but also chn[:logprior] and chn[:loglikelihood]. All of these probabilities are also consistently returned in the “unlinked space”, i.e., they don’t include any Jacobian terms obtained from transforming constrained distributions (these terms are an implementation detail and shouldn’t be ‘leaked’ to the user). Previously only chn[:lp] was provided and the meaning of that varied from sampler to sampler.

Mooncake forward-mode

Mooncake.jl now has a new forwards-mode AD system which you can use with AutoMooncakeForward(). It should work with almost all Turing models and our ADTests website has benchmarks (reverse mode is still faster for most things!)

Docs

There are some new additions to the Turing docs including a list of FAQs, as well as a more thorough page on submodels and how to use one of Turing’s most unique features. If you have particular requests for documentation please do let us know as we’ll be attempting to spend some consistent time working on the docs.

TL;DR

• BUGS (Bayesian Inference Using Gibbs Sampling) is a probabilistic programming language for Bayesian models, and JuliaBUGS is its modern implementation in Julia. DoodleBUGS is a browser-based graphical interface for JuliaBUGS, allowing users to draw probabilistic graphical models and generate BUGS code.
• Implemented: visual editor (nodes, edges, nested plates), legacy BUGS code generation that compiles with JuliaBUGS [1], [2], local execution via a Julia backend, unified standalone script generation (frontend), timeouts, multiple layouts, and extensive cleanup/typing.
• Changed from proposal: frontend implemented in Vue 3 (instead of React); backend simplified (frontend is the single source of truth for standalone scripts).
• Status: Working application. Try it here (static UI): https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/. For local inference, run the backend server.

Directory Structure

DoodleBUGS/                # Vite + Vue 3 app (UI editor)
├── README.md              # project documentation
├── public/                # static assets served by Vite
│   └── examples/          # example projects
├── experiments/           # prototypes and exploratory work
├── runtime/               # Julia HTTP backend (API endpoints & dependencies)
├── src/                   # application source
│   ├── assets/            # styles and static assets
│   ├── components/        # Vue components composing the UI
│   │   ├── canvas/        # graph canvas and toolbars
│   │   ├── common/        # shared UI primitives
│   │   ├── layouts/       # app layout and modals
│   │   │   └── MainLayout.vue   # main application layout
│   │   ├── left-sidebar/  # palette, project manager, execution settings
│   │   ├── panels/        # code preview and data input panels
│   │   ├── right-sidebar/ # execution, JSON editor, node properties
│   │   └── ui/            # base UI elements (buttons, inputs, selects)
│   ├── composables/       # reusable logic (codegen, drag & drop, graph, validator, grid)
│   ├── config/            # configuration and node definitions
│   ├── stores/            # Pinia state stores (graph, data, execution, project, UI)
│   └── types/             # TypeScript types and ambient declarations
├── tmp/                   # local temporary outputs (ignored in builds)
└── ztest/                 # scratch/test artifacts

# from repo root
cd DoodleBUGS
npm install
npm run dev

# from repo root
julia --project=DoodleBUGS/runtime DoodleBUGS/runtime/server.jl
# server listens on http://localhost:8081

The new versions of Libtask and AdvancedPS have now been integrated into Turing.jl proper. You shouldn’t see any changes, except that particle MCMC methods will now run a lot faster!

(Do note that these won’t work on Julia 1.12 just yet as it is somewhat tightly coupled to Julia internals; we’re working on a fix but if you really want to use Turing on 1.12 right now you will have to stick to Turing ≤ 0.39.6.)

Progress bars

AbstractMCMC 5.7 is released with the new progress bars! By default you get a single progress bar (but with more frequent updates). You need to opt-in to per-chain progress bars with sample(...; progress=:perchain)

ADTests categories

The list of models has been split up into different sections to make it a bit easier to read. I’m keen to add more examples of integrations with other packages — if you have a Turing model that uses functionality from a different package inside it, please do get in touch with an example! (I’ll be adding things like DifferentialEquations, HiddenMarkovModels, and AbstractGPs soon, since those are already in our docs)

Community meetings

The Turing.jl developer team usually meet once every week; we’re thinking of opening some of these meetings to be public (perhaps once a month) and would like to gauge whether there’s any interest in this. Our current thinking is that these meetings would be something along the lines of:

• 3 guests with 1 topic each, 10 minutes each: these would be user-submitted and could really be anything you wanted to talk about, e.g. how to write a model, what samplers to use, … And basic stuff is totally fine as that means more people get to learn how to do Bayesian modelling :)
• 10 minutes from us on “where Turing is going”
• 20 minutes free Q&A

If you would be interested in attending such a meeting or bringing along a topic, do let us know on Slack!

Sampling LKJCholesky with HMC/NUTS has, until now, failed because of numerical instabilities (you’d usually get a DomainError somewhere). Bijectors.jl has gotten a couple of fixes (here and here, just released v0.15.8 today that contains both of these) that should fix this, hopefully once and for all! (There are still some issues with LKJ itself, see this PR. But now with LKJCholesky working there is less need for LKJ :))

Multiple-chain progress bars

Not released yet, but you might like to see this PR (and the videos therein!) which, if merged, will provide more detailed progress bars when sampling with MCMCThreads() or MCMCDistributed(). Currently, the default is that for 10 chains or fewer you’ll get one progress bar per chain; above that there’ll just be one overall progress bar, but it’ll update more than once per chain. That’s customisable, and if you think the default should be different feel free to drop a line!

We will have two GSoC students this year working with us: their projects are both focused on JuliaBUGS.jl, one on developing a graphical interface in a web browser, and another on an R interface. We (re?-)welcome Mateus and Shravan — if you see them around do say hi 🙂

TuringGLM.jl

We’ve been thinking about putting in some work on TuringGLM.jl, which allows one to create Turing models using formula syntax (similar to that in brms, lme4 or bambi). There are (as always) plenty of things for us to work through, but if you’ve used this and would like to let us know about what you’d like to see in it, feel free to message or open an issue on the repository!

• location-scale families with dense scale matrices,
• parameter-free stochastic optimization algorithms like DoG and DoWG,
• proximal operators for stable optimization,
• the sticking-the-landing control variate for faster convergence, and
• the score gradient estimator for non-differentiable targets.

There are some other small changes to do with imports and exports. The brief summary is: @addlogprob! is now formally exported. There are a bunch of other, unexported, things where you may need to change from Turing.foo to DynamicPPL.foo – although this probably only applies if you were using DynamicPPL internals. If you have any issues with these please feel free to get in touch.

Apart from this, we have also released AdvancedHMC.jl 0.8! Breaking changes include: - if you are relying the internal transition to make an MCMC transition from phase point z using trajectory τ (or HMCKernel κ) with Hamiltonian h, please note the signature has changed. The usage should now always be transition(h, τ, z) or transition(h, κ, z). - HMC sampling requires appropriate step size for the Leapfrog integration, as the chosen step size directly affects the numerical stability of the integration process. While AdvancedHMC.jl provides find_good_stepsize to find a suitable step size during HMC sampling, it didn’t support manual step size specification, which caused unnecessary searching. Now initial_step_size can be specified as a keyword in find_good_stepsize if you want more control of the step size selection process.

And finally, we have a few new examples of normalising flows in the NormalizingFlows.jl library: https://github.com/TuringLang/NormalizingFlows.jl/tree/main/example

There’s a new major version of MCMCChains.jl. From a user point of view, the main difference is that summary statistics and quantiles aren’t automatically calculated by default (so, printing a Chains object in a REPL will only show the parameter names and sizes). To get the summary statistics and quantiles you will have to run describe(chain). The main reason for this is because the summary stats would often take quite a while to compute — if you wish to preserve the old behaviour you can stick to MCMCChains@6.

JuliaBUGS @model

JuliaBUGS.jl recently implemented a @model macro which, in terms of its syntax, looks somewhat similar to Turing.jl’s own macro, but under the hood constructs a BUGS model. Perhaps of interest is the way that parameters are initialised using @parameters struct ... end; this currently helps to initialise all parameter values to placeholders, and offers an alternative to explicitly specifying this with NamedTuples or arrays. This hasn’t yet been released but for more information and a demonstration, there’s a documentation page that describes the design of this macro. The existing @bugs macro will still be retained.

Libtask

Libtask.jl, the library that Turing’s particle Gibbs sampler is built on, was recently rewritten for its core parts by Will Tebbutt (#179. Libtask implements copyable, resumable tasks (coroutines) in pure Julia, and the new version is much faster and better documented. The new implementation is based on source code transformations, using tools and techniques from Mooncake.jl. Work is ongoing to adapt AdvancedPS.jl to work with the new Libtask version, and once that is done we should expect a performance boost for Turing’s particle Gibbs sampler. We’ll let you know once that’s out.

@model function inner()
    x ~ Normal()
end
@model function outer()
    a ~ to_submodel(inner())
    b ~ to_submodel(inner())
end
sample(outer(), Gibbs(@varname(a.x) => MH(), @varname(b.x) => MH()), 100)

It is theoretically possible that this will be slow for VarNames that involve indexing (e.g. x[1]), although we don’t have an example of this yet. If you find anything you think should be faster, let us know.

One other minor point: on ADTests you can now hover over a model name to see its definition.

A new minor version of DynamicPPL brings with it a few changes especially to the behaviour of submodels. These have not yet percolated up to Turing.jl, but will soon be. Firstly, prefixing behaviour is changed: consider these models

@model function inner()
    x ~ Normal()
end
@model function outer()
    a = [0.0]
    a[1] ~ to_submodel(inner())
end

If you ran this model, you would find that the single random variable was called a[1].x — but this isn’t the x field of the 1st element of a, it’s actually a variable whose name is literally just Symbol("a[1].x"). DynamicPPL changes this behaviour such that the variable is correctly recognised as the x field of the 1st element of a. This means that if you are trying to, for example, condition on the variable, you can do:

outer() | (@varname(a[1].x) => 1.0)

On the topic of conditioning, you can now also correctly condition or fix variables in a model before using it as a submodel, as this example demonstrates:

@model function inner()
    x ~ Normal()
end
@model function outer()
    a ~ to_submodel(inner() | (@varname(x) => 1))
end

Previously, if you wanted to do this, you would have to condition on @varname(a.x), meaning that you’d need to know the prefix before conditioning it. The current system allows for more modular construction of nested models.

For more complete details, please see the release notes.

TuringBenchmarking.jl

DynamicPPL 0.36 also brings new functionality that can be used for testing and benchmarking automatic differentiation on Turing models. This is what powers the ADTests table, which we shared last time round. (Psst — there are more examples now than before!)

For more information, see the docstring of DynamicPPL.TestUtils.AD.run_ad in the DynamicPPL docs.

As a corollary of this, the AD benchmarking functionalities in TuringBenchmarking.jl are not really needed anymore. If you are using this package, we recommend that you switch over to use the functionality that’s directly built into DynamicPPL.

AdvancedHMC compatibility with ComponentArrays

AdvancedHMC had a fairly long-standing issue where it couldn’t always be used with ComponentArrays as the position / momentum. This has now been fixed; you can take a look at the test suite to see examples of how they can be used together.

Given that you’re reading this, we hope so! We’re currently putting together a list of papers and other outputs (e.g. tutorials, presentations, …) which make use of Turing.jl. We’d love to have more examples, if you have any, please do get in touch (feel free to message me and I can forward it). Thank you!

State of the AD

Over the last few weeks we’ve been putting together a little project that tabulates the performance of different AD backends on a variety of Turing.jl models, and we’re now quite excited to share it: https://turinglang.org/ADTests/ This will hopefully help to answer the perennial question of whether you should stick with good old ForwardDiff, or whether you should try something else. Do note that (as of the time of writing) this table is still in alpha stage and there are a lot of details that have yet to be ironed out :slightly_smiling_face: However, suggestions are always welcome!

JuliaBUGS.jl

The BUGS (Bayesian inference Using Gibbs Sampling) language provides a declarative way to specify complex Bayesian statistical models. For years, implementations like WinBUGS, OpenBUGS, and JAGS have been widely used tools for researchers applying these models. JuliaBUGS.jl is a modern implementation of the BUGS language, aiming for full backwards compatibility with standard BUGS models, while also offering improved interoperability with the Julia ecosystem. (For details and examples of BUGS syntax, check out the JuliaBUGS documentation.)

A recent experimental update introduces significant performance improvements in JuliaBUGS: instead of relying solely on the previous graph-based approach, JuliaBUGS can now directly generate Julia code to compute the model’s log-density. This code generation technique can yield >10x speedups compared to the graph-based method. Currently, this provides the most benefit for models with linear or hierarchical structures; support for state space models is planned for a future update.

To use it, run this after compiling your model:

JuliaBUGS.set_evaluation_mode(your_model, JuliaBUGS.UseGeneratedLogDensityFunction())

We would love for you to test out this new functionality! If you have any feedback, please do feel free to open a GitHub issue or discussion.

Even more advanced HMC

Lastly, we have a paper of our own to share on Hamiltonian Monte Carlo methods!

• Xu, K., & Ge, H. (2024). Practical Hamiltonian Monte Carlo on Riemannian Manifolds via Relativity Theory. Forty-First International Conference on Machine Learning. https://openreview.net/pdf?id=Et8Pk97u4u and https://icml.cc/virtual/2024/poster/34558

We will be looking to integrate these methods into Turing.jl in the future.

We’ve now released v0.37 of Turing. This includes a lot of new functionality from DynamicPPL 0.35, including the new (simplified) .~ . It also cleans up the list of exported identifiers, and most notably, if you were using things from DynamicPPL, you will now also need to import DynamicPPL (or using).

More generally, it’s likely that from now on our releases will involve larger changes because we are aggregating more changes into a single minor version. We are, however, also committed to providing thorough release notes that will help users and library authors upgrade more easily! Release notes will be available on GitHub, and you can see the notes for Turing 0.37 and DynamicPPL 0.35 here. If you have any trouble upgrading, just drop us a note.

AD backend testing

Right now we test a series of DynamicPPL models with several AD backends. It’s rather ad-hoc and we are currently drafting a more formal interface for testing AD backends with Turing models. It’s still early days but if you are an AD package developer and want to know what this means for integration with Turing, get in touch (easiest way: ping Penny on Slack) 🙂

Unified interface for optimisation algorithms

There’s an ongoing discussion about unifying the interface for MAP/MLE point estimates and variational inference (and potentially even MCMC). If you use more than one of these methods and have thoughts on what you’d like from an interface, we’d be very happy to hear from you!

DynamicPPL.jl now has a set of benchmarks that are run on GitHub Actions! We measure how long it takes to evaluate a small selection of models and also to run AD on them. If you think that there are specific models / features that we should add to the benchmarks, please feel free to create an issue and let us know.

Separately, we are planning to merge the benchmarking utilities in TuringBenchmarking.jl into DynamicPPL itself. There might be a little bit of API shake-up as part of this, but it’s for the better as it’ll allow the benchmarking code to more easily stay in sync with DynamicPPL — allowing us to catch performance regressions in PRs.

SSMProblems

The SSMProblems.jl and GeneralisedFilters.jl packages have now been merged into a single repository: https://github.com/TuringLang/SSMProblems.jl. This won’t affect you if you are using the packages from the Julia General registry, but if you’re looking to develop off the main branch you may have to use a different URL, or specify a subdirectory in Pkg.add.

Smaller bits

Other code changes that have been merged:

• Some old code in AdvancedHMC.jl has been cleaned up quite a bit. See the 0.7.0 release for more information.
• Turing’s Gibbs sampler now supports warmup steps properly. We’re still thinking about how to properly encode the scenario where different sub-samplers have different numbers of warmup steps, if you have any ideas, do get in touch on that PR.
• We are going to formally remove support for Zygote as an AD backend. We don’t test it thoroughly in Turing’s test suite. You can of course still use Zygote yourself, simply load ADTypes.AutoZygote() — although we can’t guarantee that we will fix any bugs that arise.