Thanks for the thorough reply Brad. In terms of "next libraries", I would imagine that if you ask 3 people you'd get 4 answers. I imagine that the developers have their hands full. I'm more of a user than a developer..At best, I can let you know things in other languages that I commonly use that would be very important for me transitioning to Chapel. I would imagine others have similar requirements. For instance, when I use python, numpy, scipy, and pandas are a given (R or Matlab I use similar facilities). I often use some kind of database (SQL). I commonly call nlopt from other languages. I would imagine that interoperability with other languages would also make it more likely for people to use Chapel. I see a pyChapel package. This seems like a step in the right direction.
On Thu, Aug 13, 2015 at 8:34 PM, Brad Chamberlain <[email protected]> wrote: > > Hi John -- > > 1) The latest benchmark I can find (also on the Chapel website) is from >> October 2013. It does not show particularly strong performance. I imagine >> that there has been a lot of improvements since then. Are there any more >> recent performance evaluations? >> > > Things have improved a lot since 2013. The best sources for recent > performance results are the release notes that we've been putting together > for the past several releases (so that's an every-six-months report): > > http://chapel.cray.com/download.html#releaseNotes > > Results may appear in various decks for each release, but for the latest > release, most of them appear in the "Performance Optimizationsn and > Generated Code Improvements" deck and the "Benchmarks and Perforamnce > Results" deck. The other place to look for "real-time" data are the > performance graphs that we plot as part of our nightly regression testing: > > http://chapel.sourceforge.net/perf/ > > > 2) Does/will Chapel support SIMD? What about GPUs? >> > > As of version 1.11, Chapel's forall loops code generate for gcc and icc as > loops with vectorization hints that lead to vectorization. We're still in > the process of evaluating how our performance compares to hand-generated C > loops for various idioms (using the LCALS benchmark suite from LLNL), but > we have seen improvements for some cases. You can read more about this > capability in the same performance deck mentioned above, or in Elliot > Ronaghan's CHIUW 2015 talk: > > http://chapel.cray.com/CHIUW2015.html > > On the master branch, we've also recently introduced a vectorizeOnly() > iterator which has the following effect: > > forall i in 1..n // uses multitasking; tries to vectorize > while: > forall i in vectorizeOnly(1..n) // only tries to vectorize > > This will be in the upcoming 1.12 release this fall. > > As for GPUs, Albert Sidelnik at UIUC did some early work on Chapel > execution on GPUs that was captured in an IPDPS paper: > > Performance Portability with the Chapel Language. Albert Sidelnik, > Saeed Maleki, Bradford L. Chamberlain, María J. Garzarán, David > Padua. IPDPS 2012, May 2012. > > but unfortunately this work did not make it back into the master branch. > Enabling GPU support on the master branch is part of future work, but > currently queued up behind good support for Intel Xeon Phi. > > > 3) I see a lot of development, at various stages, on parallel linear >> algebra libraries. For instance, PBLAS, CLBLAS, ScaLAPAK, PLASMA, MAGMA. I >> did some cursory search for Chapel's support for either these libraries >> (like maybe with a wrapper to C or something) or similar functionality >> natively, but I didn't see anything. If this support is available, can you >> direct me to some of it. Alternately, what is the timeline for Chapel to >> have comparable functionality (by whatever means)? >> > > This has become an increasingly common request from users and has become > more of a priority for the team in the past year (support for standard > libraries). One of our interns spent the summer working on creating a > Chapel interface to LAPACK which we expect to be committed to the master > branch this week. An external developer is working on wrapping BLAS and we > hope that will be contributed in time for this fall's release, but it's TBD > (it will show up on master as soon as it is available in any case). You may > have found that we already have wrappers for some key FFTW routines: > > http://chapel.cray.com/docs/latest/modules/standard/FFTW.html > > We're interested in having the community contribute such wrapped libraries > back to the project given the number of them (FFTW was a community > contribution for example), and are continuing to take requests for "next > libraries" to wrap ourselves as reources permit. > > Thanks for your interest in Chapel and please let us know if you have > any further questions, > -Brad >
------------------------------------------------------------------------------
_______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
