yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #11747
Re: [Branch ~yade-pkg/yade/git-trunk] Rev 3486: Parallelization of interaction loops in Law2_..._Capillarity (which is in fact not a LawFunctor h...
So, there is some comparisons in the attached figures.
In the figures with "par" suffix you will find results from two simulations with j4:
- one with the updated code with parallel loops over interactions
- the other one with previous code.
In the figures with "_j" suffix there is results from:
- one simulation with j1
- one of the two j4 simulations quoted previously
I consider these figures do not show anything "bad"..
As for the fusion detection, unfortunately I can not say anything (I did not really give a look into this part yet).
What would you think then if I remove some of the parallel loops, keeping only the one for the block from l. 174 and 203 ? This block mainly use addForce() function, that is thread safe. Before that, it might modify the computed fCap in fusion case. With what I understand from openMP, it seems that nothing bad might happen here, does it ? (I guess each interaction is accessed only from one thread)
Jerome
________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx]
Sent: December 4, 2014 10:56 AM
To: yade-dev@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3486: Parallelization of interaction loops in Law2_..._Capillarity (which is in fact not a LawFunctor h...
On 04/12/14 18:46, Bruno Chareyre wrote:
On 03/12/14 22:57, Jerome Duriez wrote:
Hi,
General discussions apart, what is the problem with this commit ?
I don't know if there is a problem or not.
I guess you checked that it gives the same result before/after and -j1/-jN.
Did you check also the fusion detection?
After a quick look, there is a problem here:
https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L117
This insert() method is not thread-safe. If two threads are inserting at the same time the result is undefined.
It needs a "critical" clause (this will surely kill the performance) or a better design.
B
Follow ups
References