2
$\begingroup$

When simulation atoms, molecules, colloids, autc., are there programs that define each interacting unity as an object in the OOP sense?

In my own case, I've been simulating magnetic nanoparticles in colloidal dispersion in Fortran, but I have many arrays that are unrelated in the code for each attribute of the nanoparticles. For instance, for 100 nanoparticles, I would have the arrays r(3,100) for 3D position, m(3,100) for 3D magnetic moments, xi(100) for adsorbed molecule surface density, etc.

I started my code using Fortran 77 compilers, so I didn't use the TYPE feature of Fortran 2003 that would allow me to put all those arrays inside the same type.

However, I've been using Java a lot these times, so I wondered if I would better define each magnetic nanoparticle as an object. So I would also define methods "move", "rotate", etc. in the nanoparticle class. I am not sure about how I would compute the pair interaction itself. I don't see how to define it as object class methods... I guess I would have to do it in the "controller" layer, not in the "model" layer (using MVC paradigm).

I only hesitate in making this new program because I suspect that defining my nanoparticles as objects would make simulations a lot slower, however beautiful the code would look to me. But if there are other programs that define pair interaction unities that way, there will probably be good reasons to do so and I won't be alone in that... :-)

| cite | improve this question | |
$\endgroup$
2
$\begingroup$

The problem is the memory layout. An object can be viewed in memory like a C struct which contains data and pointers to functions. If you use the OOP, you would have in each object the 3D coordinates, the 3D magnetic moments, and pointers to functions to manipulate this data. For instance, if you want to compute the distance between all pairs of particles, you will have to iterate on all the coordinates of the particles. To do this, you will need to iterate over an array of objects. For each object you will have to fetch the 3D coordinates and skip over the rest of the struct (ie other data and eventually pointers to functions).

This way of using memory is really inefficient for HPC for which memory access is crucial : using consecutive memory is by far more efficient. In a few words, you will load a lot of unused data which will badly use your caches, increase your memory bandwidth usage, disable the hardware prefetch possibilities, disable automatic vectorization, etc.

Also, using functions to access the data in your objects can add some overhead and be an obstacle to automatic vectorization, which is an additional performance loss.

Of course, if you are an expert you will take into consideration all these points and write an efficient OO HPC code, but in general the non-OO version will be much more efficient.

If you really want to do OO programming, then you should prefer objects containing arrays instead of arrays of objects.

| cite | improve this answer | |
$\endgroup$
  • $\begingroup$ "Objects containing arrays instead of arrays of objetcs" seems to be a good idea, because I could calculate the interaction between (say) colloidal particles inside an object called "colloidalParticles" that would contain all of them. But if I had two kinds of interacting bodies, say "spheres" and "cylinders", I would have to compute the interaction partially "out-object" anyway... $\endgroup$ – Leonardo Castro Dec 23 '15 at 13:21
  • $\begingroup$ I wondered if I would have any advantages in using still an object for each interacting unity but passing their attributes to arrays of a subroutine or class that would update the objects each N steps. Well, the objects would be rather superfluous that way, I think I only want them because they look "semantically appropriate". I've been trying to justify the existence of the such objects passing them to a view layer or such, but I could also pass only the data in every case... It's such a pitty I have to give up on defining everything as objects... $\endgroup$ – Leonardo Castro Dec 23 '15 at 15:14
  • $\begingroup$ In C++, objects don't contain method pointers unless said methods are virtual - they behave exactly like structs otherwise, since non-virtual methods will be statically resolvable. An array of many objects can be done in one contiguous allocation, although would be undesirable for HPC for layout/SIMD reasons. Using functions to access data members would typically be inlined by any decent compiler. I'd have assumed that Fortran would have similar behaviour, but I could be wrong $\endgroup$ – Mark K Cowan Dec 24 '15 at 12:44
  • $\begingroup$ @MarkKCowan Thanks for the clarification on non-virtual methods. Abourt the inlining, indeed the inlining should happen with good compilers, but there may be some cases where even using an inlined function may not allow the compiler to produce code which is as efficient as hand-written code. What we can say is that (decent) explicitly written code will never be worse than inlined functions. $\endgroup$ – Anthony Scemama Dec 24 '15 at 16:59
  • 1
    $\begingroup$ Ultimately, nothing will be as good as well-written assembly, but compilers nowadays are better at writing that that most humans could ever be (I recently disassembled some GCC output for 20 lines of C as GCC was 30% faster than my hand -written ASM... it took me 2 hours to decipher how GCC's worked and why it was so much faster). I'd be surprised if a compiler-inlined function was ever slower than a manually-inlined function for the same body. $\endgroup$ – Mark K Cowan Dec 24 '15 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.