Introduction - Ayush Agarwal - GSoC Aspirant

[aygarwal]

Hi everyone!

I'm Ayush, currently pursuing a BE in Computer Science along with an MSc in Biological Sciences. I'm interested in participating in GSoC '26, and my background alignes well with the kind of work MDAnalysis is doing. I'm excited to contribute and help improve the codebase.

I am comfortable with C/C++/Python and I am currently learning Cython. I am also comfortable with Data Structures and optimisation of algorithms. I have a background in biological sciences with a familiarity with molecular biology, biochemistry, proteomics and so forth.

I'm new to contributing to open-source projects at this scale, but I'm very eager to learn and get involved. I recently opened PR #5252, which focuses on optimising inverse index mapping to improve performance. I would greatly appreciate any feedback or suggestions for improvement, and I want to refine my approach to better align with the project's standards.

Looking forward to learning from all of you and contributing meaningfully.

Thanks!
Ayush

[aygarwal]

I’m particularly interested in performance improvements, algorithm optimization, and benchmarking. I like analyzing complexity and figuring out ways to improve efficiency, and I’d love to contribute more in this area.

[aygarwal]

Thank you for the suggestion! I'll set up ASV locally and understand the existing benchmarks. I'll try writing a small benchmark and share it for feedback.
Thanks again!

[aygarwal]

Hi!
I went through the documentation of asv, set it up locally and then ran some of the existing benchmarks (selections, analysis/rms.py)
Understanding the architecture of asv and how it was used in conjunction with the mdanalysis package took a bit of time but I understood it in the end.
I implemented a benchmark for measuring the performance of Mean-Squared Displacement (analysis/msd.py)
In the code for calculating mean-square displacement, there is an example trajectory given, which is also used in the test files.

"""
This example computes a 3D MSD for the movement of 100 particles undergoing a
random walk. 

    from MDAnalysis.tests.datafiles import RANDOM_WALK_TOPO, RANDOM_WALK

Given a universe containing trajectory data we can extract the MSD
analysis by using the class :class:`EinsteinMSD`

    u = mda.Universe(RANDOM_WALK_TOPO, RANDOM_WALK)
"""

The msd.py file has two implementations of calculating MSD. There is a brute-force method and an optimised method that uses FFT. The benchmark tests I wrote run both, FFT=True and FFT=False
In the given example trajectory, the brute-force approach was running faster than the FFT approach.

========== ============= =============
--                     fft            
---------- ---------------------------
 msd_type       True         False    
========== ============= =============
   xyz      8.51±0.07ms   6.97±0.01ms 
    xy       7.26±0.2ms   6.66±0.04ms 
    yz      7.03±0.04ms    6.67±0.2ms 
    xz       7.06±0.3ms    7.07±0.3ms 
    x       5.76±0.08ms    3.84±0.1ms 
    y       5.46±0.02ms   3.90±0.05ms 
    z       5.55±0.07ms   3.77±0.04ms 
========== ============= =============

I wrote two different benchmarks for MSD - one which uses this example random walk, and a custom one in which the number of frames can be set while creating the Universe :

class MSD_Custom:
    def setup(self, n_frames, fft):
        n_atoms = 100
      
        self.u = mda.Universe.empty(
            n_atoms, 
            n_frames=n_frames, 
            trajectory=True
        )

I ran this benchmark using n_frames = [100, 1000, 10000]. FFT optimisation was now beating the brute-force approach.

========== ============= =============
--                     fft            
---------- ---------------------------
 n_frames       True         False    
========== ============= =============
   100      6.32±0.02ms   4.83±0.02ms 
   1000     20.6±0.03ms     448±10ms  
  10000       311±2ms      54.5±0.03s 
========== ============= =============

When the number of frames in the trajectory is small, FFT is beat by the brute-force solution. A more granular run showed that when number of frames is less than ~150, the brute force approach was better and above it, the FFT solution was better.

========== ============= =============
--                     fft            
---------- ---------------------------
 n_frames       True         False    
========== ============= =============
   100      6.28±0.03ms   4.83±0.01ms 
   200      8.14±0.03ms   17.0±0.08ms 
   300      10.9±0.04ms   37.7±0.05ms 
   400      11.7±0.03ms   65.6±0.09ms 
   500      12.7±0.06ms    101±0.06ms 
========== ============= =============

The example trajectory RANDOM_WALK has 100 frames. This explains why the brute-force approach was running faster than the FFT approach for the example trajectory.

Here is the benchmark code I wrote : Gist link

I also ran this benchmark on the last 100 commits of develop.

Over the last 100 commits there does not seem to be much variation, implying that there are no recent regressions.

Please let me know if this is comprehensive enough and whether this is a valid and useful benchmark.
If it is, I would really like to apply this to other modules if this approach meets the project's standards.

[orbeckst]

@Ayush-Agarwal-G1THUB this looks pretty good. I encourage you submit a PR just for the MSD benchmarks. It's not so important that you have many PRs, rather that there's one where we can interact.

[orbeckst]

When you open a PR, add a comment and ping me with @orbeckst so that I don't miss it. I can then review.

[aygarwal]

Glad to hear it's useful!
I'll submit a PR with the MSD benchmark for review and tag you in a comment.

[aygarwal]

I had a question : I read that asv defaults to using wall-clock time. Why does it use wall-clock time and not CPU cycles time, given that wall-clock time is/can be affected by other processes running on my machine? I understand that parallelism can skew these values (eg. if a process is run on 4 cores simultaneously, CPU cycles time will be 4 times wall-clock time).
But if the snippet being benchmarked does not leverage parallelism, would CPU cycle time be a better metric for writing a benchmark? Or is wall-clock time still used as the standard?

[orbeckst]

Wall-clock is the standard. At the end of the day, it's what humans care about :-) — "when is my workd done" and "can I take the time to get a tea/coffee?" ;-).

For pure numerics, cycles are also good to report as a rough measure of elementary operations. But once you involve I/O then other parts of the system are also important and perhaps not that easily measured in cycles (I am not sure that wait times show up).

What's important is to run the benchmarks in a clean and unloaded machine so that numbers are comparable. That's why there's one machine (c3potato) that has been running our benchmarks for years.

[aygarwal]

Aah okay I understand