An overview of my research Paolo Romano Lisbon University & - - PowerPoint PPT Presentation
An overview of my research Paolo Romano Lisbon University & INESC-ID Roadmap About me About IST & INESC-ID An overview of my past research activities Current research lines: Transactional Memory & emerging HW
support EU project proposal preparation
Client Application Servers DBMSs
Sensing devices
Replicated sinks filter/correlate input streams and output relevant events, e.g.:
Back-end data center
(at the logical level)
modelling and optimization of complex systems
to the same bug
countries active in the área of Transactional Memory
conferences
Theory & Algorithms
Hardware & OS
Language & Tools Applications & Performance Evaluation Cross WG Activities Showcases
mechanisms
transactional systems
waste work/energy when conflicts do arise.
studied to enhance TM efficiency in unfavorable workloads
readers
Reader Writer
r-lock r(X) r-unlock r(?) w-lock w(X) w(Y) w-unlock
Begin HW Tx Commit HW Tx
Reader Writer
r-lock r(X) r-unlock r(?) w-lock w(X) w(Y) w-unlock
? = Y
Begin H/W Tx Commit H/W Tx
Reader Writer
r-lock r(X) r-unlock r(?) w-lock w(X) w(Y) w-unlock
? = Y
w-unlock
Begin H/W Tx Commit H/W Tx
Reader Writer
r-lock r(X) r-unlock r(Y) w-lock w(X) w(Y) w-unlock
abort
Begin H/W Tx Commit H/W Tx
Reader Writer
r-lock r(X) r-unlock r(?) w-lock w(X) w(Y)
Suspend HW Tx Resume HW Tx Commit HW Tx
w-unlock
Begin HW Tx
wait for concurrent readers active here
unique feature of IBM Power processors:
parallel computations:
– promise to deliver the result of some computation – eval() used to retrieve computation’s result
– unlike parallel nesting does not block “submitter” while parallel computation takes place
f=submit(task) x=f.eval() future continuation
between TF and its continuation…
submitFuture evaluateFuture T TF w(x,1) w(x,x+1) w(x,x+1) w(y,x)
submitFuture evaluateFuture T TF w(x,1) w(x,x+1) w(x,x+1) w(y,x)
between TF and its continuation?
submitFuture evaluateFuture T TF w(x,1) w(x,x+1) w(x,x+1) w(y,x)
serialization point
between TF and its continuation?
between TF and its continuation?
submitFuture evaluateFuture T TF w(x,1) w(x,x+1) w(x,x+1) w(y,x)
serialization point serialization point
dependency graphs, e.g.:
continuation of TF1 continuation of TF2
40
Here TF1 returns the reference of TF2 to T0, in order to allow T0 to evaluate TF2
41
Logic underlying definition of TF2 continuation: Sequence of causally-related operations that leads from TF2’s submission to its evaluation
42
T1 writes TF’s reference in variable x and commits. This allows a different top-level transaction, e.g. T2, to evaluate TF. TF is used as a communication means between T1 and T2.
read-after-write
43
Logic underlying definition of TF continuation: Sequence of causally-related operations that leads from TF’s submission to its evaluation
read-after-write
level transactions è strongly atomic continuation
è weakly atomic continuation
– similar in spirit to transaction serialization graph – but aimed to:
– Support only for strongly ordered futures – Transactional futures serialized solely upon submission:
è FSG encoded via a tree
innovative multi-versioned concurrency control scheme
T0 TF1 TF2 TC3 TC4 TF5 TC6 TF7 TC8
– Support for weakly ordered futures
– Novel concurrency control based on explicit management of the FSG
VT1B VTF C VTF B VT2B VTF E (VTF S)
– Transactional Memory & emerging HW technologies:
– Leveraging Symbolic Execution for Distributed Transactional Systems – Parallel/distributed platforms for Machine Learning
48
Database PM In-memory tables Durable support Database Disk RAM In-memory tables Durable support
+
Core Core Core Core Main Memory Caches
Still volatile Now persistent
49
atomic access/transactions to memory regions?
understood: decades of literature in DBMS area!
[ASPLOS’16]:
1. Lock the value 2. Log (flush) the old value 3. Do the write
1. Flush write-set 2. Add commit marker 3. Unlock values 4. Destroy log
50
begin end x ß R(X) W(X, x+2)
crash recoverability
begin end x ß R(X) W(X, x+2) log(X) commit_log
Core Core Core Core
Private Cache Private Cache Private Cache Private Cache Main Memory Shared Cache
51
On Cache On Memory (PM)
time
_xbegin _xend Concurrency is built on on cache coherency protocols [ISCA’93] Example of a story of a non-durable (and non-atomic after recovery) transaction!
W(X,1) W(Y,2) W(Z,3)
Atomically committed on cache
Crash
Y=2 Evicted
52
On Cache On Memory (PM)
time
_xbegin
W(X,1)
Abort
Log(X) clflush
STM-based solutions[ASPLOS’11, ASPLOS’16]
schemes:
53
HTM-based solutions [DISC’15, CAL’15]
Drawbacks:
than HTM!
Drawbacks:
and available capacity
54
_xbegin log(X) W(X, x+2) _xend flush_log x ß R(X)
TS ß ReadTS()
commit_log(TS)
Wait preceding transactions Non-Durable commit Durable commit
Working Snapshot logs 1 Transaction 1 logs 2 Transaction 2
log flushed only after HTM commit commit confirmed to application only after transaction’s log is fully flushed totally ordered log maintained in a decentralized fashion
ü Ensure interoperability with existing HTM systems! ü Avoid contention hot-spots to maximize scalability
55
ü Ensure interoperability with existing HTM systems! ü Avoid contention hot-spots to maximize scalability
56
persistent snapshot on PM
57
Replayed via a background process
Working Snapshot logs Transaction Persistent Snapshot
in volatile RAM in PM
Replay
ü Writes to PM are 2x-5x slower than on volatile RAM! ü Provides opportunity to filter redundant (duplicate) writes in the log
memory
58
A=3 B=5 Commit(TS=1) A=5 C=1 Commit(TS=3) Commit(TS=5) E=5 G=1 B=3 D=2 Commit(TS=2) Commit(TS=4) F=3 H=2 A B C D E F G H
Cache Line
Thread 1 Thread 2
The Checkpoint Process may follow different policies to flush the logs:
59
ü Writes to PM are 2x-5x slower than on volatile RAM! ü Provides opportunity to filter redundant (duplicate) writes in the log
memory
60
assisted Copy-on-Write mechanism:
61
Application
Empty Empty
Persistent Snapshot Working Snapshot
62
63
64
1 2 3 4 5 6 7 8 9
5 1 1 5 2 2 5 3 Throughput (x105 TXs/s) Number of threads
PSTM PHTM NV-HTMNLP NV-HTM10x
throughout
Up to ~4x greater throughput than PHTM
65
less than PSTM, while only producing 13% more writes than NV-HTMNLP Average Writes and Flushes per transaction
writes by using our filtering approach less 2.72x writes than PHTM in average less 6.72x writes than PSTM in average
transaction can be durably committed
66
– Transactional Memory & emerging HW technologies:
– Leveraging Symbolic Execution for Distributed Transactional Systems – Parallel/distributed platforms for Machine Learning
Shared Memory
TX2 TX3 TX1
Transactional Memory for CPU+GPU systems
68
1
Existing TM implementations rely on fast intra-device communication
Need to revisit the TM abstraction and consistency criteria Serial inter-device communication makes fine-grained synchronization difficult Build a system upon this new abstraction
69
warp warp
shared
SM0
1
warp warp
shared
SM1
1
Cache
execution containing only committed transactions, without contradicting real-time order.
by some sequential execution (possibly different) containing only committed transactions.
X = X + 1 Y = Y + 1
70
Commit Commit
71
72
+ Syncs global state + Fast
SHeTM instrumentation SHeTM instrumentation
CPUQ
SHeTM metadata Queueing System
GPUQ SHAREDQ
73
Transaction batching + Amortizes synchronization costs + load-balancing using a shared queue
Modular design
Dataset0
time
Dataset1
Synchronization
CPU Batch TXC1 GPU Batch TXG1
Synchronization phase constructs the new dataset
CPU and GPU work in parallel Device local TM instrumentation collects read/write sets SHeTM sees TXG1 and TXC1 as two very large transactions
Dataset2
Batch GPU TXG2 Batch CPU TXC2
Synchronization
74
collect: RSGPU + WSGPU collect: WSCPU
Execution phase Validation phase Merge phase
Dataset synchronization configurable time interval
RSGPU ∩ WSCPU = ∅
?
time transfer WS
C P U
apply WSCPU
75
transfer dataset[WSGPU ]
bmp
collect: RSGPU + WSGPU collect: WSCPU
Execution phase Validation phase Merge phase
Dataset synchronization configurable time interval
RSGPU ∩ WSCPU = ∅
?
time transfer WS
C P U
apply WSCPU
76
WSGPU
bmp
t r a n s f e r d a t a s e t [ W SGPU ]
bmp
GPU CPU Execution Validation Merge
time
Non-blocking execution WSGPU
VAL
77
VAL
Synchronization
78
GPU CPU Execution Validation Merge
time
Non-blocking execution WSGPU
VAL
79
VAL
(a) 100% update transactions
2 4 6 8 10 12 14 16 100 200 300 400 500 600
Throughput (MTX/s) Execution Phase (msec)
CPU-only GPU-only SHeTMbasic SHeTM
(b) 10% update transactions
0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 50 100 150 200 250 300 350 400
Throughput (MTX/s) Execution Phase (msec)
80
In this experiment:
GPU CPU
Execution Validation Merge time
Write intensive workloads:
still only ~25% below sum CPU+GPU performance Read intensive workloads: + SHeTM throughput is ~95% the sum CPU+GPU
20 40 60 80 100
20 40 80 120 200 300 400 500 600 20 40 80 120 200 300 400 500 600
SHeTMbasic
CPU
SHeTM
% Time
Idle Non-blocking Processing
20 40 60 80 100
20 40 80 120 200 300 400 500 600 20 40 80 120 200 300 400 500 600
SHeTMbasic
GPU
SHeTM
% Time Execution Phase (msec)
Validation DtH Processing
Figure 5. Break-down of exec. times (100% update transactions)
Significative reduction on CPU and GPU idle time:
Non optimized SHeTM Optimized SHeTM
81
Execution
GPU CPU
Validation Merge time Non-blocking execution WSGPU
82
83
GPU requests CPU requests
GPU Steal with probability X% (X=100% means that GPU
assigned to CPU) The higher the “steal” probability, the higher the inter-device contention probability
0.0 0.5 0.8 1.0 1.2 1.5 1.8 5 10 15 20 25
Throughput (wrt CPU) Concurrent Execution (ms)
GPU-only SHeTM no-conflicts SHeTM steal 20% SHeTM steal 80% SHeTM steal 100% 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 5 10 15 20 25
Probability of Commit Concurrent Execution (ms)
Execution phase (msec) Tuning the durations allows high contention workloads to still benefit from CPU+GPU
84
absence of contention
85
– Transactional Memory & emerging HW technologies:
– Leveraging Symbolic Execution for Distributed Transactional Systems – Parallel/distributed platforms for Machine Learning
Z = y * 2 y = 6
Z == 12 OK!!! FAIL!!!
Accesses umbrella_id 15, 20,25…NUM_RECORDS *5 Accesses umbrella_id 0, 2 and 4
– Scheduling – Deterministic concurrency control (State Machine Replication) – Automatic data partitioning schemes – …
– SE is sound but not complete (halting problem)
– What if program behavior depends on the DB’s state?
– Transactional Memory & emerging HW technologies:
– Leveraging Symbolic Execution for Distributed Transactional Systems – Parallel/distributed platforms for Machine Learning
– Extreme settings: fully decentralized (1 to 1)
– …and propose novel approaches to enhance efficiency of state of the art approaches
– Challenges/opportunities:
– Cartesian product of model related and cloud related parameters
– Bayesian optimization – Sub-sampling – Aborting testing of “bad” connfigurations ASAP