PAMGUARD is open-source, platform-independent software to address the needs of developers and users of Passive Acoustic Monitoring (PAM) systems. For the PAM operator—marine mammal biologist, manager, or mitigator—PAMGUARD provides a flexible and easy-to-use suite of detection, localization, data management, and display modules. These provide a standard interface across different platforms with the flexibility to allow multiple detectors to be added, removed, and configured according to the species of interest and the hardware configuration on a particular project. For developers of PAM systems, an Application Programming Interface (API) has been developed which contains standard classes for the efficient handling of many types of data, interfaces to acquisition hardware and to databases, and a GUI framework for data display. PAMGUARD replicates and exceeds the capabilities of earlier real time monitoring programs such as the IFAW Logger Suite and Ishmael. Ongoing developments include improved real-time location and automated species classification. [PAMGUARD funded by the OGP E&P Sound and Marine Life project.]

The process of writing large parallel programs is complicated by the need to specify both the parallel behaviour of the program and the algorithm that is to be used to compute its result. This paper introduces evaluation strategies: lazy higher-order functions that control the parallel evaluation of non-strict functional languages. Using evaluation strategies, it is possible to achieve a clean separation between algorithmic and behavioural code. The result is enhanced clarity and shorter parallel programs. Evaluation strategies are a very general concept: this paper shows how they can be used to model a wide range of commonly used programming paradigms, including divide-and-conquer parallelism, pipeline parallelism, producer/consumer parallelism, and data-oriented parallelism. Because they are based on unrestricted higher-order functions, they can also capture irregular parallel structures. Evaluation strategies are not just of theoretical interest: they have evolved out of our experience in parallelising several large-scale parallel applications, where they have proved invaluable in helping to manage the complexities of parallel behaviour. Some of these applications are described in detail here. The largest application we have studied to date, Lolita, is a 40,000 line natural language engineering system. Initial results show that for these programs we can achieve acceptable parallel performance, for relatively little programming effort.

No abstract

As the number of cores grows in commodity architectures so does the likelihood of failures. A distributed actor model potentially facilitates the development of reliable and scalable software on these architectures. Key components include lightweight processes which 'share nothing' and hence can fail independently. Erlang is not only increasingly widely used, but the underlying actor model has been a beacon for programming language design, influencing for example Scala, Clojure and Cloud Haskell.While the Erlang distributed actor model is inherently scalable, we demonstrate that it is limited by some pragmatic factors. We address two network scalability issues here: globally registered process names must be updated on every node (virtual machine) in the system, and any Erlang nodes that communicate maintain an active connection. That is, there is a fully connected O(n 2 ) network of n nodes.We present the design, implementation, and initial evaluation of a conservative extension of Erlang -Scalable Distributed (SD) Erlang. SD Erlang partitions the global namespace and connection network using s groups. An s group is a set of nodes with its own process namespace and with a fully connected network within the s group, but only individual connections outside it. As a node may belong to more than one s group it is possible to construct arbitrary connection topologies like trees or rings.We present an operational semantics for the s group functions, and outline the validation of conformance between the implementation and the semantics using the QuickCheck automatic testing tool. Our preliminary evaluation in comparison with distributed Erlang shows that SD Erlang dramatically improves network scalability even if the number of global operations is tiny (0.01%). Moreover, even in the absence of global operations the reduced connection maintenance overheads mean that SD Erlang scales better beyond 80 nodes (1920 cores).

Massively Multiplayer Online Games (MMOGs) are increasing in both popularity and scale, and while classical Client/Server (C/S) architectures convey some benefits, they suffer from significant technical and commercial drawbacks. This realisation has sparked intensive research interest in adapting MMOGs to Peer-to-Peer (P2P) architectures. This paper articulates a comprehensive set of six design issues to be addressed by P2P MMOGs, namely Interest Management (IM), game event dissemination, Non-Player Character (NPC) host allocation, game state persistency, cheating mitigation and incentive mechanisms. Design alternatives for each issue are systematically compared, and their interrelationships discussed. We further evaluate how well representative P2P MMOG architectures fulfil the design criteria.

Parallel and distributed languages specify computations on multiple processors and have a computation language to describe the algorithm, i.e. what to compute, and a coordination language to describe how to organise the computations across the processors. Haskell has been used as the computation language for a wide variety of parallel and distributed languages, and this paper is a comprehensive survey of implemented languages. We outline parallel and distributed language concepts and classify Haskell extensions using them. Similar example programs are used to illustrate and contrast the coordination languages, and the comparison is facilitated by the common computation language. A lazy language is not an obvious choice for parallel or distributed computation, and we address the question of why Haskell is a common functional computation language.

No abstract

No abstract