Hi Gordon / @GordonBGood — Thanks for clarifying that your timings were taken using a Cygwin-based installation and CHPL_TASKS=fifo. Though I'd seen the note about Cygwin being an option in the original article, it hadn't occurred to me that it was the platform for your performance studies. Knowing that now, the main message I'd like to convey to anyone introduced to Chapel through this article is that running Chapel using fifo + cygwin is not representative of the performance Chapel is capable of delivering (where qthreads + native Unix-like platforms has been my team's primary performance focus).
In more detail: CHPL_TASKS=`fifo` will almost certainly result in performance overheads relative to CHPL_TASKS=`qthreads`. The fifo option is intended primarily for portability and simplicity, essentially taking the approach of using a POSIX thread per Chapel task. It also has not received much attention from us in terms of performance tuning and optimization. In contrast, qthreads multiplexes tasks across user-level threads and has received a lot more attention in terms of performance analysis and tuning (both by the Qthreads team and by our team in terms of how Chapel maps down to it). By nature, it is also more complex / less portable. The following issue details some of the challenges we've encountered when trying to use Qthreads with Cygwin: [https://github.com/Qthreads/qthreads/issues/49](https://github.com/Qthreads/qthreads/issues/49) That said, in our experience, Cygwin itself also incurs a lot of overhead relative to a native installation of Chapel, so it's hard to say how much of the poor performance you observed was due to fifo as opposed to Cygwin overheads. Like fifo, we've similarly thought of Cygwin as being a portability option rather than a performance-oriented one. And, since Windows 10 introduced Linux Bash Shell / Windows Subsystem for Linux, that's been the preferred mode for using Chapel on Windows (though admittedly, it also hasn't received performance-related attention from our team; given our focus on scalable and scientific computing, Unix-like systems have received the vast majority of our attention). This exchange has made me realize that our Cygwin documentation doesn't really include performance disclaimers, nor a mention of WSL being the current preferred alternative for Windows users, so I've opened an issue on our repo to capture that task: [https://github.com/chapel-lang/chapel/issues/15864](https://github.com/chapel-lang/chapel/issues/15864) Every few years, someone expresses interest in a native Windows port of Chapel (i.e., one that doesn't even require using WSL), but to date, there hasn't been sufficient interest to justify our putting in the effort, arguably reflecting Cray's supercomputing-focused markets and user bases. As an open-source project, we'd be happy to help provide support for someone external interested in pursuing such a port. Again, thanks again for clarifying your experimental setup for us. With respect to the performance of our hash tables / associative domains and arrays, this is admittedly another area that has not received much performance focus in our work to date compared to dense rectangular arrays. But unlike fifo and cygwin, it is an area where we intend to invest more effort. For example, members of the team have recently been working on refactoring the existing code with an eye toward improving it (e.g., [https://github.com/chapel-lang/chapel/pull/15739)](https://github.com/chapel-lang/chapel/pull/15739\)), and open-source developers have also been developing improved hash table implementations (e.g., [https://github.com/chapel-lang/chapel/pull/14409)](https://github.com/chapel-lang/chapel/pull/14409\)). Best wishes, -Brad| ---|---
