I build high-performance backend and ML infrastructure, and I validate it against references instead of trusting it.
At Reliance Jio, I work on production 4G/5G analytics, deterministic query compilation and GPU-backed inference on Kubernetes/OpenShift, including a 13-node, air-gapped, IPv6-only deployment. Outside work, I contribute to PyTorch, DuckDB, bpfilter and other C++ and ML projects, and build tools for GPU performance and distributed coordination.
Eight merged changes across five upstream C++ projects (PyTorch, DuckDB, bpfilter, Apache Arrow nanoarrow, OpenTelemetry C++); the four 2026 bug fixes each carry a regression test that fails without the fix, and every GPU claim below was measured on rented hardware and committed.
PyTorch core — two accepted changes
Enabled existing dynamic-shape support for foreach operations by default under torch.compile, with a test update (#158985). Exposed rearrange through the torch.func public API, with tests and documentation (#173183).
DuckDB — one merged pull request
SELECT DISTINCT over an unnested struct covered only the columns as written, not the expanded fields, so rows collapsed wrongly; the binder now regenerates the targets after binding (#27973).
Meta’s bpfilter — three merged pull requests
Added IPv4 Type of Service and IPv6 Traffic Class matchers, including command-line parsing, BPF code generation and unit tests (#364, #369); the IPv6 implementation uses endianness-safe byte loads. Fixed meta.probability above 50 %, where a sign-extended 32-bit immediate in a 64-bit BPF compare made every such rule match 100 % of packets (#597).
Apache Arrow nanoarrow and OpenTelemetry C++ — one merged pull request each
Made nanoarrow's testing JSON comparison recurse into nested and dictionary child fields' metadata (#993). Removed a misaligned sockaddr_in access in OpenTelemetry C++'s SocketAddr, with a regression test that fails on the original header even without sanitizers (#4725).
Landing commits: PyTorch foreach · rearrange · DuckDB DISTINCT · bpfilter probability · nanoarrow metadata · OpenTelemetry sockaddr.
Inside Mustard · Clock synchronization, protocol correctness and runtime trade-offs
Mustard is a multi-instance watch-party platform: clients connect over WebSockets and use NTP-style clock estimation with predictive drift correction, and updates go through atomic Redis Lua scripts. The 48 ms P95 is a specific claim: steady-state player-reported drift, measured across three Chrome clients at approximately 300 ms RTT during a 240-second test. It is not a physical audio-output measurement.
Protocol correctness was a separate question. TLA+/TLC model checking exposed a stale-epoch bug after store resets, leading to an ordered-epoch fix, and idempotency keys plus atomic updates keep control commands from being applied twice within the deduplication window.
I also built Go and Rust relays to test protocol conformance and runtime costs. They are study implementations, not the production backend. In a local 10,000-connection test, the Rust relay used 14.5 KB of memory per connection versus 40 KB for Go; the extreme-tail latency comparison was inconclusive.
Live site · Source · Sync design · TLA+ findings · Go/Rust study
Inside Fused CUDA operators · Custom ops, deterministic gradients and FP8
These LayerNorm/RMSNorm kernels combine fused residual-add, FP8 outputs and deterministic backward reductions, and come as drop-in PyTorch modules that work under torch.compile without graph breaks. Parameter gradients use fixed-order reductions rather than atomic accumulation, which is where the determinism comes from.
For dynamic RMSNorm-to-FP8, I measured 4.9–7.2× over the eager PyTorch composite and 1.04–1.76× over the compiled composite, across tested FP16 shapes on an NVIDIA A100. Those are kernel-time comparisons, not end-to-end model speedups. For a fuller picture, the repository also documents H100 results and configurations where PyTorch wins. v0.6.0 (October 2026) adds a register-resident few-row RMSNorm kernel and a warp-per-row dynamic-FP8 path for Hopper; in an A/B against v0.5.0 on an H100 NVL, the few-row kernel is faster at every measured shape of width ≥ 4096 in all three dtypes, with per-op medians of 0.62–0.85× the v0.5.0 kernel time (results).
Inside PyTorch AutoTune · Measure the configuration instead of guessing it
Rather than guess at a training configuration, the tuner benchmarks precision, compile mode, memory format and fused-optimizer configurations on the target model and batch. Search runs under a budget, configurations are cached for reuse, and reports show trial results, compilation cost and estimated break-even time.
I measured 2.7–6.7× training-step speedups after tuning versus the PyTorch-default FP32 eager baseline across ResNet-50, ResNet-18 and a six-layer Transformer on an NVIDIA A100, with the tuner using torch.compile alongside the other optimizations. The baseline matters, though: on the Transformer, the gain is 2.55× against an eager baseline with TF32 matmuls enabled, rather than 6.65× against the defaults. Search costs and numerical trade-offs are documented as well.
Inside ChatGPT Spark · A shipped extension and its retrieval backend
Spark is a Chrome extension I built and published for capturing and searching conversation history. A React/TypeScript dashboard lets you browse saved conversations, FastAPI handles backend requests, and ChromaDB stores the embeddings behind semantic search.
Also built: 3D Point Cloud Viewer — C++/OpenGL, octree-based culling and level-of-detail rendering.
| Area | Tools I use |
|---|---|
| Languages | C++, C, Python, Rust, Go, CUDA, TypeScript, SQL |
| Backend & data | FastAPI, NestJS, WebSockets, SSE, ClickHouse, PostgreSQL/PostGIS, Redis, ChromaDB |
| Infrastructure | Linux, Docker, Kubernetes/OpenShift, AWS, CI/CD |
| ML & performance | PyTorch internals, torch.compile, vLLM, cuSPARSE/cuDNN, GPU profiling, kernel fusion, benchmark design |
| Correctness | TLA+/TLC, reference-based tests, failing-first regression tests, deterministic-mode checks, protocol-conformance checks |
Have a systems problem worth digging into?
I’m interested in backend, distributed-systems, ML-infrastructure and performance-engineering work.
Frisco, Texas · Open to relocation
Email · LinkedIn · Hugging Face


