can it be, floats run 3 times faster with multiplication vs division!

OK, I've sort of thought this for some time, but never had the inclination to prove it directly until now.

so here it goes. if yo want the highest accuracy do division, if you want the highest speed use multiplication


test here times like a stop watch how long it takes each loop to complete

i run a test that takes the number 1 to 10000 (common feed rates) and then uses multiplication and division for the results.

using multiplication of *0.0000000166 takes .124 seconds to go thru and perform all 10000 calculations

using division of /60000000 takes .337 seconds to go thru and perform all 10000 calculations

now is this because i approximated with multiplication, or is it faster optimization because some hardware multiplication support.


use this code and find out for yourself!
code prints time in milliseconds so divide by 1000 to get seconds.
---------------------------------------------------------------------------------------------------

#define task 3 //1 is test delay 3 is test multiplication 2 is division

unsigned long timer1; //uses to compare time
unsigned long timer2;
float testnumber; // if this is in loop it does not work. must be compiler optimization.. leave here..


void setup(){
Serial.begin(19200);
Serial.println("start");
delay(1000);
}




void loop(){

timer1=millis();
do_task();

timer2=millis();
long timertotal= timer2 -timer1;
Serial.println (timertotal);

}


void do_task(){
#if task == 1
delay(1000);
#endif


#if task == 2



for (int i=0; i<10000 ; i++){
testnumber= float( i)/60000000 ; //takes 337ms


}

#endif
#if task == 3



for (int i=0; i<10000 ; i++){
testnumber= float( i)*0.0000000166 ; //takes 124ms


}

#endif


}

If you have specific numbers you need to compare against a variable, this code is for you. just modify the values between the' task == '


result is sent thru serial port and uses arduino monitor to show results. time is done by millis() which runs in background as a counter, do_task is a loop that runs between start count and end count.

Edited 4 time(s). Last edit at 07/05/2011 09:45PM by jamesdanielv.

> or is it faster optimization
> because some hardware multiplication support.

The ATmega's arithmetic instructions are 8-bit integer add, subtract and multiply; anything else (division, larger data types, floating point) has to be done in software, so takes longer.

some additional documentation
[www.atmel.com]

look up :

FMULS – Fractional Multiply Signed
Fractional Multiply Signed with Unsigned


what this is is a feature that allows 2 registers to store results of a multiplication. so 16 bit math register for multiplication

so i think in part it is that multiplication takes less instructions for math at any value than division.

it is interesting that this is used in floating point as well.


so if it is faster to multiply rather than divide, why are we using division in time sensitive acceleration algorithms?

Edited 4 time(s). Last edit at 07/06/2011 06:36AM by jamesdanielv.

sounds like something that gcc should do for us

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

it should but probably not. it requires a conscious effort to forgo some detail. division does some work that is a little more precises such as 1/3 1/6 1/9. multiplication we choose how far to go out. gcc will limit precision at some point. multiplication is even faster when we approximate. values such as time, temp, acceleration speed. call can be approximated. In fact floats are just close approximations.




amount | div | multiplication
1/3 0.33333333333333333333333333333333 0.333
1/6 0.16666666666666666666666666666667 0.166
1/7 0.14285714285714285714285714285714 0.142
1/9 0.11111111111111111111111111111111 0.111


so multiplying even though it is faster, it also limits precision. but then again how precise is a float anyways?


I'll run a test in the next few days comparing specific numbers out to precision that ide allows to find out if there is any normal situation that division is faster. can't think of any but might as well test it to be sure.

Edited 3 time(s). Last edit at 07/07/2011 07:35AM by jamesdanielv.

Single clock integer multiply (not in the AVR!) is quite common on newer processors.

Single clock integer divide is quite hard to do in silicon, though not impossible.

I am uncertain if they have cracked this with floating point.

Division is generally slower than multiplication in most micro's, but it does depend on the implementation.

One suggestion is to try and leave the divide operation to the end of the function where refactoring allows or try and combine divide actions into one operation.

This is where fixed point math comes in handy, speed!

ideally yes avoid floating point. but since we do use floating point we now know what is faster! - next topic will be about digitalwritefast. the ability to write i/o without complexity that speeds up system by 20 times.

see arduino.h and friends in teacup for the fastest way. Sprinter adopted my approach just recently.

It may seem complex, but the preprocessor does all the work, and the compiler simplifies to a single sbi or cbi instruction for each operation. that's even faster than digitalwritefast!

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

for floating point: yes the math is cached and stored and computed in compiler, but several floats are still processed as division math in the acceleration.


for digitalwritefast:
yes but it is careless to do i/o with mega unless comments are added. not all pins registers are directly writable!

but it is good that sprinter is becoming faster.

Edited 1 time(s). Last edit at 07/12/2011 01:36AM by jamesdanielv.

jamesdanielv Wrote:
-------------------------------------------------------
> not all pins registers are directly writable!

care to name an example? I know of none, unless you mean something like TCNT which isn't a pin register.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

[www.avrfreaks.net] states that there is an issue with port f

[z8kxta.blu.livefilestore.com]



the port is analog pins 0-7 if used as digital pins will require additional instructions. I do need to verify this. and any sbi cbi is two instructions as read followed by write. any way I'm sure to amend this later. do you have an atmega 1280 to play with?

ah yes sbi/cbi are indeed 2 cycle, sorry about that. still faster than digitalWriteFast.

oh, and that thread you listed about port F says that it's a bug with AVR studio, and gcc does the correct thing

Out of reset, the PORTF pins are configured as digital inputs. If arduino's libraries set them up a different way between reset and main() then yes you'll have to undo it to use them.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

love and piece the world around. lets make sprinter faster

there is a register limit that can be directly accessed as well. specific instructions are not available for portf.



either way caution those that use either method to know about interrupts changing flags, registers and such, and also make sure to comment on the faster than a few microsecond delay issues both with internal noise and with pin capacitance. what does that mean. toggle as fast as hell but only when needed. for example sprinter currently sets dir pins each freaking time it steps a motor step. i need to work around this with some buffer trick, or something....

Edited 2 time(s). Last edit at 07/12/2011 04:25AM by jamesdanielv.