NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
- 1 Introduction
- 2 Motivation
- 3 Availability
- 4 Presumptions
- 5 How to Start
- 6 Configure and Start Experiment
- 7 Optimizer Assistant in Action
- 8 Results: Speed vs Size
- 9 Results: Optimization Level
- 10 Next Steps
- 11 Review Compiler Options
- 12 Support
- 13 More Information
This is the home page for the Optimizer Assistant feature of Code Composer Studio v5 (CCS).
When you are building your system, you constantly look for that sweet spot where everything just barely fits in memory, it runs very fast, and the battery lasts almost forever. Everyone knows the easy way to do that is build with --the_perfect_compiler_option. Oh wait, there is no such option.
In real life, the way to find the sweet spot is to experiment with the compiler options. Try different options, try different settings for those options, and so on. A common response is that is too hard, or error prone, or not much fun, or something. There has to be something better.
Well, there is something better, and it's called Optimizer Assistant.
Optimizer Assistant is introduced in Code Composer Studio v5.5. Further, your compiler version must be as follows:
Optimizer Assistant is available for ARM, C2000, and MSP430 targets. As of this writing, Optimizer Assistant is not available for C6000. It is unlikely to become available for C5500 or C5400 targets.
This article presumes you are somewhat familiar with Code Composer Studio v5. In particular, you know the basics of creating and building a project.
How to Start
This section presumes you have a project loaded in CCS and it builds clean.
Here are the typical steps used to start Optimizer Assistant.
- Focus on the Problems and Advice View
- Select the Advice View
- Scan through advice entries
- Select each entry
- An entry may be too long to see it all
- Look at the bottom CCS border to see more of the message
- Double click on the indicated advice entry
These steps are illustrated by the following screen shots:
Another Way to Start
A direct method is to navigate from the main menu: View | Other | Code Composer Studio | Optimizer Assistant. Then click on the small green arrow icon for Start Analysis.
Configure and Start Experiment
This next screen shot shows the Optimizer Assistant dialog for setting up to experiment.
Use the drop-down box to choose which compiler option to experiment with. You can choose between:
- Speed vs Size trade-off (--opt_for_speed)
- Optimization level (--opt_level)
Then click Start.
Optimizer Assistant in Action
Then Optimizer Assistant goes to work, experimenting with that compiler option for you. It rebuilds the project several times over, each time with a different setting for that compiler option. For every build, the amount of flash memory required is recorded. As this is going on you see something similar to:
If you pay careful attention, you may notice that some of the builds fail. This is normal. Sometimes a particular compiler option setting may use more memory than is available. Such an occurrence causes the build to fail. When that happens, it is reflected in the results.
Results: Speed vs Size
If you experimented with the speed vs size compiler option, then your results will appear similar to the following:
The numbers are the left are the setting for the speed vs size option. The numbers on the right are the amount of flash memory required by that particular build.
The color scheme:
- Yellow - It fits, but you can do better.
- Green - Recommended
- Red - It doesn't fit. Not enough memory is available to hold everything.
A check mark is shown next to the current project setting for the speed vs size option.
The green bar is usually going to be the largest one that still fits. All other things being equal, this setting is likely to be faster than any of the yellow bars. Keep in mind that faster means fewer CPU cycles are executed, less power is consumed, and your battery will last longer.
Results: Optimization Level
If you experimented with the optimization level option, then your results will appear similar to the following:
The numbers on the left are the setting for the optimization level. The numbers on the right are the amount of flash memory required by that particular build.
The color scheme:
- Blue - It fits.
- Red - It doesn't fit.
A check mark is shown next to the current project setting for the optimization level.
There is no green bar, because the best choice is more complicated. For example, if ease of debug is a concern, you might choose the lowest optimization level that still fits. See the wiki article Debug versus Optimization Tradeoff to for further discussion of that topic.
In the results window, hover the mouse over one of the rows to see a pop-up similar to following:
The pop-up window allows you to click on one of two choices:
- Change the compiler option to the indicated setting
- Load and run the program built with that setting
In this particular case the setting is --opt_for_speed=2. You can either change your options to always build that way, or you can run the system built that way to see things like performance and power consumption.
Review Compiler Options
For convenience, this section reviews the two compiler options which are the point of experiment by Optimizer Assistant.
Speed vs Size Trade-off
Most compiler optimizations reduce both cycles and code size. A few optimizations however, work differently, and cause one to increase while the other decreases. A good example is loop unrolling. Loop unrolling makes N copies of the loop body, then executes the loop original_iteration_count/N times. In combination with other optimizations, such a transformation can use fewer cycles, but obviously takes up more code space. Making good decisions about whether to implement such optimizations requires input from the user about the relative importance of speed over size.
The option is expressed as --opt_for_speed=value. Valid values are 0-5. The value 0 favors size the most. The value 5 favors speed the most. Values in between trade off speed and size accordingly.
The best choice for the speed vs size trade-off is usually the largest size which still fits. Let Optimizer Assistant experiment for you to find that setting.
The chief difference among different optimization levels is how much of the source code is considered at once in order to make good decisions about how to improve compiler output.
|Option||Range of Optimization|
|--opt_level=4||Between files and libraries|
Higher levels of optimization tend to generate better output. All that said, there are instances of level 0 and 1 optimizations which consider a bit more source code that what is reflected here.
Do not think that this setting always optimizes for speed with no regard to code size. This option only controls the scope of the optimizations used. The speed vs size trade-off is entirely controlled by --opt_for_speed.
Please post any questions and issues to the compiler forum within the TI Engineer to Engineer community.
- PowerPoint Slide Presentation