Self-Tuning Intel TSX 3rd Euro-TM Workshop on Transactional Memory - - PowerPoint PPT Presentation

Self-Tuning Intel TSX

Nuno Diegues and Paolo Romano 3rd Euro-TM Workshop on Transactional Memory

to appear on the 11th USENIX ICAC 2014

Using TSX

_xbegin

• // your transactional code
• _xend

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

• Data contention
• Forbidden

instructions

• Hardware buffers’

capacity

• Signals and faults

Using TSX

_xbegin

• // your transactional code
• _xend

May Abort

• Data contention
• Forbidden

instructions

• Hardware buffers’

capacity

• Signals and faults

Transparently Restarts

Using TSX

Best-effort nature we cannot rely exclusively on TSX

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code

• goto begin
• code:

// your transactional code

• _xend

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code

• goto begin
• code:

// your transactional code

• _xend
• goto code

// fast path

• _xend

// fast path

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code

• goto begin
• code:

// your transactional code

• _xend
• goto code

// fast path

• _xend

// fast path

• begin:

unsigned int status = _xbegin if (status == ok) goto code // fast path if (shouldRetry) // retry policy goto begin

• code:

// your transactional code

• if (shouldRetry)

_xend // fast path

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code

• goto begin
• code:

// your transactional code

• _xend
• goto code

// fast path

• _xend

// fast path

• begin:

unsigned int status = _xbegin if (status == ok) goto code // fast path if (shouldRetry) // retry policy goto begin

• code:

// your transactional code

• if (shouldRetry)

_xend // fast path

• begin:

unsigned int status = _xbegin if (status == ok) goto code // fast path if (shouldRetry) // retry policy goto begin else acquire(lock) // fallback

• code:

// your transactional code

• if (shouldRetry)

_xend // fast path else release(lock) // fallback

Best-effort nature

Not *that* specific to Intel TSX. IBM HTMs apply partly here too

begin: unsigned int status = _xbegin if (status == ok) goto code

• goto begin
• code:

// your transactional code

• _xend
• goto code

// fast path

• _xend

// fast path

• begin:

unsigned int status = _xbegin if (status == ok) goto code // fast path if (shouldRetry) // retry policy goto begin

• code:

// your transactional code

• if (shouldRetry)

_xend // fast path

• begin:

unsigned int status = _xbegin if (status == ok) goto code // fast path if (shouldRetry) // retry policy goto begin else acquire(lock) // fallback

• code:

// your transactional code

• if (shouldRetry)

_xend // fast path else release(lock) // fallback

Transactions need to be aware of this

Summary of issues

• Lemming effect
• Number of attempts
• Retry policy
• Management of fall-back

Summary of issues

1 2 3 1 2 3 4 5 6 7 8

speedup threads GCC (Possible) Self-Tuning

none-giveup-1 aux-giveup-3 wait-giveup-4 wait-stubborn-4 wait-stubborn-4 wait-half-8 wait-half-11 wait-stubborn-11

Genome from STAMP suite

Number of attempts

1 2 4 2 4 6 12 14 16 speedup retries high contention low contention

Kmeans from STAMP

Number of attempts

1 2 4 2 4 6 12 14 16 speedup retries high contention low contention

Kmeans from STAMP G r a d i e n t D e s c e n t

• f
• r

e x p l

• r

a t i

• n

Gradient Descent

tuning the number of attempts

#attempts performance

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1

randomly search some direction; explore it while profitable

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2

randomly search some direction; explore it while profitable

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

randomly search some direction; explore it while profitable

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable randomly search some direction; explore it while profitable

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable

threshold for stabilization

randomly search some direction; explore it while profitable

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable

threshold for stabilization

randomly search some direction; explore it while profitable random jumps to avoid local minima

5

random jump

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable

threshold for stabilization

randomly search some direction; explore it while profitable random jumps to avoid local minima

5

random jump

6

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable

threshold for stabilization

randomly search some direction; explore it while profitable random jumps to avoid local minima

5

random jump

6 7

?

• ptimization

round

Gradient Descent

tuning the number of attempts

#attempts performance

1 2 3 4

revert direction when not profitable

threshold for stabilization

randomly search some direction; explore it while profitable random jumps to avoid local minima

5

random jump

6 7

recover from unlucky jumps memorize maxima

?

• ptimization

round

Retry policy

• Give up on capacity aborts?
• How should we “consume” the attempts’ budget?
• How to manage the fall-back?

Retry policy

R e i n f

• r

c e m e n t l e a r n i n g

• U

p p e r C

• n

fi d e n c e B

• u

n d

UCB

tuning the retry policy

Lever A Lever B Lever C

? ? ?

UCB

tuning the retry policy

Lever A Lever B Lever C

A quest for exploration vs benefit from current knowledge ? ? ?

UCB

tuning the retry policy

Lever A Lever B Lever C

A quest for exploration vs benefit from current knowledge UCB adapts the strategy to maximize reward Logarithmic bound on the optimization error ? ? ?

UCB

tuning the retry policy

Model the belief about capacity aborts:

• giveup — exhaust attempts
• half — drops half the attempts
• stubborn — decrements attempts

Reward: function of processor cycles (RDTSC)

Adaptation

• f one atomic block in Yada

Adaptation

• f one atomic block in Yada
• ptimizers

are *not* independent

Transparency to the User

atomic_begin

fetch atomic block's stats yes no

fetch last configuration Profile cycles Begin Tx procedure atomic_end

execute atomic block

End Tx Procedure

Re-optimize?

application logic

Profile cycles

Run grad() Run ucb()

changes next configuration yes no continue program govern retry management abort retry

Re-optimize?

gcc libitm gcc libitm

Transparency to the User

atomic_begin

fetch atomic block's stats yes no

fetch last configuration Profile cycles Begin Tx procedure atomic_end

execute atomic block

End Tx Procedure

Re-optimize?

application logic

Profile cycles

Run grad() Run ucb()

changes next configuration yes no continue program govern retry management abort retry

Re-optimize?

gcc libitm gcc libitm

Transparency to the User

atomic_begin

fetch atomic block's stats yes no

fetch last configuration Profile cycles Begin Tx procedure atomic_end

execute atomic block

End Tx Procedure

Re-optimize?

application logic

Profile cycles

Run grad() Run ucb()

changes next configuration yes no continue program govern retry management abort retry

Re-optimize?

gcc libitm gcc libitm

Summary of Evaluation

Summary of Evaluation

Peek view on results

1 2 3 4 1 2 3 4 5 6 7 8

“ideal” self-tuning

speedup

threads

Intruder from STAMP

1 2 3 5 20 25 throughput (1000 txs/sec) execution time (sec) GCC Heuristic AdaptiveLocks Tuner

benchmark finished

Peek view on results

Yada with 8 threads

Summary

• Best-effort HTMs need proper tuning
• No one-size fits all
• We used lightweight exploration/learning techniques
• Transparent to the programmer

Self-Tuning Intel TSX

Nuno Diegues and Paolo Romano

Thank you!

Questions?

to appear on the 11th USENIX ICAC 2014