Enzyme.jl
swift
Enzyme.jl | swift | |
---|---|---|
10 | 215 | |
401 | 65,927 | |
2.7% | 0.4% | |
9.5 | 10.0 | |
about 3 hours ago | 6 days ago | |
Julia | C++ | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Enzyme.jl
-
Custom gradients in Enzyme
It's possible but at this time it's not recommended or documented as right now it requires writing some LLVM-level stuff and a better system is coming soon (see https://github.com/EnzymeAD/Enzyme.jl/pull/177)
-
“Why I still recommend Julia”
Can you point to a concrete example of one that someone would run into when using the differential equation solvers with the default and recommended Enzyme AD for vector-Jacobian products? I'd be happy to look into it, but there do not currently seem to be any correctness issues in the Enzyme issue tracker that are current (3 issues are open but they all seem to be fixed, other than https://github.com/EnzymeAD/Enzyme.jl/issues/278 which is actually an activity analysis bug in LLVM). So please be more specific. The issue with Enzyme right now seems to moreso be about finding functional forms that compile, and it throws compile-time errors in the event that it cannot fully analyze the program and if it has too much dynamic behavior (example: https://github.com/EnzymeAD/Enzyme.jl/issues/368).
Additional note, we recently did a overhaul of SciMLSensitivity (https://sensitivity.sciml.ai/dev/) and setup a system which amounts to 15 hours of direct unit tests doing a combinatoric check of arguments with 4 hours of downstream testing (https://github.com/SciML/SciMLSensitivity.jl/actions/runs/25...). What that identified is that any remaining issues that can arise are due to the implicit parameters mechanism in Zygote (Zygote.params). To counteract this upstream issue, we (a) try to default to never default to Zygote VJPs whenever we can avoid it (hence defaulting to Enzyme and ReverseDiff first as previously mentioned), and (b) put in a mechanism for early error throwing if Zygote hits any not implemented derivative case with an explicit error message (https://github.com/SciML/SciMLSensitivity.jl/blob/v7.0.1/src...). We have alerted the devs of the machine learning libraries, and from this there has been a lot of movement. In particular, a globals-free machine learning library, Lux.jl, was created with fully explicit parameters https://lux.csail.mit.edu/dev/, and thus by design it cannot have this issue. In addition, the Flux.jl library itself is looking to do a redesign that eliminates implicit parameters (https://github.com/FluxML/Flux.jl/issues/1986). Which design will be the one in the end, that's uncertain right now, but it's clear that no matter what the future designs of the deep learning libraries will fully cut out that part of Zygote.jl. And additionally, the other AD libraries (Enzyme and Diffractor for example) do not have this "feature", so it's an issue that can only arise from a specific (not recommended) way of using Zygote (which now throws explicit error messages early and often if used anywhere near SciML because I don't tolerate it).
So from this, SciML should be rather safe and if not, please share some details and I'd be happy to dig in.
-
The Julia language has a number of correctness flaws
Lots of things are being rewritten. Remember we just released a new neural network library the other day, SimpleChains.jl, and showed that it gave about a 10x speed improvement on modern CPUs with multithreading enabled vs Jax Equinox (and 22x when AVX-512 is enabled) for smaller neural network and matrix-vector types of cases (https://julialang.org/blog/2022/04/simple-chains/). Then there's Lux.jl fixing some major issues of Flux.jl (https://github.com/avik-pal/Lux.jl). Pretty much everything is switching to Enzyme which improves performance quite a bit over Zygote and allows for full mutation support (https://github.com/EnzymeAD/Enzyme.jl). So an entire machine learning stack is already seeing parts release.
Right now we're in a bit of an uncomfortable spot where we have to use Zygote for a few things and then Enzyme for everything else, but the custom rules system is rather close and that's the piece that's needed to make the full transition.
-
Engineering Trade-Offs in Automatic Differentiation: from TensorFlow and PyTorch to Jax and Julia
enzyme.jl is probably the quickest way to play with enzyme: https://github.com/wsmoses/Enzyme.jl
-
Useful Algorithms That Are Not Optimized by Jax, PyTorch, or TensorFlow
"Maybe they let you declare some subgraph as 'dynamic' to avoid static optimizations?" What you just described is Tensorflow Eager and why it has some performance issues. XLA makes some pretty strong assumptions and I don't that should change. Tensorflow's ability to automatically generate good parallelized production code stems from the restrictions it has imposed. So I wouldn't even try for a "one true AD to rule them all" since making things more flexible will reduce the amount of compiler optimizations that can be automatically performed.
To get the more flexible form, you really would want to do it in a way that uses a full programming language's IR as its target. I think trying to use a fully dynamic programming language IR directly (Python, R, etc.) directly would be pretty insane because it would be hard to enforce rules and get performance. So some language that has a front end over an optimizing compiler (LLVM) would probably make the most sense. Zygote and Diffractor uses Julia's IR, but there are other ways to do this as well. Enzyme (https://github.com/wsmoses/Enzyme.jl) uses the LLVM IR directly for doing source-to-source translations. Using some dialect of LLVM (provided by MLIR) might be an interesting place to write a more ML-focused flexible AD system. Swift for Tensorflow used the Swift IR. This mindset starts to show why those tools were chosen.
-
Julia Computing Raises $24M Series A
Have you explored the SciML landscape at all (?):
https://sciml.ai/
There are a number of components here which enable (what I would call) the expression of more advanced models using Julia's nice compositional properties.
Flux.jl is of course what most people would think of here (one of Julia's deep learning frameworks). But the reality behind Flux.jl is that it is just Julia code -- nothing too fancy.
There's ongoing work for AD in several directions -- including a Julia interface to Enzyme: https://github.com/wsmoses/Enzyme.jl
Also, a new AD system which Keno (who you'll see comment below or above) has been working on -- see Diffractor.jl on the JuliaCon schedule (for example).
Long story short -- there's quite a lot of work going on.
It may not seem like there is a "unified" package -- but that's because packages compose so well together in Julia, there's really no need for that.
-
Swift for TensorFlow Shuts Down
The name of the LLVM AD tool is actually Enzyme [http://enzyme.mit.edu/] (Zygote is a Julia tool)
- Enzyme – High-performance automatic differentiation of LLVM (r/MachineLearning)
-
Enzyme – High-performance automatic differentiation of LLVM
Also see the Julia package that makes it acessible with a high level interface and probably one of the easier ways to play with it: https://github.com/wsmoses/Enzyme.jl.
swift
-
Evolving the Go Standard Library with math/rand/v2
This algorithm produces biased result with probability 1/2^(32-bitwidth(N)). Using 64 or 128 random bits can make the bias practically undetectable. Comprehensive overview of the approach can be found here: https://github.com/apple/swift/pull/39143
- Swift: Differentiable Programming Manifesto
-
Embedded Swift on the Raspberry Pi Pico
Because of C/C++ interop, and integration with CMake, you can just add Swift to a Zephyr project and it pretty much Just Works. [The docs](https://github.com/apple/swift/blob/main/docs/EmbeddedSwift/...) should mostly apply to the Zephyr SDK as well.
-
A Deep Dive Into Observation: A New Way to Boost SwiftUI Performance
Fortunately, the Observation framework is part of the Swift 5.9 standard library. We can learn more information by examining its source code.
-
Swift was always going to be part of the OS
They do! See https://github.com/apple/swift/blob/main/docs/LibraryEvoluti...
You can also see an example of what a different high level language integration with Swift ABI looks like here: https://github.com/dotnet/designs/blob/main/proposed/swift-i...
-
Differentiable Swift
So is differentiable Swift a package for Swift or is it part of the Swift standard library? The video says go to swift.org but I can't find any info about differentiable Swift on that site.
-
Beyond Backpropagation - Higher Order, Forward and Reverse-mode Automatic Differentiation for Tensorken
Swift's Differentiable Programming Manifesto. Swift has a powerful differentiable programming component, integrated with the compiler.
-
Kotlin Multiplatform for Android and iOS Apps
You can do the same thing the other way around - https://github.com/apple/swift/blob/main/docs/Android.md.
-
This isn’t the way to speed up Rust compile times
Codable (along with other derived conformances like Equatable, Hashable, and RawRepresentable) is indeed built in to the compiler[0], but unlike Serde, it operates during type-checking on a fully-constructed AST (with access to type information), manipulating the AST to insert code. Because it operates at a later stage of compilation and at a much higher level (with access to type information), the work necessary is significantly less.
With ongoing work for Swift macros, it may eventually be possible to rip this code out of the compiler and rewrite it as a macro, though it would need to be a semantic macro[1] rather a syntactic one, which isn't currently possible in Swift[2].
[0] https://github.com/apple/swift/blob/main/lib/Sema/DerivedCon...
-
How does Swift implement primitive types in its standard library?
`Int` is a regular struct with a single stored property of type `Builtin.Word` . But the latter is a magical compiler built-in. Source for integer types is generated from this template - https://github.com/apple/swift/blob/9da65ca0a15fdf341649c994b0a77ec3b71f2687/stdlib/public/core/IntegerTypes.swift.gyb
What are some alternatives?
ChainRules.jl - forward and reverse mode automatic differentiation primitives for Julia Base + StdLibs
solidity - Solidity, the Smart Contract Programming Language
ForwardDiff.jl - Forward Mode Automatic Differentiation for Julia
cpp-lazy - C++11/14/17/20 library for lazy evaluation
MLJ.jl - A Julia machine learning framework
Elixir - Elixir is a dynamic, functional language for building scalable and maintainable applications
swift - Swift for TensorFlow
tree-sitter - An incremental parsing system for programming tools
Lux.jl - Explicitly Parameterized Neural Networks in Julia
hummingbird - Hummingbird compiles trained ML models into tensor computation for faster inference.
NBodySimulator.jl - A differentiable simulator for scientific machine learning (SciML) with N-body problems, including astrophysical and molecular dynamics
lobster - The Lobster Programming Language