Search

Visual sensor networks (VSNs) perform complex scene analysis algorithms that require significant computations and communications. Under this respect, the use of skeletons contributes to reduce the complexity of VSN programming and may ensure an easier and better optimization of the code. In this context, we propose INS, a stencil based skeleton targeted for wireless/visual sensor networks (W/VSNs) and give a preliminary analysis of its benefits using tracking as a case study. INS abstracts a distributed approximation schema in which the estimation of a given metric is organized in a sequence of steps. Each step includes collecting estimates from some neighbor nodes and local computation of a new approximation. In particular, INS takes inspiration from some stencil based skeletons proposed for parallel computation and merges it with the classical event driven model typical of sensor programming. As a result, the execution of each step is triggered by the detection of a relevant event in the environment. Tracking consists in periodically predicting position and velocity of one or more mobile targets. We discuss how INS can be instantiated to a distributed version of Kalman filtering. As energy efficiency is central in W/VSNs, we derive analytic models for energy dissipation of the INS skeleton depending on different concepts of neighborhood for the data exchanged at each step. Then, these models are used to guide the deployment of our tracking application on a real scenario. [ABSTRACT FROM AUTHOR]

Parallel programming has proved to be an effective technique to increase the performance of computationally intensive applications. However, writing parallel programs is not easy, and activities such as debugging are usually hard and time consuming. To cope with these difficulties, skeletal parallel programming has been widely explored in recent years with very promising results. However, prototypal skeletal systems developed so far tend to be rather inflexible and difficult to adapt to many practical parallelization scenarios. For instance, many systems restrict all the substructures of an application being encapsulated together in term of possibly nested skeletons, which may be cumbersome when parallelizing some large and complex applications. Moreover, it is usually difficult to share resources among different skeleton instances and to reuse the same instance of a skeleton in different parts of the code. This paper reports on the current status of the OcamIP3I (2.0) system, which sensibly changes the skeletal model of the previous versions, making it more usable and flexible. In particular, we describe the new skeletons, the new skeletal execution model as well as related issues on design and implementation. [ABSTRACT FROM AUTHOR]

The paper presents a parallel programming methodology that ensures easy programming, efficiency and portability of programs to different machines belonging to the class of the general-purpose, distributed-memory, MIMD architectures. The methodology is based on the definition of a new, high-level, explicitly parallel language, called P3L, and of a set of static tools that automatically adapt the program features for each target architecture. P3L does not require programmers to specify process activations, the actual parallelism degree, scheduling, or interprocess communications, i.e. all those features that need to be adjusted to harness each specific target machine. Parallelism is on the other hand, expressed in a structured and qualitative way, by hierarchical composition of a restricted set of language constructs, corresponding to those forms of parallelism that are frequently encountered in parallel applications, and that can be efficiently implemented. The efficient portability of P3L applications is guaranteed by the compiler along with the novel structure of the support. The compiler automatically adapts the program features for each specific architecture, using the costs (in terms of performance) of the low-level mechanisms exported by the architecture itself, In our methodology, these costs, along with other features of the architecture, are viewed through an abstract machine, whose interface is used by the compiler to produce the final object code. [ABSTRACT FROM AUTHOR]