Right from the start, IBM announced that given our experience seeing the benefits of building apps with Swift and with the move to open source, we would focus on bringing Swift to the Server. To make this possible, our Swift.org efforts have been focused primarily on Concurrency. Enabling concurrency is a critical aspect of server-side programming.

Why concurrency? Fundamentally, concurrency is about allowing multiple computations to happen simultaneously while ensuring that the program still computes the expected answers. On the server, concurrency accelerates programs by exploiting multiple CPU cores, reduces latency by allowing the overlapping of computation with communication, and enables a single server process to handle many simultaneous users.

Why us? The thinking was that our deep expertise in concurrent runtime systems and the Linux operating system would enable us to effectively collaborate with the Swift open source community but also help to resolve some of the technical issue, quickly. Chris, Ian, and I have many years of experience with both enterprise and experimental language runtimes. Hubertus brings deep experience with operating systems and the Linux kernel. We’re all really enjoying the opportunity to work together, with the growing Swift.org community.

What have we all been working on? In Swift, concurrency is expressed by using the APIs of Grand Central Dispatch, Apple’s fundamental library for expressing concurrency on multi-core hardware in iOS and OS X. Grand Central Dispatch provides a set of high-level abstractions for writing concurrent programs based on tasks, serial and concurrent queues, and synchronization operations, such as groups, semaphores and barriers, rather than using an explicit threading model. On iOS and OS X, Grand Central Dispatch is tightly integrated with the operating system kernel to enable it to optimize scheduling and resource management decisions. One of the key technical issues in the port of Grand Central Dispatch to Linux was to bridge the gap between the operating system APIs available on iOS and OS X and those provided by Linux. Fortunately, we were able to leverage two existing open source projects, libkqueue and libpwq, to bridge several of the key API differences.

Within two months of Swift going open source, it is great to see the functional port of Grand Central Dispatch to Linux reaching a level of completeness and stability that it can be used by several early adopters (including the Kitura web framework).

What’s next? The current community focus is on finishing the missing pieces of the Swift APIs to Grand Central Dispatch and to continue optimizing its performance on Linux. In particular, we are working on enabling thread-specific storage to optimize dispatch operations, analyzing the performance and scalability of server-side workloads to identify areas for further enhancements, and investigating the resource management and scheduling decisions being made when executing server work loads.

Whether you are already involved or just thinking about getting started, we hope to see you in the Swift.org developer community. (https://swift.org/)

See you in Swift.org! Cheers, Chris Bailey, Hubertus Franke, David Grove and Ian Partridge

4 comments on"Talking about Swift Concurrency on Linux"

  1. […] Some further attention and care about concurrency […]

  2. Edward Chrzanowski June 24, 2016

    Any progress on Apple swift bindings for MPI and OpenMP?

    • Hi Edward,
      I’m not aware of anyone working on Swift bindings for MPI or OpenMP. Libdispatch does have some overlap of functionality with OpenMP (DispatchQueue.concurrentPerform can be used to express simple parallel loops). For MPI, it might be possible to get something basic working via Swift/C interoperability. I’d be interested in hearing any experience you have with trying to use Swift in HPC applications or systems.

      • Hi Dave (& Edward),

        Over the summer as part of a hackathon, I worked a bit on linking Swift with an MPI library. I managed to get it working, but it was somewhat kludgy at the time.
        I’ve recently had some time to look at it again, and have redone it in a better fashion. Theres currently two packages, for Open MPI (https://github.com/omor1/COpenMPI) and MPICH (https://github.com/omor1/CMPICH), and I suspect that the MPICH package would work with minor changes with some MPICH-derived libraries (e.g. MVAPICH, Intel-MPI, etc), though I haven’t tested this.
        Both packages export a CMPI module, which allows writing Swift code that calls MPI routines, though it will be done as in C. I’m looking towards eventually writing a Swifty binding for MPI, but would ask for community input beforehand. Cheers, and would love to hear feedback!

Join The Discussion

Your email address will not be published. Required fields are marked *