Chain tool speed

RE: Chain tool speed

Håkon Alseth — Thu, 04 Dec 2014 14:38:19 GMT

This is also an interesting read regarding optimization. The modulo operator is something embedded engineers fear like the plague, but it's actually efficient on the ARM platform: embeddedgurus.com/.../

When it comes to speed, it's as Nguyen says, it's the code that the developer writes that has the most impact.

Doing shift-operations are always efficient compared to doing division/multiplication. I've seen many funky macro functions for effective divisions, which are purely made with regards to speed, and to be accurate enough for the scope it's used in.

Here's a fantastic snippet from Quake 3 src sqrt calculation: en.wikipedia.org/.../Fast_inverse_square_root

Cheers, Håkon

RE: Chain tool speed

Nguyen Hoan Hoang — Thu, 04 Dec 2014 13:13:20 GMT

It's all about how you write your code. Knowing how the compiler generate code and write optimize code would be the latest. One compiler with same setting you can have 2 sets of code with one running faster the the other.

A simple example

a = b / 2;  // Takes many cpu cycles
a = b >> 1; // only 1 cycle

Compiler will not optimize that for you.

There is a good book on writing optimized code.

"C++ Footprint and Performance Optimization" by Rene Alexander & Grahm Bensley. Published by SAMS. ISBN 0-672-31904-7

PS. mBed not recommended for speed.

RE: Chain tool speed

Stian Røed Hafskjold — Thu, 04 Dec 2014 11:28:32 GMT

I don't think it is a definitive answer for that, except that i believe Mbed would be slower because it is higher level. Both in Keil and GCC you have optimization options:

gcc.gnu.org/.../Optimize-Options.html

www.keil.com/.../uv4_dg_adscc.htm

In Keil you have the -Otime optimization, which will optimize for execution time. But, in the end I believe you just have to test, because it depends on your code.

You can use a 32MHz crystal, but the chip only runs on 16MHz anyway. It just divides the clock.