Optimizations for N-body simulation using Rust API?

113 views
Skip to first unread message

Taylor

unread,
Feb 11, 2021, 9:10:34 PM2/11/21
to ArrayFire Users
Hi there. I started using ArrayFire a few days ago when I created a 2D simulation of particles using Rust. I originally programmed it in a sequential style, then converted it to iterators and parallelized it with Rayon. That provided a substantial speed-up but I still had the feeling that the CPU was the wrong tool for this task. I had a look around for GPU libraries in Rust and eventually settled on AF, because it seemed like the highest-level API for this type of work. After trying for a while to get my head around array programming, I had my sudden break-through and came up with the idea of using 2 N x N arrays, where each 2D coordinate between them represented a pair of points. In the end this sped my program up by around 2-3 times, certainly an improvement but not by as much as I had hoped. And my hypothesis that this would substantially improve my program's scalability turned out to be dead wrong! This prompted me to do a little bit more research about this specific problem and I found that it's called an N-body problem. I haven't found anything in AF documentation referencing this specific problem, but from what I gather my approach of simulating N² interactions each step is considered the "naive" approach, and operating on 2D matrices is not the preferred way to solve this problem. My next approach would have been to use gfor to go back to 1D vectors instead of 2D matrices, but gfor is not available in the Rust API so I cannot. Is there anything I could do to achieve the same effect (or would gfor just replicate my manual replication of values) or otherwise improve the performance of my program?

Pradeep Garigipati

unread,
Feb 12, 2021, 12:20:30 AM2/12/21
to Taylor, ArrayFire Users
Hey Taylor,

GFOR is a mere syntactic sugar already for available batch operations in ArrayFire. Most functions and JITed operations can operate in batch mode. This is not at all a limitation of Rust Wrapper for ArrayFire. In fact, there is nothing missing in Rust wrapper that limits vectorizing your program when compared to C++.

If you can share a small code snippet of the math equations you are trying to come up with using ArrayFire. I can then suggest possible ways to implement it using Rust Wrapper.

Also, we encourage our rust wrapper users to raise conversations on https://github.com/arrayfire/arrayfire-rust/discussions . It is not mandatory to have all discussions/conversations there, but it would help create a collection of knowledge from arrayfire's rust wrapper users for future users.

You can also showcase your projects here https://github.com/arrayfire/arrayfire-rust/discussions/categories/show-and-tell if they are public projects.

Thank you,
Pradeep.

On Fri, Feb 12, 2021 at 7:40 AM Taylor <quantumt...@gmail.com> wrote:
Hi there. I started using ArrayFire a few days ago when I created a 2D simulation of particles using Rust. I originally programmed it in a sequential style, then converted it to iterators and parallelized it with Rayon. That provided a substantial speed-up but I still had the feeling that the CPU was the wrong tool for this task. I had a look around for GPU libraries in Rust and eventually settled on AF, because it seemed like the highest-level API for this type of work. After trying for a while to get my head around array programming, I had my sudden break-through and came up with the idea of using 2 N x N arrays, where each 2D coordinate between them represented a pair of points. In the end this sped my program up by around 2-3 times, certainly an improvement but not by as much as I had hoped. And my hypothesis that this would substantially improve my program's scalability turned out to be dead wrong! This prompted me to do a little bit more research about this specific problem and I found that it's called an N-body problem. I haven't found anything in AF documentation referencing this specific problem, but from what I gather my approach of simulating N² interactions each step is considered the "naive" approach, and operating on 2D matrices is not the preferred way to solve this problem. My next approach would have been to use gfor to go back to 1D vectors instead of 2D matrices, but gfor is not available in the Rust API so I cannot. Is there anything I could do to achieve the same effect (or would gfor just replicate my manual replication of values) or otherwise improve the performance of my program?

--
You received this message because you are subscribed to the Google Groups "ArrayFire Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to arrayfire-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/arrayfire-users/a123c631-49e7-417b-a09b-816ec82dca21n%40googlegroups.com.


--

Taylor

unread,
Feb 12, 2021, 3:58:20 AM2/12/21
to ArrayFire Users
I've created a thread on the AF-rust discussion page, let's move our conversation over there: https://github.com/arrayfire/arrayfire-rust/discussions/281
(and I'd be happy to showcase my project once it reaches a level of completion I'm happy with!)
Reply all
Reply to author
Forward
0 new messages