I make science code go brrrrrr.
Master's in High Performance Computing · ICTP & SISSA, Trieste, Italy
Currently finishing a fully funded Master's in High Performance Computing at the Abdus Salam International Centre for Theoretical Physics (ICTP) — a UNESCO research centre in Trieste — run jointly with SISSA, the International School for Advanced Studies. Thesis defends December 2026.
Before that, four years building production platforms — distributed compute, CI/CD and data pipelines — at AI startups. These days I spend my time porting and profiling scientific codes for heterogeneous CPU/GPU systems.
Most of what's here was run on Leonardo at CINECA, up to 1792 cores or 40 A100s. Each badge above links to a project that uses it.
Right now
- Master's thesis with OGS, the National Institute of Oceanography and Applied Geophysics — taking
gmrecordsground-motion processing to the edge, so a seismological network processes records on the accelerometers themselves instead of shipping raw waveforms to a central server. - Ongoing research on xFFL with the University of Turin — cross-facility federated learning, training across HPC sites that cannot pool their data.
| Project | What it is | Result |
|---|---|---|
| low_level_optimisations | An out-of-tree LLVM pass that classifies loop memory access by stride and predicts vectorisability before the code runs | In a DRAM-bound loop, traffic beats codegen — shown with a control |
| gpu-kernel-profiling | Reading Nsight Systems traces on A100 — plus tooling to extract kernel timings straight from the trace databases | 11% of peak, traced to uncoalesced writes |
| fft-gpu-programming-models | Six implementations of one FFT — hand-written CUDA, OpenACC and cuFFT — benchmarked head to head | cuFFT ~12× over the best verified kernel |
| matrix-multiplication-parallel | Dense GEMM four ways, with roofline analysis | 45 TFLOP/s on 16 nodes |
| Project | What it is | Result |
|---|---|---|
| miniWeather-mpi-openacc | Fortran atmospheric model taken to MPI + OpenMP + OpenACC, with NetCDF output, CMake and containerised CI | 190 s → 2.1 s on 256 cores, then ≈4× on 8 A100s |
| quantum-espresso-ks-scaling | Profiling and GPU-porting the Davidson eigensolver inside Quantum ESPRESSO — plane-wave DFT | FFT 11.3×, solver only 2.4× |
| jacobi-poisson-solver | One Laplace problem in three parallel models — MPI+OpenMP, HDF5 parallel I/O, OpenACC — plus NVIDIA's NVSHMEM sample | 94% node-to-node efficiency, 1→10 nodes |
| fisher-kpp-rumour-diffusion | Reaction-diffusion PDE solved in parallel with PETSc — DMDA, Runge-Kutta time integration |
Matches the analytic wave speed |
| Project | What it is |
|---|---|
| hpc_containers | One MPI+OpenACC solver shipped four ways — native, InfiniBand-forced, Singularity, Docker — including the UCX/PMIx configuration that makes MPI work over InfiniBand inside a container |
| federated-learning-nextflow | FedAvg as a real Nextflow/SLURM workflow, one GPU per client, model weights exchanged as files |
| python-hpc-interop | What Python actually costs in HPC — pybind11 runs 4–17% behind native C++, depending on scale |
Every performance figure in these repos is re-derived from the committed logs and source rather than quoted from memory, and each one is published with the things that make it mean something — the baseline it's measured against, the build flags, and what was held constant between the runs being compared.
Where a figure doesn't survive that check, I change it and write up the reasoning in the repo. The LLVM pass is the one I'd point at: I built a control experiment to test my own published conclusion, and it overturned it — three static instruments had agreed with each other because none of them can see memory traffic. The control, the measurements and the revised result are all in the repo.
| Languages | Fortran · C · C++20 · Python · Bash |
| Parallel programming | MPI (OpenMPI, HPC-X) · OpenMP · OpenACC · CUDA · NVSHMEM · NCCL |
| GPU libraries | cuBLAS · cuFFT · CuPy · NVIDIA HPC SDK |
| Performance analysis | Nsight Systems · NVTX · perf · llvm-mca · LLVM analysis passes · roofline modelling |
| Scientific I/O | NetCDF · HDF5 · collective MPI-IO · ParaView / VisIt |
| Numerical libraries | PETSc · ScaLAPACK · OpenBLAS · FFTW · LAPACK |
| Build & test | CMake · CTest · Make · Git · GitHub Actions |
| Clusters & containers | SLURM · UCX / InfiniBand · NUMA-aware pinning · Docker · Singularity / Apptainer |
| Machines | Leonardo (CINECA) · JUPITER (JSC) · COKA (INFN) · ICTP / SISSA / Ferrara clusters |
| Frameworks | PyTorch · TensorFlow · scikit-learn |
| Scientific Python | NumPy · SciPy · Pandas · Matplotlib · Numba · pybind11 · mpi4py |
| Distributed & federated | FedAvg · Nextflow · Kubeflow · Argo Workflows |
| Tracking | Weights & Biases |
| Cloud | AWS · GCP (Cloud Run, GKE) |
| Orchestration | Kubernetes · Docker · Ansible |
| Backend | Django · FastAPI · Flask · REST / SOAP integrations |
| Data stores | PostgreSQL · MongoDB · Redis · ChromaDB |
| Observability | Prometheus · Grafana · Loki · OpenTelemetry · Sentry |
| Reliability | Load testing · autoscaling · capacity planning · CI/CD · on-call automation |
Smaller collections that the projects above grew out of — cuda_stuff · open_mpi_openmp_stuff · file_io_stuff · fortran · petsc · quantum_computing