CS 452/652 Spring 2022 - Lecture 7

Timing Measurements

• duration of operation?
• first approximation:

  start := clock;
  operation;
  stop := clock;
  

  • overhead/duration of clock?
  • accuracy of clock?
  • variations in operation?
• inflate impact of operation:

  start := clock;
  loop N times:
    operation;
  endloop;
  stop := clock;
  

• compute average time and/or enhanced statistics
• potential overheads
  • loop execution (counter, branch) → if relevant, measure with nop
  • concurrent workflow requires start/stop coordination
  • warm-up period with non-regular performance
  • sometimes: dummy side effects needed to keep optimizer from eliding experiment code
• N must be large enough to mitigate impact of these overheads
• experiment duration?
  • fixed N - simple
  • fixed run-time - predictable, but more difficult to set up and run

Race

• concurrent or parallel access to shared resource - at least one write
• results in non-deterministic outcome
• coordination to avoid races has overhead
• not all races are problematic! but:
  • correctness problem, if at least of the possible outcomes is incorrect
  • repeatability problem, especially with program modifications (debugging)
• data races very prevalent for multi-cpu computing
  • careful approach to coordination needed to attain highest performance
• non-determinism in CS 452
  • track and trains → sensor reports
  • human operator
• races in CS 452
  • could arise during interrupt handler when accessing shared data
  • however
    • kernel (and interrupt handler) is not interrupted
    • only user tasks are interrupted
    • user tasks do not share data with each other
  • but be aware of the potential problem!

Optimization

Processor Configuration

• ARM 920T has instruction- and data-cache → enable!
  • RedBoot disables before starting program with 'go'
• Related features (not relevant for CS 452/652)
  • lockdown mode: lock specific code/data into fast cache memory
  • Thumb mode: use simpler/smaller instruction set to reduce memory footprint
• MMU enabled with default setting → no need to tinker with
• details: see control register CP15 in EP93XX and ARM documentation

Compiler Optimization

• code without side effects might be removed
• repetitions might be removed
• loops unrolled
• code reordered based on performance of microarchitecture
• compiler understands data dependencies in synchronous control flow
• C/C++ keyword "volatile"
  • tells compiler about unspecified side effects related to a variable or memory location
  • compiler avoids reordering around and removal of volatile accesses
  • example declaration of memory-mapped register

    volatile unsigned int* timer1value = (volatile unsigned int*)0x80810084u;
    

• goal is complete understanding of what we are doing ⇒ enable optimization!

Runtime Optimization

• pipelining and out-of-order execution
• very important challenge in other areas!
• old processor with one core → not relevant for CS 452/652
• Java keyword "volatile" handles this (different from C/C++)

ARM 920T CPU Caches

• various caches
  • L1 instruction cache; L1 data cache
  • branch target cache (branch predictors)
  • TLB (page translation cache)
  • write buffer: mediate fast CPU ↔ slow RAM; coalesce writes
• ARM 920T caching modes (marked in page descriptor)
  0. non-cached, non-buffered → synchronous
  1. non-cached, buffered → ordered
  2. write-through, buffered → cache always clean
  3. write-back, buffered → most efficient
• default configuration
  • L1 caches separate (not unified)
  • no L2 cache?
  • no lockdown
  • regular memory in write-back mode
  • device memory in non-cached mode
  • RedBoot disables L1 caches during 'go' command

ARM 920T Cache Setup

MCR{<cond>} p15, 0, <Rd>, <CRn>, <CRm>{, <opcode2>}
MRC{<cond>} p15, 0, <Rd>, <CRn>, <CRm>{, <opcode2>}