Run an analysis

Analysis process

After setting up the FFT-C project, you end up on the following page.

FFT-C project details

Clicking on any element of the project will take you back to the configuration tunnel, allowing you to change any parameter at any time. In general, changing a parameter will require you to redo the rest of the tunnel, as most of the steps depend on the previous choices.

To run the analysis, click on Run analysis.

Analysis is running
1

Static analysis

The source files and the compiled binary objects are related to produce an omniscient representation mapping each code statement to the associated instructions. The instructions are statically characterized in terms of functionality and impact, and by consequence, the associated code too.

2

Dynamic analysis

The code is instrumented, built and executed to produce profile data.

3

Fusion of static and dynamic data

Static and dynamic analysis data are fused so both can be leveraged through cost models, estimating self and cumulative costs for each function.

4

Optimization potential detection

Optimization potentials are researched based on identification of advanced code patterns, knowledge of instruction costs for the target, and possible target-specific instructions.


Analysis results

General results

Analysis is done

After the analysis is over, which can take some time depending on the project and analysis mode, you can see an estimation of how much the code could benefit in terms of performance (here 9.5%). This result can be obtained by applying the 14 detected optimization points.

Click See latest analysis to view further details.

Analysis dashboard

The analysis dashboard contains useful information about the code.

  • The three first tiles represent the potential gain score, indicating possible improvements in performance (and energy) by applying optimizations in your source code.

  • Each tile corresponds to a kind of optimization:

    • Bit-exact: optimizations that do not change application outputs (safe, no trade-off).

    • Permissive: may change binary representation of outputs without degrading quality (e.g., different data types or math functions).

    • Lossy: modify accuracy (e.g., float→fixed, polynomial approximations, smaller data sizes). These can yield large performance gains but come with accuracy trade-offs.

The Detected optimization kinds tile shows details about which optimizations were detected and their implications.

You may also see estimated CPU cycles for your program and its functions, both self and cumulative costs.

Functionality repartition shows how your code behaves over time: for each function, the relative weight of calculations, memory, or control instructions. This helps prioritize optimization efforts (e.g., a function heavy on memory operations when you expect it to be compute-bound may suggest problematic memory access patterns).

Code coverage informs:

  • Static coverage: which parts of code map to machine instructions (helps identify statically dead code).

  • Dynamic coverage: which parts were executed during dynamic analysis (helps assess if execution was representative).

Call graph

A call graph summarizes all information. Functions shown in red and orange are the most costly and indicate where to focus optimization efforts first.

Once you've analyzed your code, you can run the optimization.

Last updated