ベンチマークのヒント

ベンチマークのヒント

IAR Embedded Workbenchは業界で最高峰の効率的なコードを生成します。さまざまな設定を有効にすることで、ツールの性能を最大まで引き上げることができます。

サイズとスピードの選択

最適化のレベルとタイプはアプリケーションの全体像とそれぞれのファイルの双方によって決定されます。ソースコード内では、 個々のファイルレベルでの最適化レベル・タイプの選択を#プラグマ指令が可能にします。

最適化の目的はコードサイズの削減と実行スピードの向上です。二つの目的のうちどちらかが達成されたとき、設定に沿ってコンパイラが優先度付けをします。 

異なるトランスフォーメーションの効果を調査すると、より良い結果を得られます。例としてスピード最適化によりアグレッシブなインライン関数As an example, the fact that Function inlining is more aggressive for speed optimization makes some programs smaller on the speed setting than on the size setting.

 

Choose a small memory model

Choose the smallest possible memory model available for your target.

Benefits:

  • Smaller addresses
  • Smaller instructions
  • Smaller pointers
  • More efficient
  • Less code

Adapt the runtime environment

By default, the runtime libraries are compiled at highest size optimization level. You should rebuild them if you are optimizing for speed.

Select the needed level of support for certain standard library functionality like, locale, file descriptors, and multibytes by choosing library configuration.

Select library options for scanf input and printf output formatters according to your needs. The smallest formatters are not selected by default.

 

Use the right data types

Data types have big influence on code size/speed:

  • Choose the data size best suited for your application
  • Use unsigned char if possible–allows bit operations to be performed instead of arithmetic

Check for target-specific options

Check for target-specific options that gain performance, such as:

  • Efficient addressing modes–efficient memory accesses
  • Locking registers for constants/variables–more efficient code for operations on registers than on memory
  • Even align functions entries–even aligned instructions gain speed
  • Byte align objects–requires less memory for storage but might give bigger code

Use relevant benchmark code

  • Embedded systems benchmarks should address the characteristics of embedded programs.
  • Real applications are usually good for benchmarks but, make sure that the code can execute. The linker will remove un-referenced code and variables but not all linkers have this ability.
  • Make sure that the test code is not affected by the test harness (test support functions). This example is actually benchmarking printf():

  • Compare linked code. One compiler may inline code where another makes a library call.
  • Know the application you use for benchmarking!

© IAR Systems 1995-2018 - All rights reserved.

We use cookies on this website to provide you with a better experience. You need to accept cookies to continue using this site. Cookies