GSoC 22: First Eval Update

In the second week of July, we completed the first evaluation of our Google Summer of Code program. The students have provided summaries of their work and details of the pull requests they’ve created. Check them out below:

Monalisha Ojha:

https://medium.com/@monalisha-ojha/multiple-datasets-performance-visualization-traveler-a352c13f7c25

Multiple Datasets Performance Visualization — Traveler

Phase-1 of Google Summer of Code 2022 at Stellar Group

This summer, I am working as a Google Summer of Code mentee in STE||AR Group on “Upgrading Multiple Datasets Performance Visualization feature in Traveler” under the mentorship of Kate Isaacs. This blog summarizes my work on the Traveler Platform during phase 1 of Google Summer of Code 2022 program.

About Traveler

Traveler-Integrated is a web-based visualization system for parallel performance data, such as OTF2 traces and HPX execution trees. HPX traces are collected with APEX and written as OTF2 files with extensions. It is developed by the HDC Lab (Humans, Data and Computers Lab) at the University of Arizona.The major goal of this platform is to provide meaningful insights into parallel performance data in the form of Gantt charts (trace data timelines with dependencies), source code, expression tree, aggregated time series line charts for counter data, utilization chart and task level histograms.

Web Interface of Traveler

Abstract

The aim of this project, “Multiple Datasets Performance Visualization,’’ is to add specific features in the platform that will help in managing multiple data files and organizing traveler interface windows to handle the comparison of data. Organizing multiple datasets in the platform, comparison of datasets side by side, implementing a highlighted linking system for multiple datasets and organizing datasets efficiently for visualization are some of the major sub-goals.

Phase — 1

Updated the Tagging system of Traveler Interface to accommodate multiple datasets

Issue : Organizing the datasets according to their assigned tags.

Made changes in the interface main menu to display the datasets according to their tags names. Tested the tagging system back-end to accommodate multiple datasets. The screenshot displays the fixes made when tested with 2 datasets.

Traveler Interface

Issue Link: https://github.com/hdc-arizona/traveler-integrated/issues/90

Pull Request: https://github.com/hdc-arizona/traveler-integrated/pull/91

Fixed glitches related Traveler front-end

Issue: Displaying a clear relationship between a folder and its datasets.

Made changes in the front-end to make the lines visible that shows the connection between folder and its datasets. Adjusted the tag header to solve the tag overlapping issue for multiple datasets. The screenshot of the changes are shown below.

Traveler Interface

Issue link: https://github.com/hdc-arizona/traveler-integrated/issues/92

Pull request link: https://github.com/hdc-arizona/traveler-integrated/pull/93

Adding dynamic color highlighting system

Issue: Adding a color picker system to distinguish between multiple datasets.

“Change Datasets color” option is added to datasets context menu. With this feature, a user can change the datasets selection color and main menu color to be distinguishable from other datasets. The screenshots of changes done till now are displayed below:

Traveler Interface

Pull request link: https://github.com/hdc-arizona/traveler-integrated/pull/94

Shreyas Atre

https://satacker.github.io/docs/c++/GSoC-HPX/

Mentors (STE||AR Group @ LSU)

  1. Dr. Hartmut Kaiser, Adjunct Professor @ LSU
  2. Giannis Gonidelis, RA @ LSU

Abstract#

HPX being up to date with Std C++ Proposals, Senders/Receivers were implemented as per P2300. But they have been missing coroutine (co_await) integration and minor functionalities as described in P2300 which is likely to be accepted. Hence I plan to implement these functionalities within the Core HPX Library.

  • Benefits:
    • Coroutines introduce better async code. For example, it is more readable, local variables have the same lifespan as the coroutine which means we don’t need to worry about allocation/release.
    • S/R algorithms can work with coroutines which they cannot as of now unless relied on futures which as mentioned are single-time use.
    • Adding co_await support makes the code more structured with respect to concurrency which can also be done by library abstractions of callbacks but using co_await may make it more optimized.

Brief Summary#

  • Senders, and Receivers
    • Because it makes a more consistent programming model considering async programming types i.e. Parallelism and Concurrency. It standardizes the terminologies and execution policies which are more generic and reduce redundancy.
    • Coroutines have a direct connection between Senders and Coroutine Awaitables.
  • Futures
    • One of the points of S/R is to avoid the allocations associated with futures, also, futures are single-use, whereas S/R, in general, can be used (started) multiple times. – Dr. H. Kaiser

Goal is to enable all Sender CPOs to do the following:

  • If we write a sender and pass it to a function which could be a coroutine that could co_await that sender and get its result.
  • If they are not generally awaitable then we can await transform them (i.e. make them awaitable).

Work#

My PRs can be found using this link as it’ll always be updated.

Following are the Merged PRs until now:

With coroutine traits completed, my remaining work is the following:

  1. Adapt get_completion_signatures when Sender is a awaitable
  2. Utility as_awaitable_t
    • receiver_basesender_awaitable_base
    • to transform an object into one that is awaitable within a particular coroutine.
  3. promise base for 5.
  4. operation base for 5.
  5. Utility connect_awaitable to adapt connect mentioned in spec 2.2
  6. Utility with_awaitable_senders
    • Used as the base class of a coroutine promise type, makes senders awaitable in that coroutine type

References#

Panagiotis Syskakis:

I’m Panos, currently studying Electrical and Computer Engineering in Aristotle University of Thessaloniki, in Greece. This summer, I joined the HPX team as a contributor through Google Summer of Code (GSoC).

My GSoC project involves performance analysis and optimization on C++ standard parallel algorithms.

To explain further:
The C++ standard defines many functions for algorithms that are commonly used by developers (eg. sorting, searching).
HPX provides sequential and parallel implementations for all these algorithms.
I’m working on improving the performance of these implementations.

So far, I have explored different methodologies for visualizing and assessing an algorithm’s performance. This has involved a lot of scripting for automating tasks, as well as data collection and analysis.

With help from my mentor, I have produced plots that show how an algorithm’s performance changes when tweaking different parameters (such as workload size and number of computer cores). We also produced visualizations of how different tasks are distributed and where/how they are executed in a parallel environment.

Most importantly though:
The HPX community has been immensely welcoming. It can often be awkward being “the new junior guy”, but my mentor quickly made me feel like a part of the team.
People here are talented, but also fun and humble, and always eager to help.

This summarizes my experience for the first two months of GSoC. I have learned tons so far. My work here is far from done, however we have laid a great foundation for the work that will follow.