Thanks Brad, On Mon, 13 Apr 2015, Brad Chamberlain wrote:
> I'm not personally aware of any full-fledged FE/BE/FV codes running in > Chapel. Most users in these communities are taking a "wait and see" > approach with Chapel, waiting for distributed memory performance to > improve before committing a production code to it. Even now, a lot of us probably have access to systems with 24-64 cores and maybe double that. Such systems are good enough to 'kick tyres' for a lot of concepts. not quite in the range of 1000s of cores, but good enough to experiment and still have some code that is quite useful. Also, with stuff like the Knight's Landing Xeon's due (in any volume and outside the US) within 12 months, now is probably as good a time as any to start. The GPU stuff in Chapel looks interesting but I cannot see that this is easily built in the current distribution. I also do not understand enough to inexpensively experiment with say 1 or 2 NVIDIA add-on processors. Maybe somebody from NVIDIA should suggest a platform and a cook-book recipe??? > Meanwhile, we are working hard both to improve performance and to get > Chapel to the point where such groups can put their weight on it without > risk to their projects or progress. I will reply at length to the above. Let me know if long emails should be done offline. > We did have a collaborator at JPL who did an FEM kernel in Chapel in the > very early days when we were sketching out language ideas and wrestling > with what abstractions we should support. Abstractions that work for FE are applicable to lots of other areas of HPC across a wide range of applications and industries. That said, part of the effort involves writing Chapel libraries that can import/export models produced by an easily avaible commercial/open-source preprocessors/postprocessors, i.e. modelling tools. Does not need special Chapel features. > This is an area of the language where we'd be particularly interested in > feedback. The best place to learn about these concepts other than the > language spec is in [test/release/]examples/primers/opaque.chpl and > sparse.chpl: Already looking at those. However, the LULESH benchmark has lots of nice ideas. > https://github.com/chapel-lang/chapel/tree/master/test/release/examples/primers > > The primary artifact I can (easily) find from that early exercise is captured > in slides: > > http://chapel.cray.com/presentations/ChapelForSC09Multicore.pdf > > (see, e.g., slides 44-46). That is what got my interest several years ago. Prior to that, the only clean, easy to read technique what was available with longevity were the features of something like CILK. Even now that Intel has merged this with its own the vector enhancements in Intel's C compiler, and ported it to G++, it arguably only works transparently on CPUs attached to a single system. You are limited 2-4 physical CPUs (unless you can afford an 8-core E7). The HPCC stuff that is available now provides a useful framework from which to start. What recent/current feedback do you have from LLNL? Regards - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
