An eightfold equivalence-preserving speedup of the JUNO OMILREC vertex and energy reconstruction

Imagine a giant, ultra-sensitive underwater camera sitting deep underground, waiting to catch the ghostly whispers of particles called neutrinos. These particles are so shy they can pass through light-years of lead without stopping, but when they do interact with the special liquid inside the camera, they leave behind a tiny flash of light. To understand what happened, scientists need to figure out exactly where that flash occurred (the "vertex") and how much energy it had. This is like trying to find a firefly in a dark stadium by listening to the echo of its buzz from thousands of microphones scattered everywhere. The computer program that does this math is called a "maximum-likelihood fit." It's a bit like a detective who has to test millions of possible locations for the firefly, checking every single microphone's data for each guess, until they find the one spot that makes the most sense. The problem is, this detective is incredibly slow. It takes a long time to run these tests, and since the camera sees thousands of events, the computer gets overwhelmed, becoming a bottleneck that slows down the whole scientific discovery process.

This paper tells the story of how a team of scientists and an AI assistant turned that slow detective into a lightning-fast one, without changing the answers it gives. They took the original program, which was taking about 1.5 seconds to solve a single mystery, and sped it up to less than 0.2 seconds. That's an eightfold improvement! They didn't change the math or the physics rules; instead, they fixed the way the computer was "thinking" about the data. They realized the program wasn't slow because the math was too hard, but because it was wasting time running around looking for information, like a librarian who keeps running to the back of the library to fetch a book instead of just grabbing it from the desk. By organizing the books (data) better and stopping the librarian from doing unnecessary trips, they made the process incredibly efficient. The result is a supercharged version of the software that solves the same puzzles just as accurately, but in a fraction of the time, allowing the experiment to handle much more data without needing to buy a million new computers.

The Detective's New Superpower

The Jiangmen Underground Neutrino Observatory (JUNO) is a massive experiment designed to solve the mystery of how neutrinos get their mass. To do this, it uses a central detector filled with 17,612 giant light sensors (photomultiplier tubes). When a neutrino interacts, it creates a pattern of light hits across these sensors. The software, called OMILREC, acts as the brain, trying to reconstruct exactly where the event happened and how much energy it released. It does this by using a "maximum-likelihood fit," a statistical method that tests different possible locations and energies to see which one matches the observed data best.

However, the original version of this software was a bit of a sluggard. For every single event, the computer had to perform about 470 "evaluations" (guesses). For each guess, it had to loop through all 17,612 sensors to calculate the expected light pattern. This meant the computer was doing roughly 760 million sensor checks for just 100 events. The team discovered that the program wasn't slow because it was struggling with complex math; it was slow because it was "latency-bound." In simple terms, the computer was spending most of its time waiting for data to arrive from memory, like a chef waiting for ingredients to be delivered to the kitchen, rather than actually cooking. It was only using about 10% of its potential speed because it was constantly jumping between different parts of the code and chasing pointers in memory.

The Speed-Up Recipe

The authors didn't rewrite the physics or change the algorithm's logic. Instead, they applied a series of "equivalence-preserving optimizations." Think of this as rearranging the kitchen so the chef never has to leave the stove. They used a step-by-step approach, where every single change was tested against a "frozen reference"—a perfect, unmodified version of the original code. If a change made the answer even slightly different (beyond a tiny, acceptable margin), it was rejected. This ensured that the physics results remained exactly the same, just much faster.

Here is how they did it, step by step:

1. Flattening the Data: They stopped the computer from jumping between different virtual objects and instead laid out the data in a neat, continuous row. This removed the "pointer chasing" that was causing delays.
2. Bulk Vectorization: They grouped the geometry calculations (like angles and distances) so the computer could do them all at once, like a factory assembly line, rather than one by one.
3. Hoisting Invariant Work: They realized the computer was recalculating the same things (like dark noise and hit lists) over and over again for every single guess. They moved these calculations to the front, so they only had to be done once per event.
4. Precomputation: They cached (saved) quantities that didn't change often, so the inner loop could just read them instead of recalculating them.
5. Loop Splitting: They specialized the loops for different stages of the fit, skipping unnecessary calculations for sensors that weren't relevant at that specific moment.
6. Fast Paths: For the most common scenarios, they used a slightly faster, lower-precision math path that was still accurate enough for the job.

The Results: Faster, Not Different

The results were dramatic. On an Intel Xeon processor, the time to reconstruct a single event dropped from 1524.8 milliseconds to 189.2 milliseconds, a speedup of 8.06 times. On an AMD processor, it went from 705.1 milliseconds to 134.9 milliseconds, a 5.22 times improvement. With further tweaks, they even reached 177.7 milliseconds (an 8.6 times speedup).

Crucially, the paper emphasizes that this speedup did not come at the cost of accuracy. For the first seven versions of the optimized code, the results were "bit-identical" to the original, meaning the computer output was exactly the same down to the last digit. For later versions that used slightly different math, the differences were so tiny (within a relative drift of 1.3 × 10⁻¹⁴) that they were well within the safety limits. When they tested the final results on nearly 861,000 calibration events, the reconstructed positions and energies matched the original baseline within 4 millimeters and 7 keV (kilo-electronvolts), respectively. This proved that the faster code was just as trustworthy as the slow one.

The team also noted that an AI coding agent helped them write and verify these optimizations, acting as a tireless assistant that checked every change against the strict rules. The paper concludes that this method—diagnosing the bottleneck, optimizing under a strict "equivalence contract," and verifying with a frozen reference—is a template that can be used to speed up other complex scientific simulations without altering their scientific conclusions. They didn't just make the computer faster; they made it smarter about how it uses its time, proving that sometimes the best way to solve a hard problem is to stop wasting time on the easy parts.