The second one should absolutely be slower than the first (because it
actually iterations through the indices you pass in with an indirection) and
the first should not get slower the more you run it.
Depending on your environment I recommend you using a profiling tool on the
code and look at where it is spending its time within VecAXPY. The basic
Linux/Unix profiling tool is gprof, but you can use Instruments on macOS (part
of Xcode) or Intel's vtune if you have that.
You can also try a different BLAS to see if that matters. For example
--download-fblaslapack or don't use MKL if you are using it.
Barry
> On Jan 6, 2017, at 4:31 PM, Łukasz Kasza <[email protected]> wrote:
>
>
>
> Dear PETSc Users,
>
> Please consider the following 2 snippets which do exactly the same
> (calculate a sum of two vectors):
> 1.
> VecAXPY(amg_level_x[level],1.0,amg_level_residuals[level]);
>
> 2.
> VecGetArray(amg_level_residuals[level], &values);
> VecSetValues(amg_level_x[level],size,indices,values,ADD_VALUES);
> VecRestoreArray(amg_level_residuals[level], &values);
> VecAssemblyBegin(amg_level_x[level]);
> VecAssemblyEnd(amg_level_x[level]);
>
> In my program I have both of the snippets executed in a loop. The problem
> with the first one is that the longer the program goes the longer it takes to
> execute it. At the same time the execution time of the second snippet is more
> or less constant. I don't know why but after a few hundreds of iterations
> VecAXPY takes more than MatMult on the matrix and vector of the same size and
> after that it still grows! Always returning a correct value though. I am
> using 4.5.3 version, the vectors are
> sequential. VecAXPY in such case is just a wrapper for blas, do you have any
> idea why the execution time of this function constantly grows?
>
> Best regards.
>
>
