Many programs exploit shared-memory parallelism using multithreading. Threaded codes typically use locks to coordinate access to shared data. In many cases, contention for locks reduces parallel efficiency and hurts scalability. Being able to quantify and attribute lock contention is important for understanding where a multithreaded program needs improvement.This paper proposes and evaluates three strategies for gaining insight into performance losses due to lock contention. First, we consider using a straightforward strategy based on call stack profiling to attribute idle time and show that it fails to yield insight into lock contention. Second, we consider an approach that builds on a strategy previously used for analyzing idleness in work-stealing computations; we show that this strategy does not yield insight into lock contention. Finally, we propose a new technique for measurement and analysis of lock contention that uses data associated with locks to blame lock holders for the idleness of spinning threads. Our approach incurs ≤ 5% overhead on a quantum chemistry application that makes extensive use of locking (65M distinct locks, a maximum of 340K live locks, and an average of 30K lock acquisitions per second per thread) and attributes lock contention to its full static and dynamic calling contexts. Our strategy, implemented in HPCToolkit, is fully distributed and should scale well to systems with large core counts.

/pdf/analyzing-lock-contention-in-multithreaded-applications-307f8956qb.pdf

Analyzing lock contention in multithreaded applications

A semiconductor integrated circuit has a central processing unit and a rewritable nonvolatile memory area disposed in an address space of the central processing unit. The nonvolatile memory area has a first nonvolatile memory area and a second nonvolatile memory area, which memorize information depending on the difference of threshold voltages. The first nonvolatile memory area has the maximum variation width of a threshold voltage for memorizing information set larger than that of the second nonvolatile memory area. When the maximum variation width of the threshold voltage for memorizing information is larger, since stress to a memory cell owing to a rewrite operation of memory information becomes larger, it is inferior in a point of guaranteeing the number of times of rewrite operation; however, since a read current becomes larger, a read speed of memory information can be expedited. The first nonvolatile memory area can be prioritized to expedite a read speed of the memory information and the second nonvolatile memory area can be prioritized in guaranteeing the number of times of rewrite operation of memory information more.

Semiconductor Integrated circuit

Dynamic software optimization methods are becoming increasingly popular for improving software performance and power. The first step in dynamic optimization consists of detecting frequently executed code, or "critical regions." Previous critical region detectors have been targeted to desktop processors. We introduce a critical region detector targeted to embedded processors, with the unique features of being very size and power efficient, and being completely non-intrusive to the software's execution - features needed in timing-sensitive embedded systems. Our detector not only finds the critical regions, but also determines their relative frequencies, a potentially important feature for selecting among alternative dynamic optimization methods. Our detector uses a tiny cache coupled with a small amount of logic. We provide results of extensive explorations across seventeen embedded system benchmarks. We show that highly accurate results can be achieved with only a 0.02% power overhead and acceptable size overhead. Our detector is currently being used as part of a dynamic hardware/software partitioning approach, but is applicable to a wide-variety of situations.

Frequent loop detection using efficient non-intrusive on-chip hardware

Performance monitoring hardware is available on most modern microprocessors in the form of hardware counters and other registers that record data about processor events This hardware may be used in counting mode, in which aggregate events counts are accumulated, and/or in sampling mode, in which time-based or event-based sampling is used to collect profiling data This paper discusses uses of these two modes and considers the issues of efficiency and accuracy raised by each Implications for the PAPI cross-platform hardware counter interface are also discussed

/pdf/a-comparison-of-counting-and-sampling-modes-of-using-36ylk6u4fw.pdf

A Comparison of Counting and Sampling Modes of Using Performance Monitoring Hardware

Recent advances in networking and embedded device technology have made the vision of ubiquitous computing a reality; users can access the Internet's vast offerings any-time and anywhere. Moreover, battery-powered devices such as personal digital assistants and web-enabled mobile phones have successfully emerged as new access points to the world's digital infrastructure. This ubiquity offers a new opportunity for software developers: users can now participate in the software development, optimization, and evolution process while they use their software. Such participation requires effective techniques for gathering profile information from remote, resource-constrained devices. Further, these techniques must be unobtrusive and transparent to the user; profiles must be gathered using minimal computation, communication, and power. Toward this end, we present a flexible hardware-software scheme for efficient remote profiling. We rely on the extraction of meta information from executing programs in the form of phases, and then use this information to guide intelligent online sampling and to manage the communication of those samples. Our results indicate that phase-based remote profiling can reduce the communication, computation, and energy consumption overheads by 50-75% over random and periodic sampling.

/pdf/phase-aware-remote-profiling-58z0tm58f6.pdf

Phase-Aware Remote Profiling

A multi-threaded processor provides for efficient flow-control from a pool of un-executed stores in an instruction queue to a store queue. The processor also includes similar capabilities with respect to load instructions. The processor includes logic organized into a plurality of thread processing units (“TPUs”) and allocation logic that monitors each TPUs demand for entries in the store queue. Demand is determined by subtracting an adjustable threshold value from the most recently assigned store identifier value. If the difference between the most recently assigned instruction identifier for a TPU and the TPU's threshold is non-zero, then it is determined that the TPU has demand for at least one entry in the store queue. The allocation logic includes arbitration logic that determines which one of a plurality of TPUs with store queue demand should be allocated a free entry in the store queue.

Flexible demand-based resource allocation for multiple requestors in a simultaneous multi-threaded CPU

Profile data is valuable for identifying performance bottlenecks and guiding optimizations. Periodic sampling of a processor’s performance monitoring hardware is an effective, unobtrusive way to obtain detailed profiles. Unfortunately, existing hardware simply counts events, such as cache misses and branch mispredictions, and cannot accurately attribute these events to instructions, especially on out-of-order machines. We propose an altemative approach, called ProjileMe, that samples instructions. As a sampled instruction moves through the processor pipeline, a detailed record of all interesting events and pipeline stage latencies is collected. ProfileMe also support paired sumpling, which captures information about the interactions between concurrent instructions, revealing information about useful concurrency and the utilization of various pipeline stages while an instruction is in flight. We describe an inexpensive hardware implementation of ProfileMe, outline a variety of software techniques to extract useful profile information from the hardware, and explain several ways in which this information can provide valuable feedback for programmers and optimizers.

ProJiZeMe: Hardware Support for Instruction-Level on Out-of-Order Processors

PROBLEM TO BE SOLVED: To provide a method for estimating the statistic value of characteristics of interaction between instructions processed by a processor pipeline. SOLUTION: In a method for estimating the statistic value of characteristics of interaction between instructions processed by a pipeline 111 of a computer system including plural processing steps, the instructions are fetched to the first step of the pipeline 111. A set of the instructions is selected at random from among the fetched instructions and a subset of the selected set of the instructions is mutually executed at the same time. A distance between the selected sets of the instructions is specified and the state information of the computer system is recorded while the selected set of the instructions is processed by the pipeline 111. The recorded state information is transmitted to software where a statistical analysis is applied to the plural sets of the selected instructions and the statistic value of the interaction between selected sets of instructions is estimated.

Method for estimating statistic value of characteristics of instruction processed by processor pipeline

Vorrichtung und Verfahren zur Überwachung eines Rechnersystems zur Steuerung der Optimierung

An apparatus is provided for sampling multiple concurrently executing instructions in a processor pipeline of a system The pipeline has a plurality of processing stages When the instructions are fetched into a first stage of the pipeline, the apparatus identifies multiple selected instructions as a subset of the instructions that one executed concurrently in the pipeline State information of the system is sampled while any of the multiple selected instructions are in any stage of the pipeline Software is informed whenever all of the selected instructions leave the pipeline so that the software can read any of the state information

George Z. Chrysos

Papers

Flexible demand-based resource allocation for multiple requestors in a simultaneous multi-threaded CPU

ProJiZeMe: Hardware Support for Instruction-Level on Out-of-Order Processors

Method for estimating statistic value of characteristics of instruction processed by processor pipeline

Vorrichtung und Verfahren zur Überwachung eines Rechnersystems zur Steuerung der Optimierung

Apparatus for sampling multiple concurrent instructions in a processor pipeline