12 ms·

The Chapel Parallel Programming Language

137 points by wuschel 7y ago

dang 7y ago
Related from 2016: https://news.ycombinator.com/item?id=11747709 https://news.ycombinator.com/item?id=11747709 2014: https://news.ycombinator.com/item?id=7951706 https://news.ycombinator.com/item?id=7951706 A bit from 2013: https://news.ycombinator.com/item?id=5047197 https://news.ycombinator.com/item?id=5047197 A bit from 2016: https://news.ycombinator.com/item?id=11257792 https://news.ycombinator.com/item?id=11257792 Various mentions over the years: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=cray%20chapel&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
blondin 7y ago
really love the syntax of this language and how they are repurposing existing programming language primitives for parallelism. but i also just spent quite some time looking for a substantial example of usage and had to give up. the only thing close to that are the unit tests. and the language has been in development since late 2011. that's somehow dispiriting. that, in a nutshell, is the unfortunate situation with some of these interesting modern programming languages.
- cultus 7y ago
  I never understand why people go to all this work of developing and even marketing major libraries or languages if you aren't going to at least give some doc examples. Jeez, just copy and paste some unit tests and put some prose explanation in. It doesn't take long.
  - kick 7y ago
    Why does Cray need you to use their programming language? The people who need it will seek it out, and Cray probably doesn't mind that people unwilling to spend a minute clicking on 'browse sample programs' or similar won't be trying out their language.
  - zentiggr 7y ago
    You missed the "HPC" acronym. If you're not in the market to run supercomuting projects, you'll likely never use this language. If you are, there's a very high chance you know about it already. Sharp divide between those sides.
    - ken 7y ago
      And yet, in the presentation slides linked to from their homepage, they brag that it aims to be "programmable as Python, fast as Fortran, scalable as MPI, SHMEM, or UPC, portable as C, flexible as C++, fun as [your favorite programming language]". It's not even supercomputer-specific: they say it runs on "a Mac laptop". If even half of those are true, why wouldn't I want to use it for every program I write? (Easy answer: it looks like most of those are still simply "aims", and not actually that close to being true.)
      - bradcray 7y ago
        I think it's plausible you would want to use Chapel for every program you write. I definitely want to use it for every program I write, but I'm also biased. The main disincentive to doing so today is that Chapel is not nearly as broadly adopted or well-supported as the languages you probably do use in practice today. The Chapel team is trying to get it to that point, but it's a modest-sized team taking on large challenges (both technical and social, as this thread indicates). To date, we haven't made a significant effort to draw in a massive/mainstream audience because we know we're not ready for it yet, either in terms of the language's maturity or our ability to support a large group of users. But we hope and intend to get there. That said, I think we're already achieving the aims in the slide you quote—far more than your easy answer suggests—though there's obviously room for differences of opinion (e.g., what does it really mean to be "as programmable as Python?"). If you're interested in pointers to supporting details, let me know.
        zentiggr 7y ago
        I forget that many of the people and projects that get mentioned here are here as well. Thanks for a deeper viewpoint! I'll definitely put Chapel on my curious list.
- bradcray 7y ago
  Arkouda [1], [2] is a recent and substantial example use of Chapel. It's a Python package that supports a subset of NumPy operations on distributed Terabyte-scale arrays implemented using a server written in Chapel. It currently involves ~10k lines of Chapel code. Other recent notable examples include using Chapel for Dark Matter simulations [3], tree-based search algorithms [4], and CFD simulations (to appear at CHIUW 2020 [5]). Your point is taken that the Chapel webpage could be better at pointing to such examples via a "powered by Chapel" section or the like. [1]: http://www.clsac.org/uploads/5/0/6/3/50633811/2019-reus-arkuda.pdf http://www.clsac.org/uploads/5/0/6/3/50633811/2019-reus-arku... [2]: https://chapel-lang.org/presentations/ArkoudaForPuPPy-presented.pdf https://chapel-lang.org/presentations/ArkoudaForPuPPy-presen... [3]: https://github.com/mhmerrill/arkouda https://github.com/mhmerrill/arkouda [3]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-ATM19/presentations/PAW-ATM2019_talk3.pdf https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT... [4]: https://link.springer.com/chapter/10.1007%2F978-3-030-22734-0_19 https://link.springer.com/chapter/10.1007%2F978-3-030-22734-... [5]: https://chapel-lang.org/CHIUW2020.html https://chapel-lang.org/CHIUW2020.html
eyegor 7y ago
Why do so few of these small programming language projects have a "why x?" section? How do they expect to gain marketshare if they aren't frontloading their value? This is a fairly old project and yet they've never taken the time to put a sales pitch on their website. In the past 12 years they've added 15 links to their press page [0]. This is a fairly mature project and I have no idea why I should investigate it. I guess it's fine if they never want users, but as someone who's worked in the startup world this sort of thing really gets under my skin. [0] https://chapel-lang.org/press.html https://chapel-lang.org/press.html
- throwqwerty 7y ago
  what are you talking about? it says it right there in literally bold letters on the home page in response to "what" rather than "why": >Chapel is a modern programming language that is... >parallel: contains first-class concepts for concurrent and parallel computation >productive: designed with programmability and performance in mind >portable: runs on laptops, clusters, the cloud, and HPC systems >scalable: supports locality-oriented features for distributed memory systems are you such a literalist you need literally "why? because ..." i have a question for you: why do so many hners jump on the same silly meme over and over again even when it's not accurate?
  - mardifoufs 7y ago
    I guess a better question would why is it better at those things? A lot of languages claim to be all about performance, scalability, productivity and portability. Those are pretty much what every mainstream language aims for. So why would this be better at those things? Why was it created and what does it do that others can't? I don't think things necessarily need a reason to exist, but I think asking those questions is still relevant when it comes to a programming language. They are mostly tools used to solve problems, after all.
    - bradcray 7y ago
      @mardifoufs: I realize that your point is that the Chapel webpage didn't answer this question clearly / concisely for you and agree that we could and should improve that. The observations in this thread have definitely helped given me insights about how we could position ourselves better for the non-HPC audience (and I already have a longstanding intention to make the code sample on the page more compelling using Asciinema that I need to find the time for). But to answer your specific question here: I'd say that most mainstream languages (e.g., C, C++, C#, Java, Python, Rust, Swift, ...) don't aspire to scalability in the same sense as Chapel and High Performance Computing want it, in the sense of being able to run efficiently on tens of thousands of processors with distributed memory where inter-processor communication and coordination is required. And even when they do aspire to it, it's rarely through the language itself, but through communication libraries, pragmas, and extensions. The result (in my opinion) is rarely as productive, general-purpose, and performant Chapel achieves.
eismcc 7y ago
I’ve worked with Chapel a lot. It’s an insanely powerful language that will challenge your ideas (at least for me) about many language constructs in the spirit of HPC. I went to it around 2014 for doing distributed arm projects and implemented several projects. Here’s a simple search engine. My github had a number of chapel projects. Once you get the hang of Chapel you will find it changes how you think about parallel computing. For more advanced concepts the learning curve is steep and not something you can get in a hello world example, but totally worth the effort. https://github.com/briangu/chearch https://github.com/briangu/chearch
- zentiggr 7y ago
  For us non-HPC developers, does it make any sense to dig deeper? I get the feeling there could be some interesting thread/core usage maximisation ideas, or some such, but I've not delved before so I have no frame of reference.
  - eismcc 7y ago
    I think so. I primarily work in web companies and it’s still interesting.
  - pjmlp 7y ago
    Depends where your main interests in computing are are, if you are into programming languages, it is always worth having a look.
- Abishek_Muthian 7y ago
  Thank you. I've been experimenting lately with multi-architecture distributed computing (ARM <---> x86_64) with frameworks such as dask, ray and although there were quirks in getting them running on ARM; I was able to make it work [1]. I was thinking of checking out Julia's distributed computing capabilities next, but their insistence on same OS, path etc. (last time I checked) didn't inspire confidence in me for my purpose. Would Chapel be a good alternative for multi-architecture distributed computing? My goals are simple, to explore what it takes to distribute & compute something across different architectures in parallel. [1]https://gist.github.com/heavyinfo/aa0bf2feb02aedb3b38eef203b4b8cc4 https://gist.github.com/heavyinfo/aa0bf2feb02aedb3b38eef203b...
fizixer 7y ago
Chapel was one of the three language chosen by DARPA in early 2010s (late 2000s?) to be the potential future of HPC (the other two being Fortress and X10). I think the idea was to fund these languages, allow the developers to throw them at the supercomputers, have a multi-year shoot out, and pick the one that wins out. I'm not sure what happened to the findings/results (feel free to chime in). What I do know is that I've been in the HPC application side for almost 15 years and not one of the big projects I'm involved with use any of these, or any other "new" HPC languages. The go-to languages/frameworks are the same: C/C++/Fortran, combined with OpenMP/MPI (MPI includes networking, but use of separate networking frameworks is also an option), and Cuda for GPUs (maybe very occasional OpenCL), with python being the massive success as the glue between all the system-level languages/frameworks. And now with the advent of tensor computing, the paradigm appears to be shifting once more (maybe not a shift, but one more item in the laundray list of heterogenous hardware). Go read the overview, new features, whatever on the linked Chapel website: not a single mention of GPU. That's cz Chapel/Fortress/X10 were conceived/developed around the time GPGPU was just taking off. Nobody saw GPGPU coming and it has taken the HPC world by storm. And yet, after more than a decade, the "new HPC language" website has zero mention of GPUs. What a shame. I'm not saying the new HPC languages are overrated. But I do believe the promise of an HPC language hasn't panned out, and yet at the same time new computer-architecture/hardware paradigms keep emerging which the "new" HPC languages {were never designed for, never foresaw}.
- auggierose 7y ago
  Same opinion here. Parallel first language, and no GPU support??
  - pjmlp 7y ago
    Many HPC worloads are MPI first, and then something else later. Still there is ongoing GPU support work, see sibling comment.
    - mppf 7y ago
      Right, GPU support is very important to us and we expect to make something satisfying. We just havn't been able to prioritize it yet.
bovine3dom 7y ago
Chapel has great syntax and ergonomics as others have mentioned. What it doesn't currently have is great performance, e.g. [1]. That said, it appears to be heading in the right direction [2]. I last checked about 5 years ago and the story was much worse. [1]: https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASIcs-SLATE-2019-12.pdf https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASI... [2]: https://chapel-lang.org/perf/chapcs/ https://chapel-lang.org/perf/chapcs/
- roknovosel 7y ago
  Wow, never thought I'd see my paper[1] on HN :) Even though getting the right performance was tricky, I was more frustrated with the lack of tooling, sometimes cryptic compiler messages and long compilation times for even mid-sized programs. Most of the issues were mitigated by the great community around Chapel. They are usually very responsive and helpful in their Gitter channel. In regards to actual parallel programming, Chapel was a breeze. Documentation is solid and most of the parallel concepts were easy to use.
- bradcray 7y ago
  Chapel performance has improved by leaps and bounds over the past 5+ years, though link [2] above focuses on single-node performance whereas most the team's recent optimization efforts have been focused on improving distributed memory performance and scalability, some indications of which can be seen at [3]. Of course, it's very possible for programmers without Chapel expertise to write and publish bad performance results in Chapel. The Chapel team is very interested in working with such users to help them understand where performance is being lost and to improve things to benefit future users. Most of our recent optimizations have been motivated by user feedback, and in practice we're typically able to help users get their codes to match or beat the performance of conventional approaches with reduced effort. A favorite recent example of mine can be seen in slides 6-16 of Nikhil Padmanabhan's talk at PAW-ATM 2019 [4]. A good way to keep up with Chapel performance improvements beyond whatever gets peppered into our talks is through the release notes that we publish every six months, e.g. [5], [6], [7]. [3]: https://chapel-lang.org/perf/16-node-xc/?configs=gnuugniqthreads&graphs=hpccraatomicsperfgupsn233,hpccraonperfgupsn233,hpccrarmoperfgupsn233,hpccstreamepperfgbsn5723827200,hpccglobalstreamperfgbsn5723827200,sscassca2kernel4perftepssize2224vertices,prkstencilvariationsperf,isxrelease https://chapel-lang.org/perf/16-node-xc/?configs=gnuugniqthr... [4]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-ATM19/presentations/PAW-ATM2019_talk3.pdf https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT... [5]: https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf [6]: https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.pdf https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.... [7]: https://chapel-lang.org/releaseNotes.html https://chapel-lang.org/releaseNotes.html
fulafel 7y ago
These HPC programming languages (there are others too) would be good candidates for GPU programming, hopefully GPU world will at some point emerge from the C++ dark ages despite all the hinderances (proprietary fragmented SW stacks).
- eismcc 7y ago
  There was GPU support in a branch a long time ago. I think they missed the boat on that and it would have been a great way to get distributed GPU systems even 5yrs ago
  - mppf 7y ago
    GPU support is still really important. We don't see major issues with providing native Chapel -> GPU code generation and hope to work on it soon.

137 points by wuschel 7y ago

dang 7y ago

Related from 2016: https://news.ycombinator.com/item?id=11747709 https://news.ycombinator.com/item?id=11747709 2014: https://news.ycombinator.com/item?id=7951706 https://news.ycombinator.com/item?id=7951706 A bit from 2013: https://news.ycombinator.com/item?id=5047197 https://news.ycombinator.com/item?id=5047197 A bit from 2016: https://news.ycombinator.com/item?id=11257792 https://news.ycombinator.com/item?id=11257792 Various mentions over the years: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=cray%20chapel&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

blondin 7y ago

really love the syntax of this language and how they are repurposing existing programming language primitives for parallelism. but i also just spent quite some time looking for a substantial example of usage and had to give up. the only thing close to that are the unit tests. and the language has been in development since late 2011. that's somehow dispiriting. that, in a nutshell, is the unfortunate situation with some of these interesting modern programming languages.

cultus 7y ago
I never understand why people go to all this work of developing and even marketing major libraries or languages if you aren't going to at least give some doc examples. Jeez, just copy and paste some unit tests and put some prose explanation in. It doesn't take long.
- kick 7y ago
  Why does Cray need you to use their programming language? The people who need it will seek it out, and Cray probably doesn't mind that people unwilling to spend a minute clicking on 'browse sample programs' or similar won't be trying out their language.
- zentiggr 7y ago
  You missed the "HPC" acronym. If you're not in the market to run supercomuting projects, you'll likely never use this language. If you are, there's a very high chance you know about it already. Sharp divide between those sides.
  - ken 7y ago
    And yet, in the presentation slides linked to from their homepage, they brag that it aims to be "programmable as Python, fast as Fortran, scalable as MPI, SHMEM, or UPC, portable as C, flexible as C++, fun as [your favorite programming language]". It's not even supercomputer-specific: they say it runs on "a Mac laptop". If even half of those are true, why wouldn't I want to use it for every program I write? (Easy answer: it looks like most of those are still simply "aims", and not actually that close to being true.)
    - bradcray 7y ago
      I think it's plausible you would want to use Chapel for every program you write. I definitely want to use it for every program I write, but I'm also biased. The main disincentive to doing so today is that Chapel is not nearly as broadly adopted or well-supported as the languages you probably do use in practice today. The Chapel team is trying to get it to that point, but it's a modest-sized team taking on large challenges (both technical and social, as this thread indicates). To date, we haven't made a significant effort to draw in a massive/mainstream audience because we know we're not ready for it yet, either in terms of the language's maturity or our ability to support a large group of users. But we hope and intend to get there. That said, I think we're already achieving the aims in the slide you quote—far more than your easy answer suggests—though there's obviously room for differences of opinion (e.g., what does it really mean to be "as programmable as Python?"). If you're interested in pointers to supporting details, let me know.
      - zentiggr 7y ago
        I forget that many of the people and projects that get mentioned here are here as well. Thanks for a deeper viewpoint! I'll definitely put Chapel on my curious list.
bradcray 7y ago
Arkouda [1], [2] is a recent and substantial example use of Chapel. It's a Python package that supports a subset of NumPy operations on distributed Terabyte-scale arrays implemented using a server written in Chapel. It currently involves ~10k lines of Chapel code. Other recent notable examples include using Chapel for Dark Matter simulations [3], tree-based search algorithms [4], and CFD simulations (to appear at CHIUW 2020 [5]). Your point is taken that the Chapel webpage could be better at pointing to such examples via a "powered by Chapel" section or the like. [1]: http://www.clsac.org/uploads/5/0/6/3/50633811/2019-reus-arkuda.pdf http://www.clsac.org/uploads/5/0/6/3/50633811/2019-reus-arku... [2]: https://chapel-lang.org/presentations/ArkoudaForPuPPy-presented.pdf https://chapel-lang.org/presentations/ArkoudaForPuPPy-presen... [3]: https://github.com/mhmerrill/arkouda https://github.com/mhmerrill/arkouda [3]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-ATM19/presentations/PAW-ATM2019_talk3.pdf https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT... [4]: https://link.springer.com/chapter/10.1007%2F978-3-030-22734-0_19 https://link.springer.com/chapter/10.1007%2F978-3-030-22734-... [5]: https://chapel-lang.org/CHIUW2020.html https://chapel-lang.org/CHIUW2020.html

eyegor 7y ago

Why do so few of these small programming language projects have a "why x?" section? How do they expect to gain marketshare if they aren't frontloading their value? This is a fairly old project and yet they've never taken the time to put a sales pitch on their website. In the past 12 years they've added 15 links to their press page [0]. This is a fairly mature project and I have no idea why I should investigate it. I guess it's fine if they never want users, but as someone who's worked in the startup world this sort of thing really gets under my skin. [0] https://chapel-lang.org/press.html https://chapel-lang.org/press.html

throwqwerty 7y ago
what are you talking about? it says it right there in literally bold letters on the home page in response to "what" rather than "why": >Chapel is a modern programming language that is... >parallel: contains first-class concepts for concurrent and parallel computation >productive: designed with programmability and performance in mind >portable: runs on laptops, clusters, the cloud, and HPC systems >scalable: supports locality-oriented features for distributed memory systems are you such a literalist you need literally "why? because ..." i have a question for you: why do so many hners jump on the same silly meme over and over again even when it's not accurate?
- mardifoufs 7y ago
  I guess a better question would why is it better at those things? A lot of languages claim to be all about performance, scalability, productivity and portability. Those are pretty much what every mainstream language aims for. So why would this be better at those things? Why was it created and what does it do that others can't? I don't think things necessarily need a reason to exist, but I think asking those questions is still relevant when it comes to a programming language. They are mostly tools used to solve problems, after all.
  - bradcray 7y ago
    @mardifoufs: I realize that your point is that the Chapel webpage didn't answer this question clearly / concisely for you and agree that we could and should improve that. The observations in this thread have definitely helped given me insights about how we could position ourselves better for the non-HPC audience (and I already have a longstanding intention to make the code sample on the page more compelling using Asciinema that I need to find the time for). But to answer your specific question here: I'd say that most mainstream languages (e.g., C, C++, C#, Java, Python, Rust, Swift, ...) don't aspire to scalability in the same sense as Chapel and High Performance Computing want it, in the sense of being able to run efficiently on tens of thousands of processors with distributed memory where inter-processor communication and coordination is required. And even when they do aspire to it, it's rarely through the language itself, but through communication libraries, pragmas, and extensions. The result (in my opinion) is rarely as productive, general-purpose, and performant Chapel achieves.

eismcc 7y ago

I’ve worked with Chapel a lot. It’s an insanely powerful language that will challenge your ideas (at least for me) about many language constructs in the spirit of HPC. I went to it around 2014 for doing distributed arm projects and implemented several projects. Here’s a simple search engine. My github had a number of chapel projects. Once you get the hang of Chapel you will find it changes how you think about parallel computing. For more advanced concepts the learning curve is steep and not something you can get in a hello world example, but totally worth the effort. https://github.com/briangu/chearch https://github.com/briangu/chearch

zentiggr 7y ago
For us non-HPC developers, does it make any sense to dig deeper? I get the feeling there could be some interesting thread/core usage maximisation ideas, or some such, but I've not delved before so I have no frame of reference.
- eismcc 7y ago
  I think so. I primarily work in web companies and it’s still interesting.
- pjmlp 7y ago
  Depends where your main interests in computing are are, if you are into programming languages, it is always worth having a look.
Abishek_Muthian 7y ago
Thank you. I've been experimenting lately with multi-architecture distributed computing (ARM <---> x86_64) with frameworks such as dask, ray and although there were quirks in getting them running on ARM; I was able to make it work [1]. I was thinking of checking out Julia's distributed computing capabilities next, but their insistence on same OS, path etc. (last time I checked) didn't inspire confidence in me for my purpose. Would Chapel be a good alternative for multi-architecture distributed computing? My goals are simple, to explore what it takes to distribute & compute something across different architectures in parallel. [1]https://gist.github.com/heavyinfo/aa0bf2feb02aedb3b38eef203b4b8cc4 https://gist.github.com/heavyinfo/aa0bf2feb02aedb3b38eef203b...

fizixer 7y ago

Chapel was one of the three language chosen by DARPA in early 2010s (late 2000s?) to be the potential future of HPC (the other two being Fortress and X10). I think the idea was to fund these languages, allow the developers to throw them at the supercomputers, have a multi-year shoot out, and pick the one that wins out. I'm not sure what happened to the findings/results (feel free to chime in). What I do know is that I've been in the HPC application side for almost 15 years and not one of the big projects I'm involved with use any of these, or any other "new" HPC languages. The go-to languages/frameworks are the same: C/C++/Fortran, combined with OpenMP/MPI (MPI includes networking, but use of separate networking frameworks is also an option), and Cuda for GPUs (maybe very occasional OpenCL), with python being the massive success as the glue between all the system-level languages/frameworks. And now with the advent of tensor computing, the paradigm appears to be shifting once more (maybe not a shift, but one more item in the laundray list of heterogenous hardware). Go read the overview, new features, whatever on the linked Chapel website: not a single mention of GPU. That's cz Chapel/Fortress/X10 were conceived/developed around the time GPGPU was just taking off. Nobody saw GPGPU coming and it has taken the HPC world by storm. And yet, after more than a decade, the "new HPC language" website has zero mention of GPUs. What a shame. I'm not saying the new HPC languages are overrated. But I do believe the promise of an HPC language hasn't panned out, and yet at the same time new computer-architecture/hardware paradigms keep emerging which the "new" HPC languages {were never designed for, never foresaw}.

auggierose 7y ago
Same opinion here. Parallel first language, and no GPU support??
- pjmlp 7y ago
  Many HPC worloads are MPI first, and then something else later. Still there is ongoing GPU support work, see sibling comment.
  - mppf 7y ago
    Right, GPU support is very important to us and we expect to make something satisfying. We just havn't been able to prioritize it yet.

bovine3dom 7y ago

Chapel has great syntax and ergonomics as others have mentioned. What it doesn't currently have is great performance, e.g. [1]. That said, it appears to be heading in the right direction [2]. I last checked about 5 years ago and the story was much worse. [1]: https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASIcs-SLATE-2019-12.pdf https://drops.dagstuhl.de/opus/volltexte/2019/10879/pdf/OASI... [2]: https://chapel-lang.org/perf/chapcs/ https://chapel-lang.org/perf/chapcs/

roknovosel 7y ago
Wow, never thought I'd see my paper[1] on HN :) Even though getting the right performance was tricky, I was more frustrated with the lack of tooling, sometimes cryptic compiler messages and long compilation times for even mid-sized programs. Most of the issues were mitigated by the great community around Chapel. They are usually very responsive and helpful in their Gitter channel. In regards to actual parallel programming, Chapel was a breeze. Documentation is solid and most of the parallel concepts were easy to use.
bradcray 7y ago
Chapel performance has improved by leaps and bounds over the past 5+ years, though link [2] above focuses on single-node performance whereas most the team's recent optimization efforts have been focused on improving distributed memory performance and scalability, some indications of which can be seen at [3]. Of course, it's very possible for programmers without Chapel expertise to write and publish bad performance results in Chapel. The Chapel team is very interested in working with such users to help them understand where performance is being lost and to improve things to benefit future users. Most of our recent optimizations have been motivated by user feedback, and in practice we're typically able to help users get their codes to match or beat the performance of conventional approaches with reduced effort. A favorite recent example of mine can be seen in slides 6-16 of Nikhil Padmanabhan's talk at PAW-ATM 2019 [4]. A good way to keep up with Chapel performance improvements beyond whatever gets peppered into our talks is through the release notes that we publish every six months, e.g. [5], [6], [7]. [3]: https://chapel-lang.org/perf/16-node-xc/?configs=gnuugniqthreads&graphs=hpccraatomicsperfgupsn233,hpccraonperfgupsn233,hpccrarmoperfgupsn233,hpccstreamepperfgbsn5723827200,hpccglobalstreamperfgbsn5723827200,sscassca2kernel4perftepssize2224vertices,prkstencilvariationsperf,isxrelease https://chapel-lang.org/perf/16-node-xc/?configs=gnuugniqthr... [4]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-ATM19/presentations/PAW-ATM2019_talk3.pdf https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT... [5]: https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf [6]: https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.pdf https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.... [7]: https://chapel-lang.org/releaseNotes.html https://chapel-lang.org/releaseNotes.html

fulafel 7y ago

These HPC programming languages (there are others too) would be good candidates for GPU programming, hopefully GPU world will at some point emerge from the C++ dark ages despite all the hinderances (proprietary fragmented SW stacks).

eismcc 7y ago
There was GPU support in a branch a long time ago. I think they missed the boat on that and it would have been a great way to get distributed GPU systems even 5yrs ago
- mppf 7y ago
  GPU support is still really important. We don't see major issues with providing native Chapel -> GPU code generation and hope to work on it soon.