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

Re: [petsc-dev] getting rid of the sys/shell directory?
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 9:50 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > How hard will it be to get rid of the sys/shell directory? All that code > that needs to be constantly updated with Jed's crazy schemes is driving me > nuts. Nothing in PETSc uses it: $ git grep -l PetscShell include/petscshell.h include/petscsys.h src/sys/classes/viewer/interface/dlregispetsc.c src/sys/shell/examples/tests/test1.c src/sys/shell/examples/tests/testcomponents1.c src/sys/shell/examples/tests/testcomponents2.c src/sys/shell/examples/tutorials/ex1.c src/sys/shell/interface/sysshell.c

1 0

Re: [petsc-dev] getting rid of the sys/shell directory?
by Dmitry Karpeev 12 Feb '13

12 Feb '13

I'll remove it. Dmitry On Feb 12, 2013 9:50 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > How hard will it be to get rid of the sys/shell directory? All that > code that needs to be constantly updated with Jed's crazy schemes is > driving me nuts. > > Barry > >

1 0

Re: [petsc-dev] [petsc-maint #152223] [PATCH 1/2] Remove dependence of petscvec.h on vecimpl.h while still providing fast VecGetArray
by Barry Smith 12 Feb '13

12 Feb '13

I have added PetscObjectComm() and used it 2531 times in the PETSc source. I have not yet added any code to deal with MPI_COMM_NULL yet. Barry On Feb 12, 2013, at 5:39 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Feb 12, 2013 at 5:32 PM, Matthew Knepley <petsc-maint(a)mcs.anl.gov> wrote: > > I also think including the impl is a bad option. I think the default should be an Object (yes, > > I am advocating changing the interface again), and SETERRC() would take a comm. > > I had suggested MPI_Comm PetscObjectGetComm(PetscObject) that can be called inside the SETERRQ() thing, is not an issue for performance since it is called only for error processing. For some reason it was silently rejected. > > I thought it violated the Style Guide :) > > Should we name this non-error-checking thing PetscObjectComm() (returning MPI_COMM_NULL if passed invalid input) and leave the error-checking PetscObjectGetComm() for existing users and any time it's convenient to use? Or is it too confusing to have two ways to access the comm?

1 0

getting rid of the sys/shell directory?
by Barry Smith 12 Feb '13

12 Feb '13

How hard will it be to get rid of the sys/shell directory? All that code that needs to be constantly updated with Jed's crazy schemes is driving me nuts. Barry

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Shri 12 Feb '13

12 Feb '13

On Feb 12, 2013, at 7:43 PM, Karl Rupp wrote: > Hi Jed, > > > Which crossover are you referring to? The CPU versus GTX285 at >> about 20k >> dofs, but with only very small gains for another order of magnitude? >> >> >> I assume it's the cross-over of Xeon Phi vs. Xeon, >> >> >> MIC is slower than Xeon by more than an order of magnitude at 10k dofs. > > Tim was referring to the cross-over at >10k... > > >> but almost all cross-overs happen in the 10k-100k region and are due >> to PCI-Express latency. >> >> >> Why is PCI-Express latency important here? Can't the MIC code run >> entirely on the device? > > Almost-all (OpenCL, CUDA). Native mode ought to be the exception, but it's the OpenMP overhead which limits then. Single-core on the MIC is not really an option either... > > It would be interesting to play with a pthreads-threadpool implementation on the MIC to see how much performance can really be obtained for smallish problems. You can try running the example threadcomm/examples/tutorials/ex5.c. It gives a measure of the overhead in launching kernels with OpenMP and pthread. > > Best regards, > Karli >

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Karl Rupp 12 Feb '13

12 Feb '13

Hey, > Almost-all (OpenCL, CUDA). Native mode ought to be the exception, > but it's the OpenMP overhead which limits then. Single-core on the > MIC is not really an option either... > > It would be interesting to play with a pthreads-threadpool > implementation on the MIC to see how much performance can really be > obtained for smallish problems. > > > Yup, I'd like to experiment with this. Do you have a device on a > convenient development machine? I only have access to one of the Xlab machines equipped with two Xeon Phi boards running CentOS. It's mostly/occasionally used by the OS hackers from MCS, so it's hardly ever loaded. Also, everybody gets root access. If that fits your expectations, let me know. Best regards, Karli

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 7:43 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Tim was referring to the cross-over at >10k... > Okay, but 10k is more than an order of magnitude away from a crossover with MIC. > Almost-all (OpenCL, CUDA). Native mode ought to be the exception, but it's > the OpenMP overhead which limits then. Single-core on the MIC is not really > an option either... > > It would be interesting to play with a pthreads-threadpool implementation > on the MIC to see how much performance can really be obtained for smallish > problems. > Yup, I'd like to experiment with this. Do you have a device on a convenient development machine?

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Karl Rupp 12 Feb '13

12 Feb '13

Hi Jed, > Which crossover are you referring to? The CPU versus GTX285 at > about 20k > dofs, but with only very small gains for another order of magnitude? > > > I assume it's the cross-over of Xeon Phi vs. Xeon, > > > MIC is slower than Xeon by more than an order of magnitude at 10k dofs. Tim was referring to the cross-over at >10k... > but almost all cross-overs happen in the 10k-100k region and are due > to PCI-Express latency. > > > Why is PCI-Express latency important here? Can't the MIC code run > entirely on the device? Almost-all (OpenCL, CUDA). Native mode ought to be the exception, but it's the OpenMP overhead which limits then. Single-core on the MIC is not really an option either... It would be interesting to play with a pthreads-threadpool implementation on the MIC to see how much performance can really be obtained for smallish problems. Best regards, Karli

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 7:09 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Which crossover are you referring to? The CPU versus GTX285 at about 20k >> dofs, but with only very small gains for another order of magnitude? >> > > I assume it's the cross-over of Xeon Phi vs. Xeon, MIC is slower than Xeon by more than an order of magnitude at 10k dofs. > but almost all cross-overs happen in the 10k-100k region and are due to > PCI-Express latency. Why is PCI-Express latency important here? Can't the MIC code run entirely on the device? > Scaling this to large clusters, replace Xeon Phi by compute node, > PCI-Express by GB-Ethernet/Infiniband as well as change the timescale a bit > and you're probably not too far off... >

1 0

Re: [petsc-dev] pointing out raw pointer in CUSPARRAY
by Jed Brown 12 Feb '13

12 Feb '13

On Tue, Feb 12, 2013 at 7:06 PM, Pilhwa Lee <leep(a)cims.nyu.edu> wrote: > Are they device pointers? Do I need to use host pointers? I'd like to > write a vector in Silo file format. Thanks. Use VecGetArray()

1 0