1

Computer Architecture Research OverviewFocus on: Transactional Memory

Rajeev Balasubramonian

School of Computing, University of Utahhttp://www.cs.utah.edu/~rajeev

2

What is Computer Architecture?

To a large extent, computer architecture determines:

• the number of instructions used to execute a program

• the time each instruction takes to execute

• the idle cycles when no work gets done

• the number of instructions that can execute in parallel

3

The Best Chip in 2004

P4 –like Core

2MB L2 Cache

2004 2010

4

The Advent of Multi-Core Chips

• In the past, performance magically increased by 50% every year• In the future, this improvement will be only ~20% every year … unless … the application is multi-threaded!

Core

Cache bank

5

Upcoming Architecture Challenges

• Improving single core performance

• Functionalities in multi-core chips

• Simplifying the programmer’s task

• Efficient interconnects and on-chip communication

• Power and temperature-efficient designs

• Designs tolerant of errors

For publications, see http://www.cs.utah.edu/~rajeev/research.html

6

Multi-Threaded Applications

• Parallel or multi-threaded applications are difficult to write: lots of co-ordination and data exchange between threads (referred to as synchronization)

Example:Banking Database

Alice & Bob’s joint account: $1000

ATM 1

Alice: Deposit $100

ATM 2

Bob: Deposit $100

7

Multi-Threaded Applications

Banking Database

Alice & Bob’s joint account: $1000

ATM 1

Alice: Deposit $100

ATM 2

Bob: Deposit $100

Rd balance -- $1000 Rd balance -- $1000

Update balance -- $1100 Update balance -- $1100

Write balance -- $1100 Write balance -- $1100

$1000

$1000 $1100$1100 $1000

$1100 $1100

8

Synchronization with Locks

Bank: lock(L1); read balance; calculate interest; update balance; unlock(L1);

ATM-withdraw: lock(L1); read balance; decrement; update balance; unlock(L1);

ATM-deposit: lock(L1); read balance; increment; update balance; unlock(L1);

Each snippet executesatomically, as if it is theonly process in the system

9

Problems with Locks

• Deadlocks!

lock(L1); lock(L2); … unlock(L2); unlock(L1);

lock(L2); lock(L1); … unlock(L1); unlock(L2);

10

Problems with Locks

• Performance inefficiencies!

lock(L1); if (condt1) traverse linked list till you find the entry if (condt2) sell the ticket unlock(L1);

11

Transactions

• New paradigm to simplify programming instead of lock-unlock, use transaction begin-end

• Can yield better performance; Eliminates deadlocks

• Programmer can freely encapsulate code sections within transactions and not worry about the impact on performance and correctness

• Programmer specifies the code sections they’d like to see execute atomically – the hardware takes care of the rest (provides illusion of atomicity)

12

Transactions

• Transactional semantics: when a transaction executes, it is as if the rest of the system is suspended and the transaction is in isolation the reads and writes of a transaction happen as if they are all a single atomic operation if the above conditions are not met, the transaction fails to commit (abort) and tries again

transaction begin read shared variables arithmetic write shared variables transaction end

13

Applications

• A transaction executes speculatively in the hope that there will be no conflicts

• Can replace a lock-unlock pair with a transaction begin-end the lock is blocking, the transaction is not programmers can conservatively introduce transactions without worsening performance

lock (lock1) transaction begin read A read A operations operations write A write A unlock (lock1) transaction end

14

Example 1

lock (lock1) counter = counter + 1; unlock (lock1)

transaction begin counter = counter + 1; transaction end

No apparent advantage to using transactions (apart from fault resiliency)

15

Example 2

Producer-consumer relationships – producers place tasks at the tail of a work-queue and consumers pull tasks out of the head

Enqueue Dequeue transaction begin transaction begin if (tail == NULL) if (head->next == NULL) update head and tail update head and tail else else update tail update head transaction end transaction end

With locks, neither thread can proceed in parallel since head/tail may be updated – with transactions, enqueue and dequeue can proceed in parallel – transactions will be aborted only if the queue is nearly empty

16

Detecting Conflicts – Basic Implementation

• When a transaction does a write, do not update memory; save the new value in cache and keep track of all modified lines (if the transaction is aborted, invalidate these lines)

• Also keep track of all the cache lines read by the transaction

• When another transaction commits, compare its write set with your own read set – a match causes an abort

• At transaction end, express intent to commit, broadcast write-set

17

Key Problem

• At the end of the transaction, the transaction’s writes are broadcast – the commit does not happen until everyone that needs to see the writes has seen them

• Broadcasts are not scalable! In a multi-core with 64 processors, 63 other transactions may have to wait while one transaction is busy broadcasting its writes

• Need efficient algorithms to handle a commit and need clever design of on-chip networks to improve speed/power

18

Algorithm 1 – Sequential

• Distribute memory into N nodes – each transaction keeps track of the nodes that are read and written

P1 – T1 P2 – T2 PN – TN

M1 M2 MN

• If two transactions touch different nodes, they can commit in parallel• If two transactions happen to touch the same node, they must be aware of each other in case one has to abort

Algorithm designed by Seth Pugsley, Junior in the CS programSee tech report at http://www.cs.utah.edu/~rajeev/pubs/tr-07-016.pdf

19

Algorithm 1 – Sequential

• Each transaction attempts to occupy the nodes in its commit set in ascending order – a node can be occupied by only one transaction• Must wait if another transaction has occupied the node; once all nodes are occupied, can proceed with commit

P1 – T1 P2 – T2 PN – TN

M1 M2 MN

Example 1: T1: nodes 1, 4, 7 T2: nodes 3, 4, 8

Example 2: T1: nodes 1, 4, 7 T2: nodes 3, 5, 8

20

Algorithm 1 – Sequential

• Cannot have hardware deadlocks: since nodes are occupied in increasing order, a transaction is always waiting for a transaction that is further ahead – cannot have a cycle of dependences

• If transactions usually do not pose conflicts for nodes, multiple transactions can commit in parallel

• Disadvantages: must occupy nodes sequentially, conflicts lead to long delays

21

Algorithm 2 – Speculative

• Attempt to occupy every node in the commit set in parallel – if any node is already occupied, revert back to the sequential algorithm (else, can lead to deadlocks)

• Should typically perform no worse than the sequential algorithm

22

Algorithm 3 – Momentum

• Attempt to occupy nodes in parallel – every request has a momentum value to indicate how many nodes have already been occupied by the transaction

• If a transaction finds that a node is already occupied, it can attempt to steal occupancy if it has a higher momentum

• The system is deadlock- and livelock-free (the transaction with the highest momentum at any time has a path to completion)

23

Interconnects as a Bottleneck

• In the past, on-chip data transmission on wires cost almost nothing

• Interconnect speed and power has been improving, but not at the same rate as transistor speeds

Hence, relative to computation, communication is much more expensive

• In the near future, it will take 100 cycles to travel across the chip

• 50% of chip power can be attributed to interconnects

24

On-Going Explorations

• For the various on-chip communications just described, what is the optimal on-chip network?

• What topology works best? What router microarchitecture is most efficient in terms of performance and power?

• What wires work best? Depends on criticality of specific data transfer…

25

To Learn More…

• CS/EE 3810: Computer Organization

• CS/EE 6810: Computer Architecture

• CS/EE 7810: Advanced Computer Architecture

• CS/EE 7820: Parallel Computer Architecture

• CS 7937 / 7940: Architecture Reading Seminar

26

Title

• Bullet