Shubhendra Pal Singhal

Naveen Ravi, Nathan Wichmann, Md. Wasi-ur- Rahman et al.

Leadership-class HPC systems are now accelerator-centric, with GPUs providing most floating-point throughput and memory bandwidth. As next-generation systems increasingly integrate accelerators through high-speed memory fabrics and system interconnects, exposing larger tightly coupled device domains, \ac{PGAS} models such as OpenSHMEM provide a natural abstraction for expressing fine-grained remote memory operations across these devices. While OpenSHMEM 1.x offers a lean PGAS model for irregular communication, atomics, fine-grained synchronization, and collectives, its memory model lacks portable semantics for accelerator architectures. As a result, existing GPU-enabled OpenSHMEM implementations differ in memory management, capability discovery, and operation semantics, limiting portability and ecosystem cohesion. This risks fracturing the community that OpenSHMEM was originally created to unify. This paper proposes an OpenSHMEM Auxiliary Specification for GPU-Aware Communication, designed as a lightweight, backward-compatible extension to OpenSHMEM 1.x. The auxiliary specification introduces a minimal memory model extension via a GPU-scoped memory space abstraction, along with capability queries and well-defined semantics for using \acs{GPU}-attached buffers in RMA, atomic, synchronization, and collective operations. This is initially conceived through the lens of a host-initiated interface, although it provides a general set of semantics that also allow for optional device-initiated support. A central goal of this effort is to demonstrate that GPU-aware OpenSHMEM semantics can be specified and implemented across GPUs from multiple vendors, providing a practical and rapidly implementable step toward unification under a vendor-neutral specification while informing the design of future OpenSHMEM specifications.

Shubhendra Pal Singhal, Sandeep Gupta, Pierluigi Nuzzo

This paper focuses on the explanation of the architecture of profilers particularly gprof and how to profile a program according to the user defined input of execution time . Gprof is a profiler available open source in the package of binutils. Gprof records the flow of the program including the callee and caller information and their respective execution time. This information is represented in the form of a call graph. Profilers at the time of execution creates a call graph file which indicates the full flow of the program including the individual execution time as well. This paper aims at providing a better understanding of the data structure used to store the information and how is a profiler(gprof) actually using this data structure to give user a readable format. The next section of this paper solves one of the limitation of gprof i.e. edit the time of block of code without understanding the call graph. Any changes in the execution time of a particular block of code would affect the total execution time. So if we edit the gprof in such a way that its consistent and platform independent, then it can yield various results like testing execution time after parallelism, before even designing it by replacing the values with theoretical/emulated ones and see if the total execution time is getting reduced by a desired number or not? Gprof edit can help us figure out that what section of code can be parallelized or which part of code is taking the most time and which call or part can be changed to reduce the execution time. The last section of the paper walks through the application of gprof in minisat and how gprof helps in the hardware acceleration in minisat by suggesting which part to be parallelised and how does it affect the total percentage.

Shubhendra Pal Singhal

In this paper we are trying to determine a scheme for the fair allocation of points to the contributors of the collaborative community. The major problem of fair allocation of points among the contributors is that we have to analyze the improvement in the versions of an article. Lets say there is a contribution of major change in content which is relevant vs the contribution of adding a single comma. Every contributor cannot be given the same points in such a case. There are many ways which can be used like number of changes in a new version. That might seem relevant but it becomes irrelevant in terms of correct content contribution and other significant changes. There is no AI system too which can detect such a change and award the points accordingly. So this problem of allocation of points to the contributors is presented by an algorithm with a theoretical proof. It relies on the interactive interaction of the users in the system which is trivial in case of big system design economies.