dfdx

Library Listed Dormant

Ergonomic auto differentiation in Rust, with pytorch like apis.

Checked ยท Sources

Downloads
2,369
Dependents
4
Stars
1,944
Forks
109
Contributors
38
Commits
890
Latest release
0.13.0 ยท

About

From the project README ยท

dfdx: shape checked deep learning in rust

Ergonomics & safety focused deep learning in Rust.

Still in pre-alpha state. The next few releases are planned to be breaking releases.

Features at a glance:

  1. :fire: GPU accelerated tensor library with shapes up to 6d!
  2. Shapes with both compile and runtime sized dimensions. (e.g. Tensor<(usize, Const<10>)> and Tensor<Rank2<5, 10>>)
  3. A large library of tensor operations (including matmul, conv2d, and much more).
    1. All tensor operations shape and type checked at compile time!!
  4. Ergonomic neural network building blocks (like Linear, Conv2D, and Transformer).
  5. Standard deep learning optimizers such as Sgd, Adam, AdamW, RMSprop, and more.

dfdx is on crates.io! Use by adding this to your Cargo.toml:

dfdx = "0.13.0"

See the documentation at docs.rs/dfdx.

[1] https://en.wikipedia.org/wiki/Automatic_differentiation#Reverse_accumulation

Design Goals

  1. Ergonomics the whole way down (both frontend interface & internals).
  2. Check as much at compile time as possible (i.e. don't compile if something is not correct).
  3. Maximize performance.
  4. Minimize unsafe code[1]
  5. Minimize Rc<RefCell> used in internal code[2]

[1] Currently the only unsafe calls are for matrix multiplication.

Read the full README

[2] The only things that use Arc are tensors to store their data. Arc is used instead of Box to reduce allocations when tensors are cloned.

GPU acceleration with CUDA

Enable the cuda feature to start using the Cuda device! Requires the installation of nvidia's cuda toolkit. See feature flags docs for more info.

API Preview

Check examples/ for more details.

  1. ๐Ÿ‘Œ Simple Neural Networks API, completely shape checked at compile time.
type Mlp = (
    (Linear<10, 32>, ReLU),
    (Linear<32, 32>, ReLU),
    (Linear<32, 2>, Tanh),
);

fn main() {
    let dev: Cuda = Default::default(); // or `Cpu`
    let mlp = dev.build_module::<Mlp, f32>();
    let x: Tensor<Rank1<10>, f32, Cpu> = dev.zeros();
    let y: Tensor<Rank1<2>, f32, Cpu> = mlp.forward(x);
    mlp.save("checkpoint.npz")?;
}
  1. ๐Ÿ“ˆ Ergonomic Optimizer API
type Model = ...
let mut model = dev.build_module::<Model, f32>();
let mut grads = model.alloc_grads();
let mut sgd = Sgd::new(&model, SgdConfig {
    lr: 1e-2,
    momentum: Some(Momentum::Nesterov(0.9))
});

let loss = ...
grads = loss.backward();

sgd.update(&mut model, &grads);
  1. ๐Ÿ’ก Const tensors can be converted to and from normal rust arrays
let t0: Tensor<Rank0, f32, _> = dev.tensor(0.0);
assert_eq!(t0.array(), &0.0);

let t1 /*: Tensor<Rank1<3>, f32, _>*/ = dev.tensor([1.0, 2.0, 3.0]);
assert_eq!(t1.array(), [1.0, 2.0, 3.0]);

let t2: Tensor<Rank2<2, 3>, f32, _> = dev.sample_normal();
assert_ne!(t2.array(), [[0.0; 3]; 2]);

Fun/notable implementation details

Module
pub trait Module<Input> {
    type Output;
    fn forward(&self, input: Input) -> Self::Output;
}

From this flexible trait we get:

  1. Single & batched inputs (just have multiple impls!)
  2. Multiple inputs/outputs (multi-headed modules, or rnns)
  3. Behavior different when tape is present or not (not the .train()/.eval() behavior present in other libraries!).
Tuples represent feedforward (a.k.a sequential) modules

Since we can implement traits for tuples, which is not possible in other languages AFAIK, they provide a very nice frontend for sequentially executing modules.

// no idea why you would do this, but you could!
type Model = (ReLU, Sigmoid, Tanh);
let model = dev.build_module::<Model, f32>();
type Model = (Linear<10, 5>, Tanh)
let model = dev.build_module::<Model, f32>();

How implementing Module for a 2-tuple looks:

impl<Input, A, B> Module<Input> for (A, B)
where
    Input: Tensor,
    A: Module<Input>,        // A is a module that takes Input
    B: Module<A::Output>,    // B is a module that takes A's Output
{
    type Output = B::Output; // the output of this is B's Output
    fn forward(&self, x: Input) -> Self::Output {
        let x = self.0.forward(x);
        let x = self.1.forward(x);
        x
    }
}

Modules implemented for Tuples up to 6 elements, but you can arbitrarily nest them!

No Rc<RefCells<T>> used - Gradient tape is not kept behind a cell!

Other implementations may store a reference to the gradient tape directly on tensors, which requires mutating tensors or using Rc/Refcells all over the place.

We've figured out an elegant way to avoid this, reducing references and dynamic borrow checks to 0!

Since all operations result in exactly 1 child, we can always move the gradient tape to the child of the last operation. Additionally, no model parameters (all tensors) will ever own the gradient tape because they will never be the result of any operation. This means we know exactly which tensor owns the gradient tape, and the tensors that have it will always be intermediate results that don't need to be maintained across gradient computation.

All of this together gives users unprecedented control/precision over what tensors are recorded on the gradient tape!

One advanced use case requires that tensors be re-used multiple times in a computation graph. This can be handled by cloning the tensor, and manually moving the gradient tape around.

Type checked backward

tl;dr: If you forget to include a call to trace() or traced(), the program won't compile!

-let pred = module.forward(x);
+let pred = module.forward(x.traced(grads));
let loss = (y - pred).square().mean();
let gradients = loss.backward();

Since we know exactly what tensors own the gradient tape, we can require the tensor passed into .backward() to own the gradient tape! And further, we can require it be moved into .backward(), so it can destruct the tape and construct the gradients!

All of this can be checked at compile time ๐ŸŽ‰

๐Ÿ“„ Validated against pytorch

All functions & operations are tested against behavior shown by similar code in pytorch.

License

Dual-licensed to be compatible with the Rust project.

Licensed under the Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0 or the MIT license http://opensource.org/licenses/MIT, at your option. This file may not be copied, modified, or distributed except according to those terms.

Runs on
CUDA
What shows it
  • CUDA: dfdx feature cuda (dependency cudarc)
Native code
None found
  • No native code found
Python bindings
No Python binding crate found
License
Apache-2.0 OR MIT

Compare with similar projects

Order: strongest tier first, then most downloads, then name, with unmeasured values last. A library counts downloads over 30 days. An app counts binary downloads per release. An app with none counts its crate downloads over 30 days. ML Rust runs this catalogue, so its closest project always gets a row.

dfdx beside the projects that share a topic with it
ProjectDownloadsDependentsStarsLatest releaseRuns on (GPU)Native codeLicense
dfdx This page Listed Dormant

Ergonomic auto differentiation in Rust, with pytorch like apis.

2,369 downloads over 30 days 4 1,944 0.13.0 CUDA No native code found Apache-2.0 OR MIT
tch-rs Featured

Rust wrappers for the PyTorch C++ api (libtorch).

Python bindings

Also in Train models.

1,190,464 downloads over 30 days 124 5,518 0.26.0 CUDA Binds native code: tch, torch-sys. Build uses a native toolchain: cc Apache-2.0 OR MIT
burn Featured

Flexible and Comprehensive Deep Learning Framework in Rust

Also in Tensors and GPU compute.

521,465 downloads over 30 days 391 16,257 0.22.1 CUDA, WebGPU, Metal, ROCm, Vulkan Binds native code: netlink-sys (feature iroh), nvml-wrapper-sys (feature sys-metrics), torch-sys (feature tch) Apache-2.0 OR MIT
boostr Listed

ML framework on numr for training and inference on CPU, CUDA and WebGPU: attention, quantization, inference scheduling and distributed execution. Models include LLaMA, Mamba2, Qwen3.5, Whisper, Kokoro, VITS, VoxCPM2, Silero VAD, CLAP and super-resolution. Loads SafeTensors and GGUF.

Also in Tensors and GPU compute.

1,265 downloads over 30 days 7 20 0.11.2 CUDA, WebGPU Binds native code: ring (feature distributed) Apache-2.0

Tensors and differentiable operations in Rust

Also in Tensors and GPU compute.

121 downloads over 30 days 0 504 1.1.1 GPU support unknown Binds native code: intel-mkl-src (feature mkl) MIT
RustTensor App Listed Dormant

A learning-focused, high-performance tensor computation library built from scratch in Rust, featuring automatic differentiation and CPU/CUDA backends.

Also in Tensors and GPU compute.

Not measured Not applicable 79 Not measured Not measured Not measured MIT
torchrs App Listed Dormant

Deep Learning in Rust with the PyTorch API

Also in Train models.

Not measured Not applicable 77 Not measured Not measured Not measured BSD-2-Clause
Why ListedNo archive, New or Featured rule places it, so it is Listed.

What it lacks for Featured

  • It has 1 active dependents and 1 new dependents in 365 days. Featured needs 11 active dependents or 9 new dependents in 365 days. The repository route reads 1,944 stars, 109 forks and 38 contributors. It needs 4,539 stars, 434 forks and 79 contributors together.
  • The project is dormant and not finished. Dormancy rule

What else the check found

  • The last activity is on 25 Jan 2024, 1019 days ago. That reaches the 365 days the rules expect, so the project is dormant. Dormancy rule
  • The oldest outside issue waits 1172 days for a reply, past the limit of 270. No maintainer replied in 365 days. Rot signals rule

Not measured: Latest release fails cargo check.

Exact rules: Listed, Featured library. The check on applied thresholds version 9.

Every rule outcome, as the check records it
  • expected-interval: version 0.13.0 base 140, raised to the 365-day floor: E = 365 days
  • dormancy: last activity 2024-01-25, 1019 days ago, E = 365: dormant
  • rot: oldest unanswered issue 1172 days (limit 270), no maintainer reply in 365 days
  • featured: not featured: active_users 1 < 11 and new_adopters 1 < 9 and repository route stars 1944 (needs 4539), forks 109 (needs 434), contributors 38 (needs 79); dormant and not stable
  • listed: listed: no archive, new or featured rule applies

Measurements and sources

Each signal row shows the raw value, its source and the fetch date. The Sources list gathers every distinct source on this page. Movement needs more history.

Sources6 sources
Adoption1 active dependents, 1 new dependents in 365 days1 not measured
Adoption measurements
SignalValueSourceFetchedCounts
Active dependents1crates.io database dumpYes
New dependents (365 days)1crates.io database dumpYes
Peak active dependents2crates.io database dumpYes
Active dependents as a share of the peak1crates.io database dumpYes
Binary downloads per releaseNot measuredYes
MaintenanceLatest human commit: 2 years ago3 not measured
Maintenance measurements
SignalValueSourceFetchedCounts
Latest human commit2024-01-25GitHub repositoryYes
Latest release2023-07-27crates.io database dumpYes
First release2022-05-09crates.io database dumpYes
Latest version0.13.0crates.io database dumpYes
Days the oldest outside issue waits for a reply1172GitHub repositoryYes
Maintainer replies over 365 days0GitHub repositoryYes
Repository archivedfalseGitHub repositoryYes
Repository gonefalseGitHub repositoryYes
Release commit or manifest in the repotruecrates.io packageYes
Published docstruecrates.io database dumpYes
Latest release fails cargo checkNot measuredYes
Build check dateNot measuredYes
Build check toolchainNot measuredYes
SecurityUnpatched vulnerabilities: none
Security measurements
SignalValueSourceFetchedCounts
Unpatched vulnerabilities past the grace windownoneRustSec advisory databaseYes
RustSec unmaintained advisorynoneRustSec advisory databaseYes
Deprecation noticenonecrates.io database dumpYes
Deprecated requirementnonecrates.io database dumpYes
Distribution17 releases, 2,369 downloads over 30 days5 not measured
Distribution measurements
SignalValueSourceFetchedCounts
Releases17crates.io database dumpYes
Downloads over 30 days2369crates.io database dumpYes
Binary downloads over the last 3 releasesNot measuredYes
Homebrew installs on request over 365 daysNot measuredYes
Repology repository familiesNot measuredYes
Docker pull growth over 90 daysNot measuredYes
Docker pulls at the growth baselineNot measuredYes
Every version a prereleasefalsecrates.io database dumpYes
Every version 0.0.xfalsecrates.io database dumpYes
Every version yankedfalsecrates.io database dumpYes
Crate deleted from crates.iofalsecrates.io database dumpYes
Repository1,944 stars, 109 forks, 38 contributors, 890 commits. Stars alone never qualify a project.
Repository measurements
SignalValueSourceFetchedCounts
GitHub stars1944GitHub repositoryYes โ€” one part of the repository route
GitHub forks109GitHub repositoryYes โ€” one part of the repository route
Contributors with a GitHub account38GitHub contributorsYes โ€” one part of the repository route
Commits on the default branch890GitHub repositoryNo
Repository's main crate left out of the entrynonecrates.io database dumpYes
Facts that never count
Facts that never count measurements
SignalValueSourceFetchedCounts
LicenseApache-2.0 OR MITcrates.io database dumpNo
Runs on, from listed crates and their direct dependenciesCUDAcrates.io database dumpNo
What shows each backendCUDA: dfdx feature cuda (dependency cudarc)crates.io database dumpNo
Native code, from listed crates and their dependenciesNo native code foundcrates.io database dumpNo
Python bindings, from direct dependencies of listed cratesNo Python binding crate foundcrates.io database dumpNo
Crates that depend on a listed crate directly4crates.io database dumpNo

Corrections and review history

Report a correction

No correction applies to this entry.

Judgments

A judgment enters only through an approved issue and a merged pull request.

No judgment applies to this entry.