[petsc-dev] fork for programming models debate (was "Using multiple mallocs with PETSc")

[Matthew Knepley]

On Tue, Mar 14, 2017 at 10:52 PM, Jed Brown <jed at jedbrown.org> wrote:

> Jeff Hammond <jeff.science at gmail.com> writes:
>
> > On Mon, Mar 13, 2017 at 8:08 PM, Jed Brown <jed at jedbrown.org> wrote:
> >>
> >> Jeff Hammond <jeff.science at gmail.com> writes:
> >>
> >> > OpenMP did not prevent OpenCL,
> >>
> >> This programming model isn't really intended for architectures with
> >> persistent caches.
> >>
> >
> > It's not clear to me how much this should matter in a good
> implementation.
> > The lack of implementation effort for OpenCL on cache-coherent CPU
> > architectures appears to be a more significant issue.
>
> How do you keep data resident in cache between kernel launches?
>
> >> > C11, C++11
> >>
> >> These are basically pthreads, which predates OpenMP.
> >>
> >
> > I'm not sure why it matters which one came first.  POSIX standardized
> > threads in 1995, while OpenMP was first standardized in 1997.  However,
> the
> > first serious Pthreads implementation in Linux was in 2003.
>
> And the first serious OpenMP on OS X was when?
>
> > OpenMP standardized the best practices identified in Kuck, SGI and
> > Cray directives, just like POSIX presumably standardized best
> > practices in OS threads from various Unix implementations.
> >
> > C++11 and beyond have concurrency features beyond just threads.  You
> > probably hate all of them because they are C++, and in any case I won't
> > argue, because I don't see anything that's implemented better
> >
> >>
> >> > or Fortran 2008
> >>
> >> A different language and doesn't play well with others.
> >>
> >
> > Sure, but you could use Fortran 2003 features to interoperate between C
> and
> > Fortran if you wanted to leverage Fortran 2008 concurrency features in an
> > ISO-compliant way.  I'm not suggesting you want to do this, but I dispute
> > the suggestion that Fortran does not play nice with C.
>
> I think the above qualifies as not playing nicely in this context.
>
> > Fortran coarrays images are OS processes in every implementation I know,
> > although the standard does not explicitly require this implementation.
> The
> > situation is identical to that of MPI, although there are actually MPI
> > implementations based upon OS threads rather than OS processes (and they
> > require compiler or OS magic to deal with non-heap data).
> >
> > Both of the widely available Fortran coarray implementations use MPI-3
> RMA
> > under the hood and all of the ones I know about define an image to be an
> OS
> > process.
>
> Are you trying to sell PETSc on MPI?
>
> >> > from introducing parallelism. Not sure if your comment was meant to be
> >> > serious,
> >>
> >> Partially.  It was just enough to give the appearance of a solution
> >> while not really being a solution.
> >>
> >
> > It still isn't clear what you actually want.  You appear to reject every
> > standard API for enabling explicit vectorization for CPU execution
> > (Fortran, OpenMP, OpenCL), which suggests that (1) you do not believe in
> > vectorization, (2) you think that autovectorizing compilers are
> sufficient,
> > (3) you think vector code is necessarily a non-portable software
> construct,
> > or (4) you do not think vectorization is relevant to PETSc.
>
> OpenMP is strictly about vectorization with nothing to do with threads
> and MPI is sufficient?  I don't have a problem with that, but will
> probably stick to attributes and intrinsics instead of omp simd, at
>

1) and 4) are clearly wrong. After decades of work, 2) seems practically
wrong.

This looks like a 3) answer to me, and its hard to argue. OpenCL could have
been a nice
way to get arch-independent vectorization, but the implementations suck
badly.


> least until it matures and demonstrates feature parity.
>
> Have you tried writing a BLIS microkernel using omp simd?  Is it any
> good?
>

Yep.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170315/52db3282/attachment.html>