[petsc-dev] Possible bugs when using TS with ViennaCL

Karl Rupp rupp at mcs.anl.gov
Wed Jan 29 07:28:31 CST 2014


>>> Mani's build included
>>> --with-threadcomm --with-pthreadclasses --with-openmp
>>> which seems the be the cause of the problem. Without these flags,  the
>>> problem disappears and results are correct. If I remember correctly,
>>> this is a more fundamental problem in threadcomm rather than specific to
>>> the ViennaCL bindings, yet we clearly need to fix it.
>> [repost from petsc-maint]
>> Evidently threads are a liability right now.  Do you know what caused
>> this behavior so we can avoid it in the future?
> Unfortunately I don't know what exactly is causing the problem. My best
> guess is that one of the sys-calls inside threadcomm is in conflict with
> the internals of the OpenCL runtime. I'll see whether I can reproduce
> this on my machine, then I can incrementally disable parts of threadcomm
> until I found the cause.

Okay, I could reproduce this problem on my machine: A configuration 
  --with-threadcomm --with-pthreadclasses --with-openmp
fails, while
  --with-threadcomm --with-pthreadclasses
works. Note that all runs are single-threaded, so it is only the 
presence of -fopenmp which screws things up. The most immediate 'fix' is 
to prevent the combination of OpenMP and OpenCL at the configure stage. 
The problem does not show up in a fresh build with CUDA and CUSP, at 
least not when using the standard ComputeResidual() based on VecGetArray().

Best regards,

More information about the petsc-dev mailing list