AADC extracts a computational graph from your existing analytics at run time and compiles it to machine code. It is not a source code compiler. It captures operations through operator overloading and emits a vectorised binary for x86-64 or ARM, with none of the interpreter overhead, object-oriented abstraction or memory traffic of the original.
How AADC transforms code into optimised kernels
Code Generation AAD™ uses operator overloading to trace the exact sequence of operations performed by your object-oriented code (C++, C#, or Python) at runtime, extracting a computational graph (DAG). This DAG is then compiled to optimised machine code kernels. AADC is not a source code compiler. It keeps your coding style and abstractions and removes their run-time cost, giving native performance on standard CPUs for a small change: double becomes idouble in the hot sections.
The generated kernels are reusable for repeated executions (e.g., thousands or millions of simulation paths, scenarios, or model calibrations), achieving 6–1000× speedups for both forward evaluations and first- or higher-order derivatives.
Designed for cross-platform execution, Code Generation AAD™ works across scientific simulations (PDEs, geophysics), quantitative finance, machine learning workflows (time series, recurrent networks), and other domains requiring repetitive high-performance computation.
Kernel creation time matters, because it is part of the overall run. Using off-the-shelf compilers (e.g., LLVM or C++) can take time equivalent to over 10,000 executions of the original code, making it prohibitive for smaller or dynamic simulations. This renders traditional code generation sufficient for testing but impractical for production, where minimising compilation overhead is essential.
High-performance computing usually forces a choice: write in a productive object-oriented language (Python, C++, C#) and accept the run-time overhead, or drop to hand-tuned low-level code and give up readability and speed of development.
Compilation is quick enough that the gain shows up in production, not only in a benchmark.
Nothing to install on the box that runs it, and no dependence on a slower off-the-shelf toolchain.
How AADC transforms your code into optimised kernels
Regular program execution with I/O, setup, and data loading
Load data, read configuration, initialise objects
File reading, network calls, database queries
Any operations outside the hot computational section
Timing: Use native double (no overhead) or idouble (~2% overhead) for zero-cost transition to Phase 1
Capture hot section and generate optimised machine code
Replace double with idouble. Outside of recording, idouble has ~2% overhead vs native double.
Sequence of elementary operations automatically captured into DAG
Forward and adjoint passes generated in parallel; adjoint machine code generated backwards
Constant folding, dead code elimination, optimal register allocation
Timing: Recording/compilation adds overhead compared to a single execution. One-time cost amortized over kernel executions.
Multi-threaded execution even if original code isn't thread-safe
Run kernels across multiple threads even if original code isn't thread-safe
Single kernel execution returns value and all first-order sensitivities
Bump-and-revalue (finite difference) of first-order derivatives provides best results
Kernels are serialisable - deploy to cloud for elastic compute without exposing source code
Performance: 6-1000x faster than original code, with adjoint factor <1
Reuse kernels for real-time and remote computation services
Save compiled kernels to disk for later reuse without recompilation
Kernels are compatible between Windows and Linux
Deploy kernels for always-on computation and real-time processing
Distribute kernels to remote compute nodes without exposing source code
Timing: Optional phase for production deployment scenarios
Every calculation benefits from the compilation, not only the derivatives
AVX2 or AVX-512 handles 4 or 8 doubles per instruction. What would take hand-written intrinsics happens from the recording.
Multi-threaded execution even if original code isn't thread-safe. Scales linearly with cores.
Optimal memory layout for modern CPU architecture. Data arranged for maximum cache efficiency and minimal bandwidth.
Better instruction cache usage through optimised code generation. Eliminates object-oriented overhead like virtual functions.
Python code compiled to native machine code, bypassing the interpreter entirely. Makes Python production-ready.
No virtual functions, no pointer chasing, no abstraction layers. Direct machine code for maximum performance.
What is different about AADC
AADC achieves the remarkable result where computing value AND all first-order sensitivities is faster than original code computing just the value.
Traditional AAD has adjoint factor 2-5x. AADC achieves <1x relative to original code.
20-50x speedup when running multiple scenarios through the same kernel.
While AAD fundamentally reduces sensitivity computation from O(n) bumps to O(1) adjoint pass, AADC's JIT compilation, vectorisation, and multi-threading optimisations make the combined value+sensitivities calculation faster than the original interpreted value-only calculation.
AADC delivers speedups ranging from 6× to over 1000× depending on your specific situation. The actual performance gain depends on several factors:
High-level implementations see the largest gains; already low-level optimised code sees smaller but still significant improvements
Python code typically sees larger speedups than C++ due to interpreter overhead elimination
Code without vectorisation or multithreading benefits more from AADC's automatic optimisations
Complex models with many operations benefit from kernel compilation and memory optimisation
Scenarios run many times (Monte Carlo, batch evaluation) amortize recording overhead for maximum gains
More sensitivities = larger advantage from AAD's O(1) adjoint pass vs O(n) bump-and-recompute
Contact us for a benchmark with your specific code to understand your expected performance improvement.
Complete API reference, integration guides, and code examples
Code Generation AAD™: from first publication to industry recognition
"AAD: Breaking the Primal Barrier" published in Wilmott Magazine by Goloubentsev & Lakshtanov. First description of record-once replay-many, JIT-compiled adjoint kernels, and adjoint factor <1.
"Remarks on Stochastic AAD and Financial Models Calibration" published on arXiv, extending Code Generation AAD to calibration problems.
"A New Approach to Parallel Computing Using AD" published in Intel Parallel Universe Magazine.
"Automatic IFT" published in Risk.NET, #1 most-read for over a quarter.
10th in the Chartis QuantTech50 with four category awards. Accenture FinTech Innovation Lab graduate.
Asia Risk Technology Awards: Technology Newcomer of the Year. Chartis Quantitative Analytics 50: 13th, Category Leader in Adjoint Algorithmic Differentiation.
Intel publishes developer article on AADC's record-once replay-many paradigm for Python and C++ analytics.
Chartis Quantitative Analytics 50: 13th, five category awards. EuroCC Supercomputing Accelerator Company.
Now that you understand how it works, explore what you can build with it