By Rob Mitchum // June 6, 2014
For software geeks, the breakout star of the Apple’s Worldwide Developers Conference (WWDC) this year wasn’t the next Macbook or iPhone, but a new language called Swift, for programming Apple devices. Apple hopes the language will replace the aged Objective-C as the primary way to develop software for its iOS and OS X operating systems, promising easier, faster and more secure coding.
But Apple’s Swift is not the first computing technology to carry that name. Several software tools already bear that moniker: Cornell’s secure web programming model, OpenStack’s storage system, and the acronymic worldwide interbank fund transfer software SWIFT – to name just a few.
Since 2007, Computation Institute computer scientists have created and supported a completely different Swift: a high-level programming language to make fast parallel computing on any system easier for scientists, engineers, and data analysts. The Apple and Chicago Swift languages share more than a name. Both Swifts aim to speed up development and execution, says team leader and CI senior fellow Michael Wilde, but for different applications on different computing systems and in very different ways.
“There are parallels between both Swifts in terms of the ends they want to achieve: making writing code easy and error-free, one for commercial apps and another for science apps,” said Argonne’s Ketan Maheshwari, a computer scientist on the UChicago/Argonne Swift team.
Born in 2007, the Swift parallel scripting language originated within the Globus Project – a toolkit for helping scientists tap into the distributed power of grid computing for their research. Swift’s goal was to bring a similarly powerful method to scientists: parallel computing. Instead of working through an analysis sequentially, parallel computing splits up tasks onto multiple cores, from the 2 or 4 cores found in most of today’s laptops to the hundreds of thousands (and soon, millions) of processors in today’s fastest supercomputers. But while the logic of a sequential program makes intuitive sense, programming for parallelization remains a formidable challenge for most scientists and engineers.
“What we observe is even embedded parallel programming is not that easy for scientists, and it’s not that easy because of all the plumbing reasons, the mundane things that are connecting data flow from one kind of thing to another,” Wilde said. “All these things that scientists don’t want to know about, and shouldn’t have to know about – they’re distractions from the scientific mission.”
The magic of Swift is that it doesn’t require scientists to rewrite the existing code or software they are comfortable and experienced with using in their research. As a high-level and “little” language, Swift wraps around those pre-existing applications or library functions and automatically parallelizes them, with a minimal amount of additional code. So if a bioinformatics team wants to run the sequence alignment tool BLAST a million times simultaneously on a campus cluster or in the cloud, a dozen lines of Swift code can make that happen without much fuss.
“Scientists already have at their disposal all these incredibly valuable modules of code, either as an application or as a function library,” Wilde said. “Swift is the orchestration language to put them together – and run hundreds or thousands of them at once.”
Swift’s high-level approach also allows it to perform an important organizational role for an era of open and computational science. By encapsulating all of the activities going on within its reach, Swift can keep track of data inputs, the processes executed on that data, and the data outputs, Wilde said. As journal publications increasingly ask authors to provide such details, Swift eases the burden of yet another difficult and tedious task researchers often face.
Currently, Swift is used in a broad range of disciplines and research methods, ranging fromtheoretical chemistry (shown at left, in a study of glass structure by Glen Hocky and David Reichmann), biophysics, and cancer biology to structural engineering, urban planning, circuit simulation, journal text mining, and drug discovery. Wilde hopes that the language continues to expand into new fields of research, while at the same time paradoxically becoming “invisible” to scientific programmers. Recognizing that programmers would prefer not to learn a new language beyond those they are familiar with using, the Swift team has started looking at ways of embedding Swift’s programming model into popular languages such as Python and R.
In the ideal situation, programmers would be able to simply designate, in their own preferred language, which loops they would like to run in parallel, and Swift semantics would handle the gritty details behind the scenes.
So while Apple seeks to make its Swift highly visible, the ultimate success of UChicago’s Swift parallel programming model will be greatest when it becomes largely invisible to the programmer. “We want to make Swift’s contribution last a long time by making it vanish,” Wilde said. “Its functions will be embedded in all important languages in a clean enough way that they can be used naturally by the programmers who speak those native languages. We think that many language communities would embrace this approach, so that’s our next goal.”
Sharing the same name is now an even bigger challenge for the many members of the Swift community. But scientists, engineers, and analysts who need to run many copies of diverse applications in parallel on a wide range of computer systems will be well served by the Swift parallel scripting language, Wilde said.
Swift research team: Tim Armstrong, Ian Foster, Daniel S. Katz, David Kelly, Ketan Maheshwari, Yadu Nand, Michael Wilde, Justin Wozniak