Performance, Concurrency and Big Data

Bart Massey 2013-11-18

Overview

  • Misc notes
  • Performance
  • Concurrency and Big Data
  • Case study

Misc Notes

Performance Optimization Overview

  • Usually not important because requirements

    • No performance requirement
    • Performance requirement easily met
    • Performance requirement unattainable

  • Most changes are not meaningful; almost always looking for minimum 2x

  • Code tuning is mostly silly; use a better language or compiler

What To Think About For Performance Up Front

  • Is there a performance requirement? Is it minimal?

  • Does the architecture look like it can meet the goal?

  • Does the language / environment have the needed performance?

  • Are the chosen algorithms likely to be OK?

  • How will performance be validated?

  • Performance only after correctness

What To Think About When Fixing A Performance Problem

  • Can the requirement change?

  • Where are the bottlenecks?

    • Can you buy/use hardware to solve the problem?

    • Is there an algorithm or data structure that can easily change?

    • Can you recode bottlenecks in a faster language?

    • Will code tuning help? (default no)

    • Will paralellism help? (default no)

Remember Memory Doctor

  • Memory hierarchy has huge performance effect:

    • Hard disk (10x)
    • Flash disk (10x)
    • RAM (10x)
    • L2 cache (5x)
    • L1 cache (2x)
    • Registers

  • Remember, paging is disk access

  • Modern CPUs are scary fast (McConnell notwithstanding)

System Calls Are Not Your Friend

  • OS is burdened with:

    • Lots of bookkeeping
    • Expensive protection mechanisms

  • Only call it when you have to

  • Buffered I/O is helpful, but not a panacea

    • Buffers can't match rates

You Must Profile

  • You will have performance bottlenecks

  • You have no idea where your performance bottlenecks are

  • Profiling is hard

    • Slows down program
    • Interacts badly with optimization
    • Interpretation is hard

Performance Tuning Strategy

  • Diagnostic activity, like debugging

    • Determine proximate cause
    • Determine root cause
    • Propagate root cause
    • Devise repair
    • Check repair

  • Bad performance is a failure, and may indicate underlying bugs

Learn To Use Your Compiler

  • Optimization flags and options

    • e.g. -funroll-loops, -fprofile-generate

  • Profiling support

Concurrency and Big Data

  • Concurrency is potential parallelism; not always realized

  • Sequential programs are a million times easier

  • Costs of concurrency are high

    • Big overhead for data management
    • Synchronization dramatically reduces speedup
    • Shared resources become bottleneck

  • "True" concurrency vs. naive concurrency

When To Paralellize

  • Parallelize when:

    • Naive concurrency works, and
    • Sharing should help, and
    • Developer skill / effort is not a limiting factor

  • Modern web apps meet these criteria

Optimization Case Study

  • Demo
Last modified: Monday, 18 November 2013, 11:43 PM