Distributed Places [chapter]

Kevin Tew, James Swaine, Matthew Flatt, Robert Bruce Findler, Peter Dinda
2014 Lecture Notes in Computer Science  
Distributed Places bring new support for distributed, messagepassing parallelism to Racket. This paper gives an overview of the programming model and how we had to modify our existing, runtime-system to support distributed places. We show that the freedom to design the programming model helped us to make the implementation tractable. The paper presents an evaluation of the design, examples of higher-level API's that can be built on top of distributed places, and performance results of standard
more » ... arallel benchmarks. with the Racket language to create extended languages, which describe different types of distributed programming. The distributed places API allows the user to spawn new execution contexts on remote machines. Distributed places reuse the communication channel API for intra-process parallelism to build a transparent distributed communication system over a underlying sockets layer. Racket's channels for parallel and distributed communication are first-class Racket events. These channels can be waited on concurrently with other Racket event objects such as file ports, sockets, threads, channels, etc. Together, Racket's intraprocess and distributed parallelism constructs form a foundation capable of supporting higher-level parallel frameworks. Design Programming with parallelism should avoid the typical interference problems of threads executing in a single address space. Instead, parallel executions contexts should execute in isolation. Communication between execution contexts should use message-passing instead of shared-memory in a common address space. This isolated, message-passing approach positions the programmer to think about the data-placement and communication needs of a parallel program to enable sustained scalability. Distributed places extend our existing implementation of isolated, message-passing parallelism which, until now, was limited to a single node. As a program moves from multi-core parallelism to multi-node parallelism latency increases and bandwidth decreases; data-placement and communication patterns become even more crucial. Much of a distributed programming API is littered with system administration tasks that impede programmers from focusing on programming and solving problems. First, programmers have to authenticate and launch their programs on each node in the distributed system. Then they have to establish communication links between the nodes in the system, before they can begin working on the problem itself. The work of the distributed places framework is to provide support for handling the problems of program launch and communication link establishment. Racket's distributed places API design is centered around machine nodes that do computation in places. The user/programmer configures a new distributed system using declarative syntax and callbacks. By specifying a hostname and port number, a programmer can launch a new place on a remote host. In the simplest distributed-places programs, hostnames and port numbers are hardwired. When programmers need more control, distributed places permits complete programmatic configuration of node launch and communication link parameters.
doi:10.1007/978-3-642-45340-3_3 fatcat:zhz2uuvnsfcarctqzokcgax3pu