CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > General Forums > Main CFD Forum

AoS vs SoA data structures for 2D euler equations

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By aerosayan

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 28, 2021, 21:11
Default AoS vs SoA data structures for 2D euler equations
  #1
New Member
 
Join Date: Dec 2021
Posts: 28
Rep Power: 3
ander is on a distinguished road
Hi
I am going to develop a 2D structured grid explicit Euler solver in C++. I am planning to use 1D dynamic arrays to store the conserved variables. My question is if it is preferable to use an array of structures (aos) or structure of arrays (soa) in this case.

The aos approach could look like the following
Code:
struct Conserved {
    double density, mom_x, mom_y, energy;
};

Conserved* field = new Conserved[N*N];
The soa approach could look something like this:

Code:
struct ConservedField {
    double* density;
    double* mom_x;
    double* mom_y;
    double* energy;
};

ConservedField field;
//allocate memory for field
Which approach is likely to yield the best performance?
ander is offline   Reply With Quote

Old   December 29, 2021, 05:24
Default
  #2
Senior Member
 
sbaffini's Avatar
 
Paolo Lampitella
Join Date: Mar 2009
Location: Italy
Posts: 1,940
Blog Entries: 29
Rep Power: 36
sbaffini will become famous soon enoughsbaffini will become famous soon enough
Send a message via Skype™ to sbaffini
Depends on how you actually access your variables the most and how the compiler (or language) promises to lay down variables in the aos case.

If you mostly access them only one at the time, the soa is definitely what you need.

But what if you use a solver that mostly needs to access all of them at once (i.e., a coupled solver)? In this case you would probably prefer the aos version, PROVIDED that consecutive array elements are stored consecutively. But I am no expert in C++, so I have no idea if that ever happens or under what conditions it does.

As usual, testing is needed for the specific case.
sbaffini is offline   Reply With Quote

Old   January 2, 2022, 01:15
Default
  #3
Senior Member
 
Sayan Bhattacharjee
Join Date: Mar 2020
Posts: 456
Rep Power: 6
aerosayan is on a distinguished road
Aight. You're where I started one year ago.

Finally a topic in which I consider myself somewhat experienced

Store all of values together using AOS.

Most of your solver's time will be spent in calculating the fluxes and residuals. So you need the data to be together in cache.

Also, just focus on parallelizing your code.

Don't even bother with improving the performance of each thread, because it doesn't matter that much.

Your code will be limited by the memory bandwidth, and if you use SOA, you're going to be doing lots of reads and writes to very far away positions in memory.

If you choose SOA, your fluxes might also be in SOA form, which will be bad because you will be doing lots of write operations during the flux calculation stage.

Go through my post history in this forum.

You'll see that I had the same questions and after some research I found out that memory bandwidth is the limiting factor.

My code was fast, too fast, so much that the memory bandwidth couldn't keep up and I was getting lots of cache misses.

That's what you want to avoid.

Look up roofline model of performance analysis, you'll see that your performance is limited by how many reads you do.

sbaffini had previously said to calculate all things on the fly, which only made sense after I did my own analysis too. So, additionally, calculate the volume, cell area, etc. on the fly. That is, don't even bother storing them. Those reads will slow you down. Just calculate them directly from the coordinates and then use them.
aerosayan is offline   Reply With Quote

Old   January 4, 2022, 22:28
Default
  #4
New Member
 
Join Date: Dec 2021
Posts: 28
Rep Power: 3
ander is on a distinguished road
Luckily I choose AOS randomly before I read this, so I won't have to bother with rewriting everything
I'll check out your post history and the other stuff, when i have time!
I also have a question about operator overloading. Is this acceptable to use? I'm thinking about using it in the cases where the same operations are done on all 4 entries in the vectors, like for instance when timestepping. It would make the code easier to read and write, but I have heard they are slow.
ander is offline   Reply With Quote

Old   January 6, 2022, 10:45
Default
  #5
Senior Member
 
Sayan Bhattacharjee
Join Date: Mar 2020
Posts: 456
Rep Power: 6
aerosayan is on a distinguished road
Modern compilers can optimize operator overloading. Although check the disassembly to make sure you're getting optimized code. If you don't know what optimized code looks like in assembly, you don't need to worry about it right now.

If you're operator overloading, don't go too deep. Nested operator overloads might not get optimized correctly if you have 3 or 4 levels of indirection.
ander likes this.
aerosayan is offline   Reply With Quote

Reply

Tags
c++, euler, memory

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[OpenFOAM] Paraview python script, creating data using only CLI, saving in csv/excel file Ash Kot ParaView 1 September 24, 2021 13:23
Periodic boundary conditions for compressible Euler equations selig5576 Main CFD Forum 24 April 25, 2017 17:43
Incompressible Euler Equations with SIMPLE method yfjok22 OpenFOAM Programming & Development 1 September 22, 2016 09:11
Normalization of eigenvectors of the Euler equations bubble45 Main CFD Forum 9 March 16, 2015 18:09
Euler equations? Jan Ramboer Main CFD Forum 2 August 19, 1999 02:58


All times are GMT -4. The time now is 21:19.