Enhancing data-streaming programming platforms: a case for dispel4py and a GrPPI comparison

Hi! My name Javier Fernández Muñoz, I am working as a Visiting Professor in the Computer Architecture and Technology Area of the Computer Science Department at the University Carlos III de Madrid (Spain). 

My research field includes the development of parallel programming frameworks that enhance usability and portability. In this regard, I have been working several years in the development of GrPPI (Generic Reusable Parallel Pattern Interface), an open source generic and reusable parallel pattern programming interface. Basically, GRPPI accommodates a layer between developers and existing parallel programming frameworks targeted at multi-core processor capabilities, such as ISO C++ Threads, OpenMP, Intel TBB, and FastFlow. To achieve this goal, the interface leverages modern C++ features, meta-programming concepts, and generic programming to act as a switch between those frameworks.

I spent three months at EPCC at the University of Edinburgh under the HPC-Europa3 transnational access programme with EPCC's Dr Rosa Filgueira acting as my host. The main objective of this collaborative research is to compare two parallel programming frameworks designed for online big data management using the data stream processing (DaSP) paradigm. These two programming frameworks are the aforementioned GrPPI and the dispel4py framework, which is a parallel Python-based stream-orientated dataflow framework that acts as a bridge to existing distributed programming frameworks like MPI, Storm and Python multiprocessing. The idea is to detect the advantages and drawbacks of both frameworks' approaches and start making a case for a future integration of both frameworks.

A use-case based on the cross-correlation of waveform traces from seismology stations was implemented. The application is written as a pipelined workflow. The pipeline is divided into two phases: in the first phase, each continuous time series (or trace) obtained from a given seismic station is preprocessed independently.  Later, in the second phase, every single trace is cross-correlated with every other trace in a combinatory pair-up process. The application was implemented on both frameworks using their distinctive corresponding philosophies.

The test results (see the diagram below) show that on a single node, the C++/GrPPI implementation has a better performance than Python/Dispel4Py for a small number of cores. However, the situation reverses when the number of cores increase. This is due to the different treatment of the data. While GRPPI uses a single copy of each trace that is shared for all computing stages, Dispel4Py performs a copy of the trace data at each stage. This drags the Dyspel4Py performance down when working on the same NUMA node. But when the number of cores increases, GrPPI’s performance starts getting worse because of the need to work on the memory of a different NUMA node rather than just the working core.

In conclusion the results show that, in order to improve performance of GrPPI, data inside the NUMA node should be shared among the computing stages instead of copied. While among NUMA nodes (or actual nodes), the data should be copied instead

It was not all work. In my free time I enjoyed the Edinburgh city life, the multiple parks, monuments and historic buildings in Edinburgh and other parts of Scotland. I also had the opportunity to attend a performance of the Military Tattoo on the Edinburgh Castle Esplanade, which I really enjoyed.

Ms Catherine Inglis (EPCC) provided me with not only excellent administrative support, but with invaluable help to stay in the city and finish my visit successfully.

Dr Mario Antonioletti (EPCC) and Dr William Lucas (EPCC) made my access to Cirrus an effortless procedure. They helped me with any platform-related issues, provided me with hardware when mine was failing, and gave me professional advice that helped me to perform the visit-related tasks more efficiently.