automatically exploiting cross-invocation parallelism using runtime ...
Share Embed Flag
Download ePaper

automatically exploiting cross-invocation parallelism using runtime ...

automatically exploiting cross-invocation parallelism using runtime ... automatically exploiting cross-invocation parallelism using runtime ...

dataspace.princeton.edu
from dataspace.princeton.edu More from this publisher
13.07.2015 Views

takes up to 200MB memory space.To detect misspeculation, the checker thread needs the memory access signatures, theworker thread’s epoch and task numbers and the epoch and task numbers of the otherworker threads when the task began. After sending the data to the checker thread, a workerthread may stall to wait for other worker threads if continuing execution would exceed thespeculative range. In Figure 4.6, thread 4 stalls after executing task . When thread4 tries to start task , it determines the distance to thread 3’s task is three. Inthe example, the speculative range limit is two, so thread 4 stalls until thread 3 finishes task. The example is simplified, since in real programs the speculative range is alwaysat least the number of threads and usually much larger.There are two subtle memory consistency issues with the checking scheme describedabove. First, the checking scheme assumes that updates to the epoch and task numberswill be globally visible after all other stores in the previous task. If the memory consistencymodel allows the architecture to reorder stores, this assumption will be false. In otherwords, the checking methodology assumes a Total Store Order (TSO) architecture. ModernTSO architectures include: x86, x86-64, SPARC, and the IBM zSeries [41]. For architecturesthat do not support TSO, such as ARM and POWER, each thread should execute amemory fence before updating the epoch and task numbers. The costs of memory fencesmay be greater than the costs of speculative barriers when the number of tasks per epoch ishigh.Second, the epoch and task numbers must update together atomically. The easiest wayto accomplish this is to store these numbers as the high and low bits of a 64-bit word anduse an atomic write operation. For x86-64, 64-bit writes are atomic by default, so no specialhandling is required.62

log entriesWorker1 Log...Worker2 Log...epoch1epoch2epochNtask1task2task3s1.1 s1.2 s1.3s2.1.......................................taskM...task1task2task3s1.1 s1.2 epoch1.......................................taskM...epoch2epochNSignature LogFigure 4.8: Data structure for Signature Log4.2.2 Checkpointing and RecoveryPeriodically, the worker threads checkpoint so that their state can be restored after misspeculation.Infrequent checkpointing reduces the overhead of the runtime system, butincreases the cost of misspeculation. SPECCROSS’s profiling library enables very low ratesof misspeculation, thus infrequent checkpointing is efficient in practice. By default, SPEC-CROSS checkpoints at every thousandth speculative barrier, though it can be re-configuredbased on program characteristics. Checkpoints act as non-speculative barriers. All workerthreads synchronize at the checkpoint waiting for the checker thread to finish all checkingrequests before the checkpoint, ensuring the checkpoint’s state is safe.In SPECCROSS, checkpointing is divided into two parts. SPECCROSS first saves theregister state of each thread, and then saves the memory of the entire process. The Cstandard library’s setjmp function is used to save the register state of each thread. Aftereach thread is saved, the process forks, duplicating the state of the entire process. Thenewly forked child sleeps until the checker thread detects misspeculation. To restore a63

log entriesWorker1 Log...Worker2 Log...epoch1epoch2epochNtask1task2task3s1.1 s1.2 s1.3s2.1.......................................taskM...task1task2task3s1.1 s1.2 epoch1.......................................taskM...epoch2epochNSignature LogFigure 4.8: Data structure for Signature Log4.2.2 Checkpointing and RecoveryPeriodically, the worker threads checkpoint so that their state can be restored after misspeculation.Infrequent checkpointing reduces the overhead of the <strong>runtime</strong> system, butincreases the cost of misspeculation. SPECCROSS’s profiling library enables very low ratesof misspeculation, thus infrequent checkpointing is efficient in practice. By default, SPEC-CROSS checkpoints at every thousandth speculative barrier, though it can be re-configuredbased on program characteristics. Checkpoints act as non-speculative barriers. All workerthreads synchronize at the checkpoint waiting for the checker thread to finish all checkingrequests before the checkpoint, ensuring the checkpoint’s state is safe.In SPECCROSS, checkpointing is divided into two parts. SPECCROSS first saves theregister state of each thread, and then saves the memory of the entire process. The Cstandard library’s setjmp function is used to save the register state of each thread. Aftereach thread is saved, the process forks, duplicating the state of the entire process. Thenewly forked child sleeps until the checker thread detects misspeculation. To restore a63

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!