yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

> Now, look at my weird results (60 seconds of simulation):
> 
> OMP_NUM_THREADS    3D on     3D off
> 1                  5375      5498   (1 core at 100%)
> 2                  6340      6582   (2 cores at 95%)
> 3                  6977      7040   (3 cores at 95%)
> 4                  6624      6939   (4 cores at 100%)
> 5                  6240      6970   (5 cores at 95%)
> 8                  1267      3491   (8 cores at 100%)
> 12                 6018      5806   (8 cores at 45%)
Nothing surprising, that is just the way it works. CPU percentages are
approximate; sometimes the kernel can show 100% load and it is slower
than 20% loaded CPU and so on; it probably has some internal cause, but
it doesn't reflect computation speed. The number with 3d on are not very
interesting, that depends on the graphics card etc and I don't think any
serious simulation is run with the 3d view.
> You said that with little amount of bodies the speedup is not
> visible. I am confirming this ;) Later I'll see how it works with
> thousands of bodies.
That was already tested many times. I am attaching a figure for 10k
particles (Xeon cluster).
> On boost ML one guy recommended tbb::concurrent_vector and
> intel's thread building blocks library is in debian. But adding
> another library to our dependencies isn't something to be done
> hastily. Just things that we can keep in mind.
That would not solve nothing. We have no "problem" with the body
container, but with interactions (not stored in a vector) and it could
be solved by saving Interaction, InteractionGeometry and
InteractionPhysics as shared_ptr's to guarantee that they will not
disappear while rendered. But, what's the use of that effort? Just for
the rendering?
> BTW, I see that getProgress() lack of naming convention. Apparently
> that was me ;) So how is it now in the whole rest of the code? Do we
> have getVal(); setVal(val) now?
? There is no unified convention on that, except of making data members
where they have to be accessed even just for reading :-D

Cheers, v.

Attachment: openmp-scaling.pdf
Description: Adobe PDF document