How to optimize the embedded code and make efficient coding

[amar]

Hi
can someone suggest me how to make good code and optimize code
so that it can helps for efficient response of the system

[smashedProton]

This is a really wide topic to ask...  may I suggest that you ask for a specific answer on the microcontroller thread?   That should get you what you need.  Thanks

[westfw]

Oh, no one does THAT anymore.  Just buy a faster chip!

[grumpydoc]

Just buy a faster chip!

Or faster JVM 

[digsys]

There's not much chance you can learn this on a forum. You seriously will need to do a class, and get face to face tuition.
There should be plenty of schools, colleges, technical places that offer courses. IF you believe you're a quick adapter,
then try an on-line course, or search for free coding lessons to see if you catch on.
As far as "no one does this any more" comments .. don't listen to them, plenty still do, just that most are lazy now :-)

[ddavidebor]

Hi
can someone suggest me how to make good code and optimize code
so that it can helps for efficient response of the system

It's simple, time, no girls, and a lot of coffee

[Ax_6]

Oh, no one does THAT anymore.  Just buy a faster chip!

I'm not really of the same opinion... some times you can easily improve your code and save some money.

For example if you want 8 clock pulses as fast as you can (and you don't have problem of memory space) instead of writing

Code: [Select]

for(int a =0;a<8;a++){
out = 1;
out = 0;
}you can write

Code: [Select]

out = 1;
out = 0;
out = 1;
out = 0;
out = 1;
out = 0;
out = 1;
...
...
out = 0;
The code would be ugly! But, on the other hand It would be faster, in this case it could even double the speed of your clock.
That's just an example but I hope that you get what I'm trying to say.

[grumpydoc]

For example if you want 8 clock pulses as fast as you can (and you don't have problem of memory space) instead of writing
....[snip]....

A good compiler should be able to do that for you (the technique is known as "loop unrolling" by the way.

My JVM comment above was meant to be a little sarcastic, people are moving further and further away from low level coding and while this is a good thing in many ways it does partly explain why desktop operating systems and word processors today don't feel much faster than they were 10 or 15 years ago despite processors being 10's or 100's of times faster (a big chunk of the rest is that everything has to be accompanied with fancy graphics but I digress).

The best optimisation is to choose the correct algorithm in the first place. Understanding different data structures and their trade-offs is also important. Micro-optimisations like loop unrolling can be important but can be automated - choosing an O(NlogM) algorithm over an O(N²) one can't.

That said one sometimes needs to have low level skills - I once worked on an embedded system where I needed to grab about a megabyte of RAM (out of 4 IIRC) for an enhancement and was told by the main team that I couldn't as there was only about half a meg unused. It turned out that no-one in the main team understood structure packing (or rather the implications of getting it wrong). Once I'd re-ordered their data structures they were about half the original size so I had my 1 meg and the system had more free RAM when I finished than it did when I started.

[andersm]

Pick the appropriate algorithms, learn to take advantage of the hardware and peripheral features. Adapt your coding style to the hardware. Learn the tools, figure out how to measure things - optimizations are useless if they're not applied in the right places. Learn about interrupts, tasks, threads and how to structure your application to best take advantage of them. The time spent waiting on eg. a slow peripheral can be better used doing something else.

[kfitch42]

"Premature optimization is the root of all evil" - D. Knuth

Optimization without a goal is really obfuscation.

All optimization needs to be guided by a goal and by measurements.

Potential goals: decreased code size, increased throughput, decreased latency, increased maintainability ...

Optimization is about tradeoffs, so you need to make sure you are measuring more than one thing ... e.g. is a 1000% increase in code size worth a 0.1% increase in throughput?

[mikeselectricstuff]

Learn assembler first. that way you get a better understanding of the hardware and its limitations, and can look at the code that a compiler generates and be able to judge if it is doing things efficiently.

[AlfBaz]

Just be careful when optimising that you don't get carried away with opaque constructs

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Brian Kernighan.

[andyturk]

Hi
can someone suggest me how to make good code and optimize code
so that it can helps for efficient response of the system

1) Get the code to work first. Doesn't matter if it's inefficient.

2) Measure the parts you care about. Interrupt routines taking too long? Screen updates too slow? Using too much RAM? Whatever it is, measure where you are and figure out how much you need to save.

3) If you're lucky, 50+% of the resource you're trying to optimize will be absorbed by one part of the system. Fixing that will make a big dent in your overall picture. This is known as "low hanging fruit". If you're not lucky, you'll have lots of modules each of which uses a small piece of the resource. In this case, there's no obvious place to start.

4) Repeat steps 2 and 3 until your code is efficient "enough" or there's no more low hanging fruit to optimize.

5) If it's still not efficient enough, go read Knuth.

[Hypernova]

Look at the math equation you are trying to convert to code and look for places where you can simplify.
Eg If some symbolic math solver gives you A*B*C+A*B*D, use A*B*(C+D), Now you only have to do A*B once, for large equations that can make all the difference.

General trade off to optimization is size vs speed like in Ax_6's example,  identify any constants that can be precomputed.
Eg, for fixed point math where 0~360 degree is represented by a 10 bit unsigned int you can have a x1024 array storing precomputed sin(x) values.

[kfitch42]

4) Repeat steps 2 and 3 until your code is efficient "enough" or there's no more low hanging fruit to optimize.

I agree that is a good description of how to optimize ... but I would say step 4 should say repeat steps 1,2 and 3. A good automated test suite is a great help here. Code that computes the wrong answer really fast doesn't help anyone

 

[IanB]

I'm really surprised that no-one has recommended using code that has no I/O overhead and no side effects, like this:

Code: [Select]

   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP

This code will run about as fast as it is possible for any code to run.

[pyroesp]

I've done a 256-FFT on a 32 bit mcu. The samples where read from the ADC and sent to my transform function.
In my first version, the transform function used to read the samples like this:

Code: [Select]

for (i = 0; i < fft_point; i++)
{
    something_fft = samples[i];
    // something
    // something
}
The compiler could have compiled it to something like this (pseudo code):

Code: [Select]

for_loop:
ADD samples, i, reg1 // add i to address sample and save to reg1
GETDATA reg1, reg2 // get the data at address reg1, write it to reg2
MOV something, reg2 // move value of reg2 into something
INC i // increase i
CHECKLOWER i, fft_point, for_loop // check if i < fftpoint, if true, jump to 'for_loop'
In the optimized version I changed the way I read my data from the buffers like this :

Code: [Select]

for (i = 0; i < fft_point; i++)
{
    ++samples;
    something_fft = *(samples);
    // something
    // something
}
Which could get compiled to something like this(pseudo code):

Code: [Select]

for_loop:
INC sample // increase sample pointer
GETDATA sample, something // get the data at address sample, write it to reg2
INC i // increase i
CHECKLOWER i, fft_point, for_loop // check if i < fftpoint, if true, jump to 'for_loop'
I gained 1 instruction in this example.
Do this for most of your code and you'll gain some time.

Most of this optimization is through experience and google (reading other people's code).

PS: "samples" is a pointer/copy of the address of the samples buffer.

P-PS: Try to set the compiler to optimize your code with "-OX", X being a number from 0 to 5 if I remember correctly (Might be different from compiler to compiler).

[AlfBaz]

I'm really surprised that no-one has recommended using code that has no I/O overhead and no side effects, like this:

Code: [Select]

   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP
   NOP

This code will run about as fast as it is possible for any code to run.

LOL
IN this day and age it won't be so optimal as the java VM running on the embedded rtos running oop constructs will undoubtedly run each NOP thousands of cycles apart 

[grumpydoc]

Look at the math equation you are trying to convert to code and look for places where you can simplify.
Eg If some symbolic math solver gives you A*B*C+A*B*D, use A*B*(C+D), Now you only have to do A*B once, for large equations that can make all the difference.

If your <insert favourite language> compiler doesn't do the above for you throw it away and get a better one.

The important steps for the human being in the equation are
1) understand the problem
2) understand your system
3) choose the right data structures and algorithms
4) measure the performance before "optimising" the code.

General trade off to optimization is size vs speed like in Ax_6's example,  identify any constants that can be precomputed.
Eg, for fixed point math where 0~360 degree is represented by a 10 bit unsigned int you can have a x1024 array storing precomputed sin(x) values.

Yes, that sort of technique can be useful if you don't have a FPU.

[Ed.Kloonk]

A wise guru informed me once that the code you waste too much time on by trying to optimise it as you write it will be worse than the actual bottleneck or bloat that really impedes your program.

Just code it. Code utill you are exahusted. Then try to comment it as well as you can before you fall asleep.

[westfw]

Code: [Select]

   NOP
   NOP
   NOPAh, but which NOP should you use?  I mean, on the KL and KI CPUs, "JFCL" (Jump and Clear Flags, but don't clear any flags and don't jump) is the fastest nop, but on the KL CPU, you should should use "TRN" (Test Right half with nothing, do Nothing to those bits, and don't ever skip.)  (I guess modern RISC CPUs don't have quite the variety of alternatives of the old CISC mainframes, but you might have to worry about whether a tiny loop of nop that fits in cache and matches the HW branch prediction expectations is faster than a long chain of inline nops...)

I suspect that the OP, if he wasn't a troll, is more at the level of "don't use floating point on a cpu that doesn't have floating point hardware", than "don't use sprintf when strcat would work", or "ARMs have a 32-bit ALU, so using smaller datatypes can actually slow down computations as they are expanded/compressed from their memory locations to the forms the ALU can deal with, unlike most 8-bit CPUs where larger datatypes are nearly always slower."

[andersm]

I gained 1 instruction in this example.

You have a terrible compiler.

P-PS: Try to set the compiler to optimize your code with "-OX", X being a number from 0 to 5 if I remember correctly (Might be different from compiler to compiler).

Very much so. For example for GCC-based compilers only levels 0-3 are valid.

[mikeselectricstuff]

Although there are all sorts of clever things a good (expensive) compiler can potentially do, in practice many don't, so it is well worth learning how to write code that even a dumb compiler will do a reasonable job of.
But even the best compiler can't help a fundamentally flawed code design.
For example it won't tell you that you don't need floating point just to display a number that happens to have a decimal point in it, and the best compiler will still take more code and cycles than a poor one given a better approach for the same task. 
A good compiler will also not tell you that you are using unnecessarily large data types.

[grumpydoc]

In the optimized version I changed the way I read my data from the buffers like this :
....[example with pointer instead of index snipped]....

this is typically the sort of micro-optimisation that is a waste of time unless you know that you need to shave a processor cycle or a byte of code, know that playing games like this with the high level code yields better assembler.

This latter point will depend on the compiler - once optimisation is on the output from your two examples might be similar or even identical. It will also be dependent upon the platform which you need to know well.

For example the AVR instruction set* has lousy indexing so I'd expect the code from your first example to be along the lines of your pseudo-code. Except that you ignore operand size issues so that is likely to introduce more actual assembler.

* slight disclaimer, I've never hand coded AVR, just had a quick look at the instruction set a minute ago so might be wrong but you get the point, I'm sure.

Arm, however has decent indexing so the whole "something_fft = samples[i ];" statement should be a single instruction and it might be that version will be better on that platform.

AVR does have pre-decrement and post-increment so the compiler should be able to shange

Code: [Select]

    something_fft = *(samples);
    ++samples;

into a single instruction which does the assembler equivalent of

Code: [Select]

    something_fft = *(samples++);

Now, you wrote that the other way round. That would be OK** if the initialisation of "samples" (outside the loop) was correct starting one before the data, then incrementing, then dereferencing but if you wrote it that way you'd probably deny the compiler an optimisation.

** Apart from being invalid C - you're not supposed to generate addresses before the start of an array because on some segmented architectures address arithmetic might go AWOL at that boundary. You are allowed to generate the address one past the end of an array for comparison but not to dereference it.

Even if you do "win" by playing these games move platforms and the rules change. It's much better to write code in as clear and un-convoluted way as possible and let the compiler take care of the rest at this level. If you really (after measuring) want to shave a cycle, or shave a byte then actually write the assembler code.

[amar]

yes
1st understand problem.
2nd make algorithm/flow chart
then make a good working code.
after that read code 3-4 time & try to optimize the code so that it can run fast and take less flash memory