# About

I find out where the time, the cost and the failures actually go, and I publish the measurement so
someone else can re-run it. The subject has changed four times; the question has not.

## 2007–2011, Pune

B.Tech at the College of Engineering, Pune.

## 2011–2017, Bangalore

MSc and PhD at the Indian Institute of Science, in high-performance computing, parallel algorithms
and numerical methods. The physics was statistical thermodynamics and fluid dynamics; the work was
making particle simulations run on many nodes and trusting the numbers they produced. Three
peer-reviewed papers came out of it (*J. Chem. Phys.* 2020 and 2015, *Phys. Rev. E* 2013;
[ORCID 0000-0003-4516-4415](https://orcid.org/0000-0003-4516-4415)).

## 2018–2024, SankhyaSutra Labs

A Monte Carlo particle simulator (DSMC) in C++ and MPI, owned from the first line to release and,
for the last stretch, as tech lead. It ran 2× (source: SankhyaSutra Labs internal benchmark (2018–2024), résumé, checked 2026-09-21) faster than Sandia's SPARTA on the
same hardware and problem. The speedup came from profiling, which found cache misses and load
imbalance, and from redesigning the particle layout and the collision algorithm around what the
profile showed. It scaled past 100 (source: résumé, SankhyaSutra Labs, checked 2026-09-21) nodes. One thing did not work: a space-filling-curve
partitioning scheme, implemented and measured, was abandoned for its communication cost.

## 2024–, AMD

Senior Member of Technical Staff on uProf, the profiler AMD's compiler, runtime and silicon teams
use when a performance problem has to be attributed to one layer. I built out its tracing for
multi-node MPI and OpenMP runs, and I spend much of my time reading compiler-generated code for
vectorisation failures and memory stalls, then taking the finding back to the compiler or
architecture team with a reproducer and a cost.

## 2026, the compiler itself

The profiler kept pointing at the compiler, so I went there. A small MLIR compiler for the
operations that dominate dense inference (matmul, bias, activation) with fusion, tiling and an int8
type, whose kernel reached 64 GFLOP/s (source: résumé, "ML Compiler and Inference Performance (2026)", checked 2026-09-21) on one core, 2.4× (source: résumé, "ML Compiler and Inference Performance (2026)", checked 2026-09-21) a hand-tuned
blocked C baseline. I predicted the number from a machine model before measuring it; where model and
hardware disagreed was a cache-capacity cliff a single-level model cannot express. Reading the
production MLIR lowering stack, one `vector.contract` lowering choice made the same kernel
≈6× (source: résumé, "Codegen analysis of the production MLIR lowering stack", checked 2026-09-21) slower. Then upstream: pull requests to LLVM/MLIR and Spack, 8 pull requests, 5 merged (source: src/data/prs.json (tools/fetch_prs.py), checked 2026-09-23)
(the live list, with states, is on [Work](/work)), and an [RFC](https://discourse.llvm.org/t/91649)
on whether `vector.transfer_read` should keep `in_bounds`, which drew 9 (source: https://discourse.llvm.org/t/91649.json, checked 2026-09-22) replies
from the vector dialect maintainers. The [in_bounds project page](/projects/in-bounds) has the
measurement and the mistake.

## 2026, AI agents

The same question one layer up. When an agent fails, is slow or costs too much, does the model own
it or the code around it? A video series and four studies answer that with run ledgers anyone can
open: context policy, prompt-injection defences, LLM judges, and local models on one Mac. In the
security study the same public injection succeeded 2 to 35 of 97 (source: next_series/T02_agent_security/series/FACTS.md in dhairyashilRG/agent-harnesses-2026, checked 2026-09-19) times across five
models with no defence at all. Details on [Videos](/videos).

## How this site was made

The words are mine and every number carries a receipt: a source, a date checked and, where one
exists, a command. AI coding agents helped build the site's code and checks and drafted copy to a
written style guide; the measurements, the pull requests and the mistakes are my own. The site is a
public repository; its rules for changing anything are in it.

Contact: <a href="mailto:hello@dhairyashilrg.dev">hello@dhairyashilrg.dev</a> ·
<a rel="me" href="https://github.com/dhairyashilRG">GitHub</a> ·
<a rel="me" href="https://www.linkedin.com/in/dhairyashilrg">LinkedIn</a> ·
<a rel="me" href="https://www.youtube.com/@dhairyashilRG">YouTube</a> ·
<a rel="me" href="https://orcid.org/0000-0003-4516-4415">ORCID 0000-0003-4516-4415</a> ·
<a rel="me" href="https://scholar.google.co.in/citations?user=40V2yM8AAAAJ">Scholar</a>

---
Updated 2026-09-22. HTML: https://dhairyashilrg.dev/about