18 Implementations.
One Benchmark.

NAG dco/c++ is a tape-based AAD library similar to Adept in its approach. Based on our benchmarks, NAG dco/c++ performance should be comparable to Adept results (approximately 6-100× slower than AADC). While NAG focuses on operator overloading with tape recording, AADC uses Code Generation AAD with JIT compilation to binary kernels, which is fundamentally faster.

Tape-based AAD (CppAD, Adept, NAG dco/c++, CoDiPack) records operations to a "tape" during the forward pass, then replays the tape in reverse for derivatives. AADC uses Code Generation AAD which JIT compiles the computational graph into optimized binary kernels with AVX2/AVX512 vectorization. This eliminates tape overhead and achieves adjoint factor less than 1.

Enzyme-AD faces significant challenges for production quant codebases: (1) Requires LLVM/Clang toolchain — Most production quant libraries use MSVC (Windows) or specific GCC versions with proprietary extensions, and switching compilers is often not an option. (2) Source-to-source transformation — Must recompile the entire codebase through LLVM, doesn't work with precompiled third-party libraries (Bloomberg, Reuters, proprietary risk engines). (3) Limited C++ feature support — Struggles with virtual functions, exceptions, RTTI, and complex template metaprogramming common in quant code. (4) Build system overhaul — Requires CMake/LLVM plugin integration across the entire build pipeline. (5) Debugging nightmare — Transformed LLVM IR is nearly impossible to debug when things go wrong.

Tape-based libraries face major integration challenges for >1M LOC codebases: (1) Type replacement throughout codebase — Must change every double to codi::RealReverse, CppAD::AD<double>, adept::adouble, etc. In 1M+ LOC, this means touching thousands of files. (2) Cannot differentiate external dependencies — Closed-source libraries (market data feeds, legacy pricing engines) cannot be instrumented. (3) Compilation time explosion — Template-heavy implementations cause compile times to grow from minutes to hours on large codebases. (4) Memory scaling issues — Tape storage grows linearly with computation graph size, and production Monte Carlo runs can exhaust memory. (5) Thread safety concerns — Most tape-based libraries require careful tape management for multi-threaded code.

XAD faces similar challenges: (1) Same type-replacement problem — Requires changing numeric types throughout the codebase. (2) Commercial licensing — Additional procurement/legal overhead for enterprise deployment. (3) Integration effort — Estimated 6-12 months for large codebase integration.

ML frameworks are unsuitable for C++ quant libraries: (1) Python-only — Cannot integrate with existing C++ codebases without complete rewrites or complex binding layers. (2) 12-18 second compilation overhead — JIT compilation makes them impractical for dynamic trade structures where parameters change frequently. (3) Framework lock-in — Must rewrite models in framework-specific syntax (jax.numpy, torch tensors). (4) Not designed for quant workflows — Optimized for ML training, not derivatives pricing with frequent recompilation.

Autograd is not viable for production: (1) Pure Python — Orders of magnitude slower than C++ implementations. (2) No C++ integration — Cannot be used with existing quant libraries. (3) Research tool only — Designed for prototyping, not production scale. (4) Unmaintained — No active development since 2022.

AADC avoids these problems through kernel recording: (1) No type changes required — Works with existing double types via idouble. (2) Compiler agnostic — Works with GCC, Clang, and MSVC. (3) Handles external dependencies — Records at runtime, doesn't need source access to third-party libraries. (4) Minimal code changes — Less than 1% of codebase needs modification. (5) Production-proven — Designed specifically for large-scale quant systems with 1M+ LOC, deployed at Tier-1 banks.

The benchmark computes Delta, Rho, and Vega for Asian options using Monte Carlo simulation. All implementations compute identical Greeks values to machine precision, ensuring fair comparison.

AADC Python achieves Greeks computation 2.1× faster than hand-optimized C++ code. This is because AADC generates optimized binary kernels that leverage AVX512 vectorization and multi-threading, while also computing derivatives automatically.

Adjoint factor measures the cost of computing derivatives relative to the function value. Traditional AAD has factors of 2-5×. AADC achieves adjoint factor less than 1, meaning price plus ALL Greeks costs less than price alone with original code.

For production quant finance with large codebases: AADC is the only viable option - it provides best performance with minimal code changes and works with existing compilers and external dependencies. For small open-source projects: Enzyme-AD is fastest open-source option (9× slower than AADC) but requires LLVM toolchain. For tape-based: CoDiPack is best (10-15× slower than AADC) but requires type changes throughout codebase. Avoid autodiff (700× slower) and unmaintained tools like Autograd.

Benchmarks run on Intel Xeon processors with AVX512 support, 8 threads. Multi-threaded implementations (AADC, Enzyme-AD, Optimised C++) scale linearly. Single-threaded implementations (JAX, PyTorch, NumPy, Autograd) don't benefit from additional cores due to Python GIL.

Yes, the benchmark code is available. Contact MatLogica for access to reproduce results on your infrastructure. The interactive benchmark allows configuring trades (10-1000) and scenarios (10K-500K) to match your use case.

AADC integration typically takes 2-4 weeks for initial POC results on large codebases (1M+ LOC). Full production deployment at a Tier-2 bank was achieved in 9 months with 70% code elimination. Compare this to 6-12+ months estimated for tape-based libraries that require type replacement throughout the entire codebase.