[Octopus-devel] [Octopus-notify] svn commit: r8394 - trunk/src/hamiltonian by jrfsousa
José Rui Faustino Sousa
jrfsousa at teor.fis.uc.pt
Thu Nov 10 17:08:57 WET 2011
On Thu, 2011-10-20 at 22:45 -0400, Xavier Andrade wrote:
> 2011/10/19 José Rui Faustino Sousa <jrfsousa at teor.fis.uc.pt>:
> > My point was only with the private declaration, it listed the "forall"
> > variable as private, my understanding is that it is in the best useless
> > and in the worst it could interact in unexpected ways in the code
> > generated by the "forall", which may not be a loop.
> The variable _must_ be private as each loop is executed independently
> on each thread.
And it is by default.
I was having segmentation faults at that point in the code and, wrongly,
assumed the unnecessary private declaration was confusing the compiler
when in fact the problem was insufficient per thread stack.
> > That is not stupid. If you write a(1:n)=b(1:n), instead of just a=b, the
> > compiler is quite right to assume that you mean something.
> Copying the values to a temporary array is stupid.
For simple cases yes, but for any sufficiently interesting case probably
not. You also have to take in account assignment rules.
> Luckily, I can't imagine how much worst Windows could be written if it
> was written in Fortran.
One always has to choose the right tool to the job. There are no
Anyway I am pretty sure the calculator thingie was work much better! It
could not be any worst than writing numerical code in C. ;-)
> They are better, but they have limitations (you can't use temporary
> variables inside) and the omp parallelization of foralls works worse
> than for do loops.
I was reading around and it seems that, in most compilers, workshare is
simply implemented as single... :-(
> >> If you want to improve code performance you have to test it, at least
> >> with a two different compilers.
Are there any default performance test cases for octopus?
More information about the Octopus-devel