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=gnuugniqthr...

[4]: https://github.com/sourceryinstitute/PAW/raw/gh-pages/PAW-AT...

[5]: https://chapel-lang.org/releaseNotes/1.20/06-perf-opt.pdf [6]: https://chapel-lang.org/releaseNotes/1.19/05-benchmark-opts.... [7]: https://chapel-lang.org/releaseNotes.html