February 2013 - petsc-dev - mailman3.cels.anl.gov

Google Summer of Code
by Jed Brown 18 Feb '13

18 Feb '13

This year's program was recently announced. http://www.google-melange.com/gsoc/events/google/gsoc2013 Applications from mentoring organizations have to be received between March 18 and March 29. If we would like PETSc to be a mentoring organization, we should start by sketching a few project ideas. There are a few such projects on this page, but we'd need to collect a few that would be interesting and feasible as a summer project. https://bitbucket.org/petsc/petsc-dev/issues?status=new&status=open

1 0

Re: [petsc-dev] Registration implicitly collective on COMM_WORLD
by Barry Smith 17 Feb '13

17 Feb '13

On Feb 17, 2013, at 12:00 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Feb 5, 2013 at 8:05 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Then we would need to remove the support for [/path/libname[.so.1.0]:]functionname[()] where items in [] denote optional from PetscFunctionListFind() so no more > > -ksp_type /Users/me/libmyksp.so:MyKSPCreate() > > Instead people would need to load the library in one collective call and then call the functionlistfind. > > But I guess that is ok, no body uses this anyways. > > Shall we add PETSC_PLUGIN_PATH and -petsc_plugin list_of:directories:or_libs.so. This would require plugin authors to create registration routines for each shared library, but I think this makes for a better UI anyway. It is ok with me.

1 0

Re: [petsc-dev] Registration implicitly collective on COMM_WORLD
by Jed Brown 17 Feb '13

17 Feb '13

On Tue, Feb 5, 2013 at 8:05 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Then we would need to remove the support for > [/path/libname[.so.1.0]:]functionname[()] where items in [] denote > optional from PetscFunctionListFind() so no more > > -ksp_type /Users/me/libmyksp.so:MyKSPCreate() > > Instead people would need to load the library in one collective call and > then call the functionlistfind. > > But I guess that is ok, no body uses this anyways. > Shall we add PETSC_PLUGIN_PATH and -petsc_plugin list_of:directories:or_libs.so. This would require plugin authors to create registration routines for each shared library, but I think this makes for a better UI anyway.

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Jed Brown 16 Feb '13

16 Feb '13

On Sat, Feb 16, 2013 at 8:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > size_t and friends makes me nervous at _t > Good point, _t means type in way too many contexts. We have used _T in a type macro as well (PETSC_UINTPTR_T, MPIU_SIZE_T, ...). Maybe _K is not so bad after all. > > On Feb 16, 2013, at 8:08 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > > On Sat, Feb 16, 2013 at 7:55 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > _k _t ? > > > > I think I'd prefer _t or _T. The "kernel" mnemonic is more about the > intent of the code that usually goes in such a function than the semantics > of that execution mode. > >

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Barry Smith 16 Feb '13

16 Feb '13

size_t and friends makes me nervous at _t On Feb 16, 2013, at 8:08 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Sat, Feb 16, 2013 at 7:55 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > _k _t ? > > I think I'd prefer _t or _T. The "kernel" mnemonic is more about the intent of the code that usually goes in such a function than the semantics of that execution mode.

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Jed Brown 16 Feb '13

16 Feb '13

On Sat, Feb 16, 2013 at 7:55 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > _k _t ? I think I'd prefer _t or _T. The "kernel" mnemonic is more about the intent of the code that usually goes in such a function than the semantics of that execution mode.

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Barry Smith 16 Feb '13

16 Feb '13

_k _t ? On Feb 16, 2013, at 7:06 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Sat, Feb 16, 2013 at 6:52 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > Still like that better than _r. > > Reentrancy is not a subset or superset of thread-safety. I certainly wasn't suggesting that we use _r to indicate thread-safety. Rather, I was asking whether we should use a shorter (possibly single-character) identifier, and perhaps something that indicated "CPU threads" so as not to confuse with device kernels.

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Jed Brown 16 Feb '13

16 Feb '13

On Sat, Feb 16, 2013 at 6:52 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > Still like that better than _r. Reentrancy is not a subset or superset of thread-safety. I certainly wasn't suggesting that we use _r to indicate thread-safety. Rather, I was asking whether we should use a shorter (possibly single-character) identifier, and perhaps something that indicated "CPU threads" so as not to confuse with device kernels.

1 0

Re: [petsc-dev] Naming for functions that are safe to call from threads
by Matthew Knepley 16 Feb '13

16 Feb '13

On Sat, Feb 16, 2013 at 7:34 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > We've currently been naming functions with FunctionName_kernel, but these > have been very private so far. Some new work will make some of these > sharable (e.g., between matrix classes). > > I've already found cases where _kernel functions call non-kernel > functions, which is definitely broken, so I'd like to adopt a consistent > naming that we can use everywhere, and even selectively open up to users > (e.g., a threaded MatSetValues). > > The C standard library uses funcname_r for reentrant. What convention > should PETSc use. Note that spelling out "_kernel" uses up a lot of > characters if we use it with extern linkage. > Still like that better than _r. 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

1 0

Naming for functions that are safe to call from threads
by Jed Brown 16 Feb '13

16 Feb '13

We've currently been naming functions with FunctionName_kernel, but these have been very private so far. Some new work will make some of these sharable (e.g., between matrix classes). I've already found cases where _kernel functions call non-kernel functions, which is definitely broken, so I'd like to adopt a consistent naming that we can use everywhere, and even selectively open up to users (e.g., a threaded MatSetValues). The C standard library uses funcname_r for reentrant. What convention should PETSc use. Note that spelling out "_kernel" uses up a lot of characters if we use it with extern linkage.

1 0