[Feature Question] Roadmap for Performance Improvement (GPU & Multi-Node)

[Kihang-Youn]

Hello Team,

This is not a bug report, so I am unsure which category to use. If there is a dedicated discussion space (for non-bug topics), please let me know.

I understand that the current computations in phono3py are accelerated using LAPACK. Do you have a roadmap for future GPU acceleration? Additionally, are there any plans for multi-node parallelization?

Thank you for your excellent work!

[atztogo]

Dear @Kihang-Youn,

Do you have a roadmap for future GPU acceleration?

We have no plan to support GPU currently.

are there any plans for multi-node parallelization?

We have no plan to support MPI. But for example, thermal conductivity calculation can be distributed by q-points and bands.
https://phonopy.github.io/phono3py/workload-distribution.html

[Kihang-Youn]

Hi @atztogo,

Thanks for your quick and concise answer!

Regarding performance, if GPU acceleration were to be implemented someday, where do you think the greatest hotspots/bottlenecks would be within the phono3py workflow (e.g., three-phonon matrix calculation, BZ integration, data transfer)?

Similarly, which computational step has been the most challenging to parallelize effectively using multi-core CPU in the current implementation?

Please let me know if this question is inappropriate or broad.

[atztogo]

This function is a bottleneck.

phono3py/c/reciprocal_to_normal.c

Line 82 in 8074d3c

void reciprocal_to_normal_squared(

The reason I don't want to use GPU is not just the difficulty of implementation, but rather the increase in maintenance costs. I left some comment here,
phonopy/phonopy#644

which computational step has been the most challenging to parallelize effectively using multi-core CPU in the current implementation?

It depends on the number of atoms in the primitive cell. It is adjusted the location of OpenMP application based on that.

phono3py/phono3py/phonon3/interaction.py

Lines 885 to 888 in 8074d3c

	if len(self._triplets_at_q) > num_band:
	openmp_per_triplets = True
	else:
	openmp_per_triplets = False

If we were using first-principles calculation as force calculators, usually it is the dominant part of computational demand, so it is better to consider accelerate it not ph-ph calculation.

[Kihang-Youn]

Hi Atsushi,
Thank you so much for your detailed response!
And honestly, I didn’t realize at first—but you’re quite a famous researcher in this field! I saw how many citations your papers have, and it’s truly an honor to have this conversation with you :-)

To give you a bit more context,
I work at NVIDIA, helping Korean researchers make the best use of our solutions. One of our customers mentioned that they’re using phono3py, so before talking with them, I wanted to check whether GPU acceleration is already possible—or at least feasible—for this code.

It’s good to understand that the main reason it hasn’t been transitioned to GPU is the maintenance complexity. My plan is to identify which parts of their actual workflow are the main bottlenecks and see if those can be offloaded to the GPU.

I’ll make sure to share an update with you if anything moves forward and if you don't mind. Thanks again—I’ll definitely take a close look at similar work that converts the run_qpoints part to cuPy.
Really appreciate your help!