Robert Ennals

Task partitioning for multi-core network processors

Network processors (NPs) typically contain multiple concurrent processing cores. State-of-the-art programming techniques for NPs are invariably low-level, requiring programmers to partition code into concurrent tasks early in the design process. This results in programs that are hard to maintain and hard to port to alternative architectures. This paper presents a new approach in which a high-level program is separated from its partitioning into concurrent tasks. Designers write their programs in a high-level, domain-specific, architecturally-neutral language, but also provide a separate Architecture Mapping Script (AMS). An AMS specifies semantics-preserving transformations that are applied to the program to re-arrange it into a set of tasks appropriate for execution on a particular target architecture. We (i) describe three such transformations: pipeline introduction, pipeline elimination and queue multiplexing; and (ii) specify when each can be safely applied. As a case study we describe an IP packet-forwarder and present an AMS script that partitions it into a form capable of running at 3Gb/s on an Intel IXP2400 Network Processor.

Linear Types for Packet Processing

We present PacLang: an imperative, concurrent, linearly-typed language designed for expressing packet processing applications. PacLang’s linear type system ensures that no packet is referenced by more than one thread, but allows multiple references to a packet within a thread. We argue (i) that this property greatly simplifies compilation of high-level programs to the distributed memory architectures of modern Network Processors; and (ii) that PacLang’s type system captures that style in which imperative packet processing programs are already written. Claim (ii) is justified by means of a case-study: we describe a PacLang implementation of the IPv4 unicast packet forwarding algorithm.

Optimistic evaluation: an adaptive evaluation strategy for non-strict programs

Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this observation. Optimistic Evaluation complements compile-time analyses with run-time experiments: it evaluates a thunk speculatively, but has an abortion mechanism to back out if it makes a bad choice. A run-time adaption mechanism records expressions found to be unsuitable for speculative evaluation, and arranges for them to be evaluated more lazily in the future.We have implemented optimistic evaluation in the Glasgow Haskell Compiler. The results are encouraging: many programs speed up significantly (5-25%), some improve dramatically, and none go more than 15% slower.

HsDebug: debugging lazy programs by not being lazy

We argue that conventional debugging techniques have perhaps been dismissed too quickly. We present two alterations to the evaluation model of lazy functional languages that allow conventional debugging techniques to be successfully applied. Transient tail frames allow tail-calls to be visible to the debugger without affecting space complexity (Section 4). Optimistic Evaluation causes evaluation to only use laziness when absolutely necessary, thus preserving the termination behaviour of Lazy Evaluation, while reducing its confusing effect on program state (Section 5).

Controlled temporal non-determinism for reasoning with a machine of finite speed

Reactive models such as that used by Fran [l] allow one to describe a system that changes with time, by describing the state of an object after an event in terms of the situation before the event. This approach has advantages over the action based approach taken by imperative languages and the monadic approach 121. Notably, the state of any behaviour is defined in only one place, and one does not need to worry about when things should be updated. Systems such as Fran [l] allow one to specify the state that the system should be in at an exact point in absolute time, however current machines are only capable of processing information at a finite speed, and so may be unable to set behaviours to the states specified at the times specified. We will usually need to have a lag between the time at which something is specified to take on a value, and the time at which the state actually changes. What is more, the length of this lag will generally be non-deterministic. This lag needs to be dealt with in some way. The convention has been for no objects to be allowed to lag with respect to others, causing everything to always lag by the same amount. This greatly restricts what one can do with the system. One cannot have behaviours that are allowed to update at different rates, or that update as quickly as possible. One also cannot have practical distributed systems, as the synchronisation overhead would be unworkable. In order to make the reactive approach as expressive as the imperative approach, and thus practically applicable to areas beyond those of realtime processing and animations, we need to introduce a degree of temporal non-determinism into our model.

Verbose typing

In type systems that require one to manually specify types, one is constrained by practicality into having relatively short types that can be read and written easily. This constrains the amount of information that can be encoded in a type, and forces one to restrict the expressiveness of the type system. Type inference systems such as that of Haskell [l] improve things greatly by allowing the type system to infer types, but still require types to be stated when declaring type classes. By removing such requirements to state types, we can grant ourselves the freedom to make types as large as we like, including much more information than would otherwise be practical. One way to do this is by separating the concepts of a type identifier and a type constraint.