January 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] IMP prototype
by Jed Brown 02 Jan '14

02 Jan '14

Victor Eijkhout <eijkhout(a)tacc.utexas.edu> writes: > On Jan 2, 2014, at 10:50 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> I find simple demonstrations as unconvincing as most patents. 99% of >> the work remains in extending the idea into something practical. It may >> or may not pan out, but we can't say anything from the simple >> demonstration alone. > > Maybe you and I disagree on what I'm demonstrating. My goal was to > show that my notion of parallelism generalizes MPI & tasking > notions. Not that I have a better notation for VecScatters. My impression is that your transformation is recognizing a common pattern of communication into temporary buffers, followed by computation, followed by post-communication and putting a declarative syntax on it (with callbacks for the computation). The same operations can also be written imperatively and I'm not seeing the profound advantage of converting to your callback system. > And from this demonstration we can definitely say something: namely > that I've shown how one API can address multiple types of > parallelism. That's more than any other system I know of. There are systems like AMPI that run MPI programs on top of threads, and the MPI implementations already optimize shared-memory communication. If you want separate work buffers per thread, those systems will give you a single abstraction. But the reason people want native interfaces to threads is so that they can use large shared data structures and techniques like cooperative prefetch. Your abstraction is not uniform if you need to index into owned parts of shared data structures or perform optimizations like cooperative prefetch. If you're going to use separate buffers, why is a system like MPI not sufficient? What semantic does your abstraction provide for hybrid distributed/shared memory that imperative communication systems cannot? > But let's be constructive: I want to use this demonstration to get > funding. NSF/DOE/Darpa, I don't know. Now if you can't say anything > from this simple demonstration, then what would convince you as a > reviewer? Make a precise and concrete (falsifiable) statement about what semantic your system can provide that others cannot. Show examples that are hard to express with existing solutions (such as MPI), but are cleanly represented by your system. Be fair and show examples of the converse if they exist (silver bullets are rare). >> another layer of callbacks > > If you have mentioned that objection before it escaped my attention. See earlier message on "Callback Hell". > Yes, I agree that in that respect (which has little to do with the > parallelism part) my demonstration is not optimal. The unification of > MPI & tasks is going too far there. For MPI it would be possible to > have calls like VecScatterBegin/End and instead of a callback just > have the local node code in place. For task models that is not > possible (afaik). See for instance Quark, where each task contains a > function pointer and a few data pointers. Quark does this because it is a dynamic scheduler. (When people compare, static schedules are usually as good or better, though if the dependency graph changes from run to run, you may still want to write it as a DAG and have callbacks.) But your model is not a general DAG and the execution model is BSP so it's not clear what is gained by switching to callbacks.

1 0

Re: [petsc-dev] IMP prototype
by Victor Eijkhout 02 Jan '14

02 Jan '14

On Jan 2, 2014, at 10:50 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > I find simple demonstrations as unconvincing as most patents. 99% of > the work remains in extending the idea into something practical. It may > or may not pan out, but we can't say anything from the simple > demonstration alone. Maybe you and I disagree on what I'm demonstrating. My goal was to show that my notion of parallelism generalizes MPI & tasking notions. Not that I have a better notation for VecScatters. And from this demonstration we can definitely say something: namely that I've shown how one API can address multiple types of parallelism. That's more than any other system I know of. The most interesting question to me is if I can do heterogeneity. There I have to wave my hands somewhat vigorously. But let's be constructive: I want to use this demonstration to get funding. NSF/DOE/Darpa, I don't know. Now if you can't say anything from this simple demonstration, then what would convince you as a reviewer? > another layer of callbacks If you have mentioned that objection before it escaped my attention. Yes, I agree that in that respect (which has little to do with the parallelism part) my demonstration is not optimal. The unification of MPI & tasks is going too far there. For MPI it would be possible to have calls like VecScatterBegin/End and instead of a callback just have the local node code in place. For task models that is not possible (afaik). See for instance Quark, where each task contains a function pointer and a few data pointers. Victor. -- Victor Eijkhout, 512 471 5809 (w) Texas Advanced Computing Center, The University of Texas at Austin

1 0

Re: [petsc-dev] get rid of petscsys.hh?
by Jed Brown 02 Jan '14

02 Jan '14

Barry Smith <barryfsmith(a)me.com> writes: > How about just embedding the information directly into the petscsys.h > file and putting a comment explaining its purpose I'd much rather have err.c include <sstream> than petscsys.h.

1 0

Re: [petsc-dev] IMP prototype
by Jed Brown 02 Jan '14

02 Jan '14

Victor Eijkhout <eijkhout(a)tacc.utexas.edu> writes: > On Jan 2, 2014, at 10:03 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> only for > > Look, it's a demonstration prototype. The shift syntax handles one > case. For other cases you need a different syntax or extend the > current. Then the proposal is for something else. The distinguishing feature of successful programming abstractions is never one of making easy things pretty. There are many ways to do that, just as there are many ways to solve a homogeneous Laplacian. A successful abstraction needs to make hard things possible. As stated earlier, my principle reservation with IMP is that adding another layer of callbacks has a long track record of being more difficult to reason about, and I'm far from convinced that it makes the model more expressive. The syntax for describing distributions is a distraction (syntax usually is), but the semantics matter. Two-sided descriptions are a usability problem, but a performance benefit. If IMP turns out not to be suitable for a particular use case, transforming from callback-driven to non-callback is a nontrivial refactoring, as is going the other direction. That's not good because it increases the overhead of incremental adoption. I find simple demonstrations as unconvincing as most patents. 99% of the work remains in extending the idea into something practical. It may or may not pan out, but we can't say anything from the simple demonstration alone.

1 0

Re: [petsc-dev] get rid of petscsys.hh?
by Barry Smith 02 Jan '14

02 Jan '14

How about just embedding the information directly into the petscsys.h file and putting a comment explaining its purpose > On Jan 2, 2014, at 10:10 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > >> On Wed, Jan 1, 2014 at 2:10 PM, Barry Smith <barryfsmith(a)me.com> wrote: >> >> Matt, >> >> You removed petscsys.hh but also need to remove its dependencies > > I don't think we can remove this. I fixed the include. > > Matt > >> CXX arch-pylith-gcc-opt/obj/src/sys/error/err.o >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c: In function 'void PetscCxxErrorThrow()': >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:304:5: error: 'ostringstream' is not a member of 'std' >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc >> /petsc-pylith/binaries/src/sys/error/err.c:304:25: error: 'msg' was not declared in this scope >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:12: error: 'ostringstream' is not a member of 'std' >> >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:31: error: expected primary-expression before ')' token >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:33: error: expected ';' before 'eh' >> /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:309:9: error: 'PETSc' has not been declared >> make[2]: *** [arch-pylith-gcc-opt/obj/src/sys/error/err.o] Error 1 >> >> On Dec 26, 2013, at 2:59 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> > On Thu, Dec 26, 2013 at 2:41 PM, Barry Smith <barryfsmith(a)me.com> wrote: >> > >> > >> > Can we get rid of petscsys.hh which still? seems to be lurking in master? >> > >> > I will get rid of it. >> > >> > Matt >> > >> > Thanks >> > >> > Barry >> > >> > /* Special support for C++ */ >> > #if defined(PETSC_CLANGUAGE_CXX) && defined(__cplusplus) >> > #include <petscsys.hh> >> > #endif >> > >> > >> > >> > >> > >> > >> > -- >> > 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 > > > > -- > 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

1 0

Re: [petsc-dev] IMP prototype
by Victor Eijkhout 02 Jan '14

02 Jan '14

On Jan 2, 2014, at 10:03 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > only for Look, it's a demonstration prototype. The shift syntax handles one case. For other cases you need a different syntax or extend the current. Victor. -- Victor Eijkhout, 512 471 5809 (w) Texas Advanced Computing Center, The University of Texas at Austin

1 0

Re: [petsc-dev] get rid of petscsys.hh?
by Matthew Knepley 02 Jan '14

02 Jan '14

On Wed, Jan 1, 2014 at 2:10 PM, Barry Smith <barryfsmith(a)me.com> wrote: > > Matt, > > You removed petscsys.hh but also need to remove its dependencies > I don't think we can remove this. I fixed the include. Matt > CXX arch-pylith-gcc-opt/obj/src/sys/error/err.o > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c: > In function 'void PetscCxxErrorThrow()': > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:304:5: > error: 'ostringstream' is not a member of 'std' > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc > /petsc-pylith/binaries/src/sys/error/err.c:304:25: error: 'msg' was not > declared in this scope > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:12: > error: 'ostringstream' is not a member of 'std' > > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:31: > error: expected primary-expression before ')' token > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:33: > error: expected ';' before 'eh' > /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:309:9: > error: 'PETSc' has not been declared > make[2]: *** [arch-pylith-gcc-opt/obj/src/sys/error/err.o] Error 1 > > On Dec 26, 2013, at 2:59 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > On Thu, Dec 26, 2013 at 2:41 PM, Barry Smith <barryfsmith(a)me.com> wrote: > > > > > > Can we get rid of petscsys.hh which still? seems to be lurking in > master? > > > > I will get rid of it. > > > > Matt > > > > Thanks > > > > Barry > > > > /* Special support for C++ */ > > #if defined(PETSC_CLANGUAGE_CXX) && defined(__cplusplus) > > #include <petscsys.hh> > > #endif > > > > > > > > > > > > > > -- > > 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 > > -- 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

1 0

Re: [petsc-dev] IMP prototype
by Jed Brown 02 Jan '14

02 Jan '14

Victor Eijkhout <eijkhout(a)tacc.utexas.edu> writes: > On Dec 31, 2013, at 3:10 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> Hmm, I don't really see the API for specifying the distributions. >> rightshift->operate(">>1") is a pretty special-purpose interface. >> Presumably this part is non-collective, > > No, it's collective. As I argue in section 1.1, I want sequential > semantics. Okay, but surely a more general interface for describing the distribution must involve setting non-collectively (at least the data is not collective, so you'll have to build the two-sided representation). > It's actually not all that special purpose. The shift notation is > enough if you have stencils with offsets that are constant during > program execution. Uh, only for structured grids, and for multiple dimensions, you either need this communication abstraction to know about multi-dimensional layout (essentially putting DMDA inside VecScatter) or you can't use the shift notation. > And you did read section 2.3, right? Yeah, it's cute but limited and IMO, not very useful in practice.

1 0

Re: [petsc-dev] adding Report Typo and Errors link to manual pages
by Barry Smith 01 Jan '14

01 Jan '14

Satish, Resending this. Should be really straightforward, please let me know if there are difficulties in getting this done soon. Thanks Barry Request-assigned: balay add Report Typos and Errors link to all manual pages On Dec 10, 2013, at 11:11 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Satish, > > Please add to the generation of all manual pages (in the upper right corner) a Report Typos and Errors link using mailto: For example something like > > <a href=“mailto:[email protected]?subject=Typo or Error in MANUALPAGE &body=Please describe the typo or error in the manual page">Report Typos and Errors</a> > > where MANUALPAGE is the name of that generated manual page. > > Thanks > > Barry >

1 0

Re: [petsc-dev] get rid of petscsys.hh?
by Barry Smith 01 Jan '14

01 Jan '14

Matt, You removed petscsys.hh but also need to remove its dependencies CXX arch-pylith-gcc-opt/obj/src/sys/error/err.o /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c: In function 'void PetscCxxErrorThrow()': /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:304:5: error: 'ostringstream' is not a member of 'std' /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc /petsc-pylith/binaries/src/sys/error/err.c:304:25: error: 'msg' was not declared in this scope /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:12: error: 'ostringstream' is not a member of 'std' /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:31: error: expected primary-expression before ')' token /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:305:33: error: expected ';' before 'eh' /Users/buildbot/slave/build/pylith_darwin_10.6_binbot/PETSc/petsc-pylith/binaries/src/sys/error/err.c:309:9: error: 'PETSc' has not been declared make[2]: *** [arch-pylith-gcc-opt/obj/src/sys/error/err.o] Error 1 On Dec 26, 2013, at 2:59 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Thu, Dec 26, 2013 at 2:41 PM, Barry Smith <barryfsmith(a)me.com> wrote: > > > Can we get rid of petscsys.hh which still? seems to be lurking in master? > > I will get rid of it. > > Matt > > Thanks > > Barry > > /* Special support for C++ */ > #if defined(PETSC_CLANGUAGE_CXX) && defined(__cplusplus) > #include <petscsys.hh> > #endif > > > > > > > -- > 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

1 0