The S3.mp scalable shared memory multiprocessor

Nowatzyk, Andreas; Aybay, Gunes; Browne, M. C.; Kelly, Edmund J.; Lee, D.; Parkin, Michael

doi:10.1109/hicss.1994.323149

Cited by 54 publications

(52 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such controllers appear in the MIT Alewife machine [1], the KSR1 machine [15], the Stanford DASH multiprocessor [17], and the SGI Origin 2000 [16]. As o increases, the controller becomes less hardwired and more general-purpose, from specialized coprocessors like those in the Stanford FLASH multiprocessor [14] and the Sun S3.mp [22], through inexpensive off-the-shelf processors on the memory bus as in Typhoon-1 [23], to a controller on the I/O bus of the main processor like those in SHRIMP [3], and the IBM SP2 [28]. We also vary the node-to-network bandwidth from 400 MB/s (g 1 ) down to 25 MB/s (g 16 ), to analyze the effect of reducing network bandwidth on the applications under consideration.…”

Section: Design Spacementioning

confidence: 99%

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

Chaudhuri

Heinrich

Holt³

et al. 2003

IEEE Trans. Comput.

View full text Add to dashboard Cite

Abstract-While the desire to use commodity parts in the communication architecture of a DSM multiprocessor offers advantages in cost and design time, the impact on application performance is unclear. We study this performance impact through detailed simulation, analytical modeling, and experiments on a flexible DSM prototype, using a range of parallel applications. We adapt the logP model to characterize the communication architectures of DSM machines. The l (network latency) and o (controller occupancy) parameters are the keys to performance in these machines, with the g (node-to-network bandwidth) parameter becoming important only for the fastest controllers. We show that, of all the logP parameters, controller occupancy has the greatest impact on application performance. Of the two contributions of occupancy to performance degradation-the latency it adds and the contention it induces-it is the contention component that governs performance regardless of network latency, showing a quadratic dependence on o. As expected, techniques to reduce the impact of latency make controller occupancy a greater bottleneck. Surprisingly, the performance impact of occupancy is substantial, even for highly-tuned applications and even in the absence of latency hiding techniques. Scaling the problem size is often used as a technique to overcome limitations in communication latency and bandwidth. Through experiments on a DSM prototype, we show that there are important classes of applications for which the performance lost by using higher occupancy controllers cannot be regained easily, if at all, by scaling the problem size.

show abstract

Section: Design Spacementioning

confidence: 99%

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

Chaudhuri

Heinrich

Holt³

et al. 2003

IEEE Trans. Comput.

View full text Add to dashboard Cite

show abstract

“…To minimize changes to the memory system, TokenTM stores 16 metabits per 64-byte memory block using recoded error-correction codes, as pioneered by S3.mp [21]. Standard DRAM modules uses 72-bit codewords to protect 64 data bits with single error correction and double error detection (SECDED).…”

Section: Metastate At Memorymentioning

confidence: 99%

TokenTM: Efficient Execution of Large Transactions with Hardware Transactional Memory

Bobba¹,

Goyal²,

Hill³

et al. 2008

2008 International Symposium on Computer Architecture

View full text Add to dashboard Cite

Current hardware transactional memory systems seek to simplify parallel programming, but assume that large transactions are rare, so it is acceptable to penalize their performance or concurrency. However, future programmers may wish to use large transactions more often in order to integrate with higher-level programming models (e.g., database transactions) or perform selected I/O operations.To prevent the "small transactions are common" assumption from becoming self-fulfilling, this paper contributes TokenTM-an unbounded HTM that uses the abstraction of tokens to precisely track conflicts on an unbounded number of memory blocks. TokenTM implements tokens with new mechanisms, including metastate fission/fusion and fast token release. TokenTM executes small transactions fast, executes concurrent large transactions with no penalty to nonconflicting transactions, and gracefully handles paging, context switching, and System-V-style shared memory.

show abstract

“…Such flexible protocol processors, used in the Piranha system [1], STiNG multiprocessor [19], S3.mp [23], etc., allow late binding of the protocol, flexibility in the choice of protocol, and a relatively easy and fast protocol verification phase. Coherence messages arrive at the processor interface (PI inbound) or the network interface (NI inbound) and wait for the dispatch unit to schedule them.…”

Section: Node Controller Architecturementioning

confidence: 99%

Exploring virtual network selection algorithms in DSM cache coherence protocols

Chaudhuri

Heinrich

2004

IEEE Trans. Parallel Distrib. Syst.

View full text Add to dashboard Cite

Abstract-Distributed shared memory (DSM) multiprocessors typically require disjoint networks for deadlock-free execution of cache coherence protocols. This is normally achieved by implementing virtual networks with the help of virtual channels or virtual lanes multiplexed on a single physical network. To keep the coherence protocol simple, messages are usually assigned to virtual lanes in a predefined static manner based on a cycle-free lane assignment dependence graph. However, this static split of virtual networks (such as request and reply networks) may lead to underutilization of certain virtual networks while saturating the other networks. In this paper, we explore different static and dynamic schemes to select the virtual lanes for outgoing messages and mix the load among them without restricting any particular type of message to be carried only by a particular virtual network. We achieve this by exposing the selection algorithms to the coherence protocol itself, so that it can inject messages into selected virtual lanes based on some local information, and still enjoy deadlock-freedom. Our execution-driven simulation on five applications from the SPLASH-2 suite shows that as the system scales, the virtual network selection algorithms play an important role. For 128-node systems, our dynamic selection algorithm speeds up parallel execution by as much as 22 percent over an optimized baseline system running a modified SGI Origin 2000 protocol. We also explore how network latency, the number of message buffers per virtual lane, and the depth of network interface output queues affect the relative performance of various virtual lane selection algorithms.

show abstract

The S3.mp scalable shared memory multiprocessor

Cited by 54 publications

References 6 publications

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

Latency, occupancy, and bandwidth in dsm multiprocessors: a performance evaluation

TokenTM: Efficient Execution of Large Transactions with Hardware Transactional Memory

Exploring virtual network selection algorithms in DSM cache coherence protocols

Contact Info

Product

Resources

About