{'fraction_non_alphanumeric': 0.012944983818770227, 'fraction_numerical': 0.0028317152103559872, 'mean_word_length': 5.136476426799008, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
High Performance Multi-Paradigm Messaging Run Time on Multicore Systems

Broad deployment of multicore systems in commodity situations has highlighted the need for parallel environments that support a wider range of application than those on traditional parallel supercomputers. Further we need to build composite jobs made of heterogeneous applications. A common underlying runtime that supports multiple programming paradigms appears to be one important part of future parallel computing environments integrating cluster and multicore parallelism. Here we examine CCR or the Concurrency and Coordination Run time from Microsoft as a multi-paradigm run time supporting three key parallel models: full MPI collective messaging, asynchronous threading and coarse grain functional parallelism or workflow. It is an attractive multi-paradigm candidate as it was designed to support general dynamic message patterns with high performance and already has a distributed, REST oriented runtime known as DSS built on top of it. We present results on message latency and bandwidth for two processor multicore systems based on AMD and Intel architectures with a total of four and eight cores. Generating up to a million messages per second on a single PC, we find on the AMD based PC, latencies from 4μs in basic asynchronous threading and point to point mode to 14 μs for a full MPI_SENDRECV exchange with all threads (one per core) sending and receiving 2 messages at a traditional MPI loosely synchronous rendezvous. Workflow latencies are measured as less than 40 μs with all results coming from the CCR and DSS freely available as part of the Microsoft Robotics Studio distribution. We present Intel PC latencies that are significantly higher but whose optimization has not been studied yet by us. Looking to the future, we suggest that the ease of programming custom collectives using the CCR primitives make it attractive to consider building a full MPI run time on top of it. This would have fully asynchronous queued messaging, integration with workflow and thread-based programming, a rendezvous and active message mode, support of managed code (C#) and ability to run on cluster and multicore systems. Although the current CCR has reasonable performance for MPI primitives, it would be important to improve this and current core CCR plans should lead to a factor of 2 lower latencies. We also will investigate the origins of the differences between Intel and AMD results.