Elegant on a GPU?
Posted: 05 May 2012, 03:22
Hi all-
I am not familiar with the low level implementation of the elegant code, but I would guess that the basic calculations are mostly matrix multiplications. GPUs are optimized to compute matrix multiplications, and in general they can do these computations very rapidly and in parallel.
If the majority of the calculations in elegant are multiplying particle phase space vectors by transfer matrices, then I think this could really speed up the simulation. If instead a good chunk of the calculation is computing the matrices themselves, then this will be less useful.
There are a couple of frameworks called CUDA and openCL that are used to optimize a given code (usually written in C) for the system's GPU.
I only started thinking about this issue when we attempted to do live simulations of the full FACET beamline at SLAC. The lattice file contains ~4k elements and we run the simulation with 100k particles. It takes 5 to 10 minutes to run and that is too long when you are constantly tuning the machine. We will try to implement pelegant soon to cut down on simulation time.
Our lattice file uses RFCW elements for our cavities (most of the beamline), and CSR Bends and drifts in the final chicane. I think those are the only elements we use that do not lend themselves to obvious parallelization. Also, I looked at Borland's PhysRevSTAB.4.070701 where he describes the process for computing CSR. One of the steps is an FFT, which GPUs also do very well.
I probably won't have time to delve deeper into this until ~July. For now I am simply trying to figure out if this is a useful/tractable project. Let me know!
-Spencer
I am not familiar with the low level implementation of the elegant code, but I would guess that the basic calculations are mostly matrix multiplications. GPUs are optimized to compute matrix multiplications, and in general they can do these computations very rapidly and in parallel.
If the majority of the calculations in elegant are multiplying particle phase space vectors by transfer matrices, then I think this could really speed up the simulation. If instead a good chunk of the calculation is computing the matrices themselves, then this will be less useful.
There are a couple of frameworks called CUDA and openCL that are used to optimize a given code (usually written in C) for the system's GPU.
I only started thinking about this issue when we attempted to do live simulations of the full FACET beamline at SLAC. The lattice file contains ~4k elements and we run the simulation with 100k particles. It takes 5 to 10 minutes to run and that is too long when you are constantly tuning the machine. We will try to implement pelegant soon to cut down on simulation time.
Our lattice file uses RFCW elements for our cavities (most of the beamline), and CSR Bends and drifts in the final chicane. I think those are the only elements we use that do not lend themselves to obvious parallelization. Also, I looked at Borland's PhysRevSTAB.4.070701 where he describes the process for computing CSR. One of the steps is an FFT, which GPUs also do very well.
I probably won't have time to delve deeper into this until ~July. For now I am simply trying to figure out if this is a useful/tractable project. Let me know!
-Spencer