1. CS 3214 Computer Systems Godmar Back Lecture 10

2. Announcements Stay tuned for Exercise 5 Project 2 due Sep 30 Auto-fail rule 2: –Need at least Firecracker to blow up to pass class. CS 3214 Fall 2010

3. Lessons so far (1) Does not matter how many local variables or temporaries you introduce Does not matter if you use constants, expressions, or const local variables, or write-once local variables –So optimize for readability, not the compiler Does not matter how many pointer derefs you have in your code (*, [ ], ->) as long as there’s no intervening write/store to memory –If there is, compiler must repeat the ‘load’ –Avoid introducing ‘stores’ by introducing local temporaries that defer the write to memory whenever possible Don’t rewrite array code into pointer form CS 3214 Fall 2010

4. Lessons so far (2) Inlining changes the game substantially –Compiler will aggressively inline functions whose definitions occur in same compilation unit –Does not matter if declared ‘static’ or not; but must be static if included in multiple files to avoid multiple strong symbols Can remove abstraction penalty entirely in many cases –No need for manual inlining, using macros Inlining can generate better code because it enables optimizations not possible without knowing the caller: –potential for aliasing of pointer arguments may be reduced, allowing for more precise and less-conservative points-to analysis –May be able to remove bounds-checks even (next slide) Caveat: inlining is not possible if target of the call is not known to the compiler –E.g. non-final, non-private methods in Java, or “virtual” methods in C++; so declare your methods final or private in Java whenever possible CS 3214 Fall 2010

5. MACHINE-DEPENDENT OPTIMIZATIONS CS 3214 Fall 2010

6. Roadmap for this lecture Techniques to be discussed: –Loop unrolling –Use of multiple accumulators –Reassociation –Branch avoidance –Branch hinting Concepts: –Pipelined execution –Out of order execution/dataflow view –Branch prediction CS 3214 Fall 2010

7. Example: Compute Factorials Machines –Intel Pentium 4 Nocona, 3.2 GHz –Intel Core 2, 2.7 GHz Compiler Versions –GCC 3.4.2 int rfact(int n) { if (n <= 1) return 1; return n * rfact(n-1); } int fact(int n) { int i; int result = 1; for (i = n; i > 0; i--) result = result * i; return result; } MachineNoconaCore 2 rfact 15.56.0 fact10.03.0 Cycles per element (or per mult) CS 3214 Fall 2010

8. Optimization 1: Loop Unrolling Compute more values per iteration Does not help here Why? Branch prediction – details later int fact_u3a(int n) { int i; int result = 1; for (i = n; i >= 3; i-=3) { result = result * i * (i-1) * (i-2); } for (; i > 0; i--) result *= i; return result; } MachineNoconaCore 2 rfact15.56.0 fact10.03.0 fact_u3a10.03.0 Cycles per element (or per mult) CS 3214 Fall 2010

9. Optimization 2: Multiple Accumulators That seems to help. Can one get even faster? Explanation: instruction level parallelism int fact_u3b(int n) { int i; int result0 = 1; int result1 = 1; int result2 = 1; for (i = n; i >= 3; i-=3) { result0 *= i; result1 *= (i-1); result2 *= (i-2); } for (; i > 0; i--) result0 *= i; return result0 * result1 * result2; } MachineNoconaCore 2 rfact15.56.0 fact10.03.0 fact_u3a10.03.0 fact_u3b3.31.0 Cycles per element (or per mult) CS 3214 Fall 2010

10. Modern CPU Design Execution Functional Units Instruction Control Integer/ Branch FP Add FP Mult/Div LoadStore Instruction Cache Data Cache Fetch Control Instruction Decode Address Instructions Operations Prediction OK? Data Addr. General Integer Operation Results Retirement Unit Register File Register Updates CS 3214 Fall 2010

11. Superscalar Processor Definition: A superscalar processor can issue and execute multiple instructions in one cycle. The instructions are retrieved from a sequential instruction stream and are usually scheduled dynamically. Benefit: without programming effort, superscalar processor can take advantage of the instruction level parallelism that most programs have Most CPUs since about 1998 are superscalar. Intel: since Pentium Pro CS 3214 Fall 2010

12. Pentium 4 Nocona CPU Multiple instructions can execute in parallel 1 load, with address computation 1 store, with address computation 2 simple integer (one may be branch) 1 complex integer (multiply/divide) 1 FP/SSE3 unit 1 FP move (does all conversions) Some instructions take > 1 cycle, but can be pipelined InstructionLatencyCycles/Issue Load / Store51 Integer Multiply101 Integer/Long Divide36/10636/106 Single/Double FP Multiply72 Single/Double FP Add52 Single/Double FP Divide32/4632/46 CS 3214 Fall 2010

13. Latency versus Throughput Last slide: latencycycles/issue Integer Multiply101 Step 1 1 cycle Step 2 1 cycle Step 10 1 cycle Consequence: How fast can 10 independent int mults be executed? t1 = t2*t3; t4 = t5*t6; … How fast can 10 sequentially dependent int mults be executed? t1 = t2*t3; t4 = t5*t1; t6 = t7*t4; … Major problem for fast execution: Keep pipelines filled CS 3214 Fall 2010

14. Hard Bounds How many cycles at least if –Function requires n int mults? –Function requires n float adds? –Function requires n float ops (adds and mults)? Latency and throughput of instructions InstructionLatencyCycles/Issue Load / Store51 Integer Multiply101 Integer/Long Divide36/10636/106 Single/Double FP Multiply72 Single/Double FP Add52 Single/Double FP Divide32/4632/46 CS 3214 Fall 2010

15. Aside: Performance in Numerical Computing Numerical computing = computing dominated by floating point operations Example: Matrix multiplication Performance measure: Floating point operations per second (flop/s) –Counting only floating point adds and mults –Higher is better –Like inverse runtime Often used to compute theoretical peak performance CS 3214 Fall 2010

16. Nocona vs. Core 2 Nocona (3.2 GHz) InstructionLatencyCycles/Issue Load / Store51 Integer Multiply101 Integer/Long Divide36/10636/106 Single/Double FP Multiply72 Single/Double FP Add52 Single/Double FP Divide32/4632/46 Core 2 (2.7 GHz) (Recent Intel microprocessors) InstructionLatencyCycles/Issue Load / Store51 Integer Multiply31 Integer/Long Divide18/5018/50 Single/Double FP Multiply4/51 Single/Double FP Add31 Single/Double FP Divide18/3218/32 CS 3214 Fall 2010

17. Instruction Control Grabs instruction bytes from memory –Based on current PC + predicted targets for predicted branches –Hardware dynamically guesses whether branches taken/not taken and (possibly) branch target Translates instructions into micro-operations (for CISC style CPUs) –Micro-op = primitive step required to perform instruction –Typical instruction requires 1–3 operations Converts register references into tags –Abstract identifier linking destination of one operation with sources of later operations Instruction Control Instruction Cache Fetch Control Instruction Decode Address Instructions Operations Retirement Unit Register File CS 3214 Fall 2010

18. Translating into Micro-Operations Goal: Each operation utilizes single functional unit –Requires: Load, integer arithmetic, store –Exact form and format of operations is trade secret imulq %rax, 8(%rbx,%rdx,4) load 8(%rbx,%rdx,4)  temp1 imulq %rax, temp1  temp2 store temp2, 8(%rbx,%rdx,4) CS 3214 Fall 2010

19. Traditional View of Instruction Execution Imperative View –Registers are fixed storage locations Individual instructions read & write them –Instructions must be executed in specified sequence to guarantee proper program behavior addq %rax, %rbx # I1 andq %rbx, %rdx # I2 mulq %rcx, %rbx # I3 xorq %rbx, %rdi # I4 rax + rbxrdxrcxrdi I1 I2 I3 I4 & * ^ CS 3214 Fall 2010

20. Dataflow View of Instruction Execution Functional View –View each write as creating new instance of value –Operations can be performed as soon as operands available –No need to execute in original sequence rax.0 + rbx.0rdx.0rcx.0rdi.0 I1 I2/I3 I4 * ^ rbx.1 rdx.1 rbx.2 rdi.1 addq %rax, %rbx # I1 andq %rbx, %rdx # I2 mulq %rcx, %rbx # I3 xorq %rbx, %rdi # I4 & CS 3214 Fall 2010

21. Previous Best Combining Code Let’s return to our example Task –Compute sum of all elements in vector –Vector represented by C-style abstract data type –Achieved CPE of 2.00 Cycles per element void combine4(vec_ptr v, int *dest) { int i; int length = vec_length(v); int *data = get_vec_start(v); int sum = 0; for (i = 0; i < length; i++) sum += data[i]; *dest = sum; } CS 3214 Fall 2010

22. General Forms of Combining Data Types –Use different declarations for data_t –int –float –double void abstract_combine4(vec_ptr v, data_t *dest) { int i; int length = vec_length(v); data_t *data = get_vec_start(v); data_t t = IDENT; for (i = 0; i < length; i++) t = t OP data[i]; *dest = t; } Operations –Use different definitions of OP and IDENT – + / 0 – * / 1 CS 3214 Fall 2010

23. Impact of machine-independent optimizations (for Pentium III) Optimizations –Reduce non-inlined function calls and memory references within loop Performance Anomaly –Computing FP product of all elements exceptionally slow. –Very large speedup when accumulate in temporary –Caused by quirk of IA32 floating point Memory uses 64-bit format, register use 80 Benchmark data caused overflow of 64 bits, but not 80 CS 3214 Fall 2010

24. Example Computation Data Types –Use different declarations for data_t –int –float –double void combine4(vec_ptr v, data_t *dest) { int i; int length = vec_length(v); data_t *d = get_vec_start(v); data_t t = IDENT; for (i = 0; i < length; i++) t = t OP d[i]; *dest = t; } Operations –Use different definitions of OP and IDENT – + / 0 – * / 1 d[1] OP d[2] OP d[3] OP … OP d[length-1] CS 3214 Fall 2010

25. x86-64 Compilation of Combine4 Inner Loop (Case: Integer Multiply) L33: # Loop: movl (%eax,%edx,4), %ebx # temp = d[i] incl %edx # i++ imull %ebx, %ecx # x *= temp cmpl %esi, %edx # i:length jl L33 # if < goto Loop void combine4(vec_ptr v, data_t *dest) { int i; int length = vec_length(v); data_t *d = get_vec_start(v); data_t t = IDENT; for (i = 0; i < length; i++) t = t OP d[i]; *dest = t; } MethodInt (add/mult)Float (add/mult) combine42.210.05.07.0 bound1.0 2.0 Cycles per element (or per OP) CS 3214 Fall 2010

26. Combine4 = Serial Computation (OP = *) Computation (length=8) ((((((((1 * d[0]) * d[1]) * d[2]) * d[3]) * d[4]) * d[5]) * d[6]) * d[7]) Sequential dependence! Hence, –Performance: determined by latency of OP! * * 1d0d0 d1d1 * d2d2 * d3d3 * d4d4 * d5d5 * d6d6 * d7d7 MethodInt (add/mult)Float (add/mult) combine42.210.05.07.0 bound1.0 2.0 Cycles per element (or per OP) CS 3214 Fall 2010

27. Loop Unrolling Perform 2x more useful work per iteration void unroll2a_combine(vec_ptr v, data_t *dest) { int length = vec_length(v); int limit = length-1; data_t *d = get_vec_start(v); data_t x = IDENT; int i; /* Combine 2 elements at a time */ for (i = 0; i < limit; i+=2) { x = (x OP d[i]) OP d[i+1]; } /* Finish any remaining elements */ for (; i < length; i++) { x = x OP d[i]; } *dest = x; } CS 3214 Fall 2010

28. Effect of Loop Unrolling Helps integer sum Others don’t improve. Why? –Still sequential dependency x = (x OP d[i]) OP d[i+1]; MethodInt (add/mult)Float (add/mult) combine42.210.05.07.0 unroll21.510.05.07.0 bound1.0 2.0 CS 3214 Fall 2010

29. Loop Unrolling with Reassociation Can this change the result of the computation? Yes, for FP. Why? void unroll2aa_combine(vec_ptr v, data_t *dest) { int length = vec_length(v); int limit = length-1; data_t *d = get_vec_start(v); data_t x = IDENT; int i; /* Combine 2 elements at a time */ for (i = 0; i < limit; i+=2) { x = x OP (d[i] OP d[i+1]); } /* Finish any remaining elements */ for (; i < length; i++) { x = x OP d[i]; } *dest = x; } CS 3214 Fall 2010

30. Effect of Reassociation Nearly 2x speedup for Int *, FP +, FP * –Reason: Breaks sequential dependency –Why is that? (next slide) x = x OP (d[i] OP d[i+1]); MethodInt (add/mult)Float (add/mult) combine42.210.05.07.0 unroll21.510.05.07.0 unroll2-ra1.565.02.753.62 bound1.0 2.0 CS 3214 Fall 2010

31. Reassociated Computation What changed: –Ops in the next iteration can be started early (no dependency) Overall Performance –N elements, D cycles latency/op –Should be (N/2+1)*D cycles: CPE = D/2 –Measured CPE slightly worse for FP * * 1 * * * d1d1 d0d0 * d3d3 d2d2 * d5d5 d4d4 * d7d7 d6d6 x = x OP (d[i] OP d[i+1]); CS 3214 Fall 2010

32. Loop Unrolling with Separate Accumulators void unroll2a_combine(vec_ptr v, data_t *dest) { int length = vec_length(v); int limit = length-1; data_t *d = get_vec_start(v); data_t x0 = IDENT; data_t x1 = IDENT; int i; /* Combine 2 elements at a time */ for (i = 0; i < limit; i+=2) { x0 = x0 OP d[i]; x1 = x1 OP d[i+1]; } /* Finish any remaining elements */ for (; i < length; i++) { x0 = x0 OP d[i]; } *dest = x0 OP x1; } CS 3214 Fall 2010 Different form of reassociation

33. Effect of Separate Accumulators Almost exact 2x speedup (over unroll2) for Int *, FP +, FP * –Breaks sequential dependency in a “cleaner,” more obvious way x0 = x0 OP d[i]; x1 = x1 OP d[i+1]; MethodInt (add/mult)Float (add/mult) combine42.210.05.07.0 unroll21.510.05.07.0 unroll2-ra1.565.02.753.62 unroll2-sa1.505.02.53.5 bound1.0 2.0 CS 3214 Fall 2010

34. Separate Accumulators * * 1d1d1 d3d3 * d5d5 * d7d7 * * * 1d0d0 d2d2 * d4d4 * d6d6 x0 = x0 OP d[i]; x1 = x1 OP d[i+1]; What changed:  Two independent “streams” of operations Overall Performance  N elements, D cycles latency/op  Should be (N/2+1)*D cycles: CPE = D/2  CPE matches prediction! CS 3214 Fall 2010

35. Unrolling & Accumulating Idea –Can unroll to any degree L –Can accumulate K results in parallel –L must be multiple of K Limitations –Diminishing returns Cannot go beyond throughput limitations of execution units –Large overhead for short lengths Finish off iterations sequentially CS 3214 Fall 2010

36. Unrolling & Accumulating: Intel FP * Case –Intel Nocona –FP Multiplication –Theoretical Limit: 2.00 FP *Unrolling Factor L K1234681012 17.00 7.017.00 23.50 32.34 42.012.00 6 2.01 8 102.00 122.00 Accumulators CS 3214 Fall 2010

37. Unrolling & Accumulating: Intel FP + Case –Intel Nocona –FP Addition –Theoretical Limit: 2.00 FP +Unrolling Factor L K1234681012 15.00 5.025.00 22.502.51 32.00 42.012.00 6 1.99 82.01 102.00 122.00 CS 3214 Fall 2010

38. Unrolling & Accumulating: Intel Int * Case –Intel Nocona –Integer Multiplication –Theoretical Limit: 1.00 Int *Unrolling Factor L K1234681012 110.00 10.01 25.005.015.00 33.33 42.502.51 61.67 81.25 101.09 121.14 CS 3214 Fall 2010

39. Unrolling & Accumulating: Intel Int + Case –Intel Nocona –Integer addition –Theoretical Limit: 1.00 (unrolling enough) Int +Unrolling Factor L K1234681012 12.201.501.101.03 21.501.101.03 31.34 41.091.03 61.01 81.03 101.04 121.11 CS 3214 Fall 2010

40. FP *: Nocona versus Core 2 Machines –Intel Nocona 3.2 GHz –Intel Core 2 2.7 GHz Performance –Core 2 lower latency & fully pipelined (1 cycle/issue) FP *Unrolling Factor L K1234681012 14.00 4.01 22.00 31.34 41.00 6 8 101.00 121.00 FP *Unrolling Factor L K1234681012 17.00 7.017.00 23.50 32.34 42.012.00 6 2.01 8 102.00 122.00

41. Nocona vs. Core 2 Int * Performance –Newer version of GCC does reassociation –Why for int’s and not for float’s? Int *Unrolling Factor L K1234681012 13.001.501.00 21.501.00 3 4 6 8 101.00 121.33 Int *Unrolling Factor L K1234681012 110.00 10.01 25.005.015.00 33.33 42.502.51 61.67 81.25 101.09 121.14 CS 3214 Fall 2010

42. Intel vs. AMD FP * Machines –Intel Nocona 3.2 GHz –AMD Opteron 2.0 GHz Performance –AMD lower latency & better pipelining –But slower clock rate CS 3214 Fall 2010

43. Intel vs. AMD Int * Performance –AMD multiplier much lower latency –Can get high performance with less work –Doesn’t achieve as good an optimum CS 3214 Fall 2010

44. Intel vs. AMD Int + Performance –AMD gets below 1.0 –Even just with unrolling Explanation –Both Intel & AMD can “double pump” integer units –Only AMD can load two elements / cycle CS 3214 Fall 2010

45. Limitations of Parallel Execution Need Lots of Registers –To hold sums/products –IA32: only 6 usable integer registers Also needed for pointers, loop conditions –8 FP registers –When not enough registers, must spill temporaries onto stack Wipes out any performance gains –Not helped by internal renaming Cannot reference more operands than instruction set allows Major drawback of IA32 instruction set CS 3214 Fall 2010

46. Register Spilling Example Example –8 X 8 integer product –7 local variables share 1 register –See that are storing locals on stack –E.g., at -8(%ebp).L165: imull (%eax),%ecx movl -4(%ebp),%edi imull 4(%eax),%edi movl %edi,-4(%ebp) movl -8(%ebp),%edi imull 8(%eax),%edi movl %edi,-8(%ebp) movl -12(%ebp),%edi imull 12(%eax),%edi movl %edi,-12(%ebp) movl -16(%ebp),%edi imull 16(%eax),%edi movl %edi,-16(%ebp) … addl $32,%eax addl $8,%edx cmpl -32(%ebp),%edx jl.L165 CS 3214 Fall 2010

47. What About Branches? Challenge –Instruction Control Unit must work well ahead of Execution Unit to generate enough operations to keep EU busy –When encounters conditional branch, cannot reliably determine where to continue fetching 80489f3:movl $0x1,%ecx 80489f8:xorl %edx,%edx 80489fa:cmpl %esi,%edx 80489fc:jnl 8048a25 80489fe:movl %esi,%esi 8048a00:imull (%eax,%edx,4),%ecx Executing How to continue? CS 3214 Fall 2010

48. Branch Outcomes –When encounter conditional branch, cannot determine where to continue fetching Branch Taken: Transfer control to branch target Branch Not-Taken: Continue with next instruction in sequence –Cannot resolve until outcome determined by branch/integer unit 80489f3:movl $0x1,%ecx 80489f8:xorl %edx,%edx 80489fa:cmpl %esi,%edx 80489fc:jnl 8048a25 80489fe:movl %esi,%esi 8048a00:imull (%eax,%edx,4),%ecx Branch Taken Branch Not-Taken CS 3214 Fall 2010 8048a25:cmpl %edi,%edx 8048a27:jl 8048a20 8048a29:movl 0xc(%ebp),%eax 8048a2c:leal 0xffffffe8(%ebp),%esp 8048a2f:movl %ecx,(%eax)

49. Branch Prediction Idea –Guess which way branch will go –Begin executing instructions at predicted position But don’t actually modify register or memory data 80489f3:movl $0x1,%ecx 80489f8:xorl %edx,%edx 80489fa:cmpl %esi,%edx 80489fc:jnl 8048a25... 8048a25:cmpl %edi,%edx 8048a27:jl 8048a20 8048a29:movl 0xc(%ebp),%eax 8048a2c:leal 0xffffffe8(%ebp),%esp 8048a2f:movl %ecx,(%eax) Predict Taken Begin Execution CS 3214 Fall 2010

50. Branch Prediction Through Loop 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 i = 98 i = 99 i = 100 Predict Taken (OK) Predict Taken (Oops) 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 i = 101 Assume vector length = 100 Read invalid location Executed Fetched CS 3214 Fall 2010

51. Branch Misprediction Invalidation 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 i = 98 i = 99 i = 100 Predict Taken (OK) Predict Taken (Oops) 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx i = 101 Invalidate Assume vector length = 100 CS 3214 Fall 2010

52. Branch Misprediction Recovery Performance Cost –Multiple clock cycles on modern processor –Can be a major performance limiter 80488b1:movl (%ecx,%edx,4),%eax 80488b4:addl %eax,(%edi) 80488b6:incl %edx 80488b7:cmpl %esi,%edx 80488b9:jl 80488b1 80488bb:leal 0xffffffe8(%ebp),%esp 80488be:popl %ebx 80488bf:popl %esi 80488c0:popl %edi i = 99 Definitely not taken CS 3214 Fall 2010

53. Determining Misprediction Penalty Failed attempt GCC/x86-64 tries to minimize use of Branches –Generates conditional moves when possible/sensible int cnt_gt = 0; int cnt_le = 0; int cnt_all = 0; int choose_cmov(int x, int y) { int result; if (x > y) { result = cnt_gt; } else { result = cnt_le; } ++cnt_all; return result; } choose_cmov: cmpl %esi, %edi # x:y movl cnt_le(%rip), %eax # r = cnt_le cmovg cnt_gt(%rip), %eax # if >= r=cnt_gt incl cnt_all(%rip) # cnt_all++ ret # return r CS 3214 Fall 2010

54. Forcing Conditional Cannot use conditional move when either outcome has side effect int cnt_gt = 0; int cnt_le = 0; int choose_cond(int x, int y) { int result; if (x > y) { result = ++cnt_gt; } else { result = ++cnt_le; } return result; } CS 3214 Fall 2010 choose_cond: cmpl %esi, %edi jle.L8 movl cnt_gt(%rip), %eax incl %eax movl %eax, cnt_gt(%rip) ret.L8: movl cnt_le(%rip), %eax incl %eax movl %eax, cnt_le(%rip) ret If Then Else

55. Testing Methodology Idea –Measure procedure under two different prediction probabilities P = 1.0: Perfect prediction P = 0.5: Random data Test Data –x = 0, y =  1 Case +1: y = [+1, +1, +1, …, +1, +1] Case − 1: y = [ − 1, − 1, − 1, …, − 1, − 1] Case A: y = [+1, − 1, +1, …, +1, − 1] (alternate) Case R: y = [+1, − 1, − 1, …, − 1, +1] (random) CS 3214 Fall 2010

56. Testing Outcomes Observations: –Conditional move insensitive to data –Perfect prediction for regular patterns Else case requires 6 (Nocona), 2 (AMD), or 1 (Core 2) extra cycles Averages to 15.2 –Branch penalties: (for R, processor will get it right half of the time) Nocona: 2 * (31.2-15.2) = 32 cycles AMD: 2 * (15.7-9.2) = 13 cycles Core 2: 2 * (17.7-8.7) = 18 cycles Casecmovcond +112.318.2 −112.312.2 A12.315.2 R12.331.2 Casecmovcond +18.0510.1 −18.058.1 A8.059.2 R8.0515.7 Intel NoconaAMD Opteron Casecmovcond +17.179.2 −17.178.2 A7.178.7 R7.1717.7 Intel Core 2 CS 3214 Fall 2010

57. Branch Prediction Strategies Most Intel processors use “forward branch not taken, backward branch taken” for first time a branch is seen –Even if done always, fits loops well – misprediction penalty paid only during last iteration –May be augmented by branch history buffer Some architectures have “hinted branch” instructions where likely direction is encoded in instruction word User-guided branch hinting –GCC: __builtin_expect(expr, value) CS 3214 Fall 2010

58. Branch Hinting CS 3214 Fall 2010 #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(x, 0) extern int g(int), h(int); int f_likely_g(int v) { return likely(v) ? g(v) : h(v); } int f_likely_h(int v) { return unlikely(v) ? g(v) : h(v); }

59. Branch Hinting CS 3214 Fall 2010 f_likely_h: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax testl %eax, %eax jne.L7 movl $0, 8(%ebp) popl %ebp jmp h.L7: popl %ebp jmp g f_likely_g: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax testl %eax, %eax je.L9 popl %ebp jmp g.L9: movl $0, 8(%ebp) popl %ebp jmp h Aside: absent user-provided branch hinting, compiler guesses which direction the branch goes and arranges code accordingly

60. Machine-Dependent Opt. Summary Pointer Code –Look carefully at generated code to see whether helpful Loop Unrolling –Some compilers do this automatically –Generally not as clever as what can achieve by hand Consider Branch Hinting Exposing Instruction-Level Parallelism –Very machine dependent –Avoid spilling –Best if performed by compiler when tuning for a particular architecture CS 3214 Fall 2010

61. Role of Programmer How should I write my programs, given that I have a good, optimizing compiler? Don’t: Smash Code into Oblivion –Hard to read, maintain & assure correctness Do: –Select best algorithm –Write code that’s readable & maintainable Use procedures, recursion, avoid built-in constant limits Even though these factors can slow down code –Eliminate optimization blockers Allows compiler to do its job CS 3214 Fall 2010