[Users] bug in Dissipation thorn?

[Kentaro Takami]

Hi, Erik,

> These two executables are not useful to me, since you said you are not
> interested in using the -fp-model-precise option anyway. I therefore see no
> reason to examine it. I am rather interested in comparing the executables
> for (a) the original version and (b) a version that you "like".

OK. In same directory, you can find all executables used by performance test.
In order to find the reason why random changes are produced or not,
"cactus_GRHydro.F90_DoStyle--datura.OMP-NO_PRECISE-NO" is reasonable,
because "do-loop" style is used.
I note only "Dissipation::order = 5" can be used in this executable.


>> > Do you also have performance data to support your statement that
>> > OpenMP is slowing things down in this case?
>>
>> Please see the attached file.
>> Apparently the case (4) is the fastest, that is, OMP palatalization
>> shouldn't be used
>> for these small section.
>
> If I read the numbers correctly, then the original code is the fastest in
> all cases, sometimes by a factor of five.

Oh, you are right.
Sorry, I was seeing consuming time, i.e., "getrusage".

Due to the data, this compiler doesn't parallelize "!$OMP  PARALLEL WORKSHARE"
properly.  So, as Peter pointed out, many compiler still can't use
this directive,
and it is safe to use "!$OMP  PARALLEL DO".

OK, I agree that we use "do-loop" + "OpenMP" now.

Forthermore, "introducing a local array var" to avoid random change,
derive slow down, especially for OpenMP.


Kentaro TAKAMI