Notes - MIECT
Sistemas Operativos E De Tempo-real
Notes - MIECT
Sistemas Operativos E De Tempo-real
  • Sistemas Operativos e de Tempo-real
  • Basic Concepts About Real-Time Systems
    • Preliminaries
    • Definitions
    • Objective of the Study of RTS
    • Requirements of Real-Time Systems
  • Real Time Model
    • Real Time Model
    • Temporal Control
    • Task states and execution
    • Kernel/RTOS Architecture
      • Time Management Functions
    • Examples of RTOS
  • Practical Class 01
    • Real-Time Services in Linux
    • Using the Linux real-time services
  • Scheduling Basics
    • Basic concepts
    • Scheduling Algorithms
      • Basic algorithms
    • Static Cyclic Scheduling
    • Exercise
  • Fixed Priority Scheduling
    • Online scheduling with fixed priorities
    • Schedulability tests based on utilization
      • Deadline Monotonic Scheduling DM
    • Response-time analysis
  • Practical Class 2
    • Xenomai brief introduction
    • API
    • Developing an application
  • Dynamic Priority Scheduling
    • On-line scheduling with dynamic priorities
    • Analysis: CPU utilization bound
    • Analysis: CPU Load Analysis
    • Other deadline assignment criteria
  • Exclusive Access to Shared Resources
    • The priority inversion problem
    • Techniques for allowing exclusive access
    • Priority Inheritance Protocol
    • Priority Ceiling Protocol
    • Stack Resource Policy
    • Notes
  • Aperiodic Servers
    • Joint scheduling of periodic and aperiodic tasks
    • Aperiodic Servers
    • Fixed Priority Servers
    • Dynamic Priority Servers
  • Limited preemption, release jitter and overheads
    • Non-preemptive scheduling
    • Impact of Release Jitter
    • Accounting for overheads
    • Considerations about the WCET
  • Profiling and Code Optimization
    • Code optimization techniques
      • CPU independent optimization techniques
      • Cache impact
      • Optimization techniques dependent on memory architecture
      • Architecture-dependent optimization techniques
    • Profiling
  • Multiprocessor Scheduling, V1.2
    • Introduction
    • Definitions, Assumptions and Scheduling Model
    • Scheduling for Multicore Platforms
    • Task allocation
Powered by GitBook
On this page
  • Why optimize code?
  • Low-level vs high-level languages
  • Is using assembly the solution?
  • “C” vs Assembly
  • Then what is the best approach?
  1. Profiling and Code Optimization

Code optimization techniques

Why optimize code?

Many real-time systems are used in applications:

  • Highly cost-sensitive.

  • Where energy consumption must be minimized.

  • Where physical space is restricted, ...

If the execution time or footprint is too large just buying a faster processor IS NOT a solution!

Code optimization allows to produce:

  • Faster programs:

    • Enables the use of slower processors, with lower cost, lower energy consumption.

  • Shorter programs:

    • Less memory, therefore lower costs and lower energy consumption.

Low-level vs high-level languages

Is using assembly the solution?

Assembly language programming.

  • It potentially allows a very high level of efficiency, but:

    • Difficult debugging and maintenance.

    • Long development cycle.

    • Processor dependent - non-portable code!

    • Requires long learning cycles.

Programming in high-level languages (e.g. “C”).

  • Easier to develop and maintain, relatively processor independent, etc. but:

    • Generated code potentially less efficient than code written in assembly.

“C” vs Assembly

Assembly programming, while potentially more efficient, in general, turns out not to be a good approach:

  • Focus on implementation details and not on fundamental algorithmic issues, where the best optimization opportunities usually reside.

    • E.g .: instead of spending hours building an “ultra-efficient” library for manipulating lists, it will be preferable to use “hash-tables”;

    • Good quality compilers produce more efficient code than the one produced by an ”average” programmer;

John Levine, on Comp.Compilers

“Compilers make it a lot easier to use complex data structures, compilers don’t get bored halfway through, and generate reliably pretty good code.”

Then what is the best approach?

As in almost everything in life, “virtue is in the middle”, or otherwise, in the “war” between “C” and Assembly wins ... whoever chooses both!

General approach:

  • The programmer writes the application in a high-level language (e.g. ”C”).

    • The programmer uses tools to detect ”hot spots” (points where the application spends more resources).

    • The programmer analyzes the generated code and ...

      • Re-write critical sections in assembly,

      • and/or restructures high-level code to generate more suitable assembly code.

PreviousConsiderations about the WCETNextCPU independent optimization techniques

Last updated 2 years ago