Prev: Confused with Notation
Next: PWM
From: Walter Banks on 19 Apr 2010 15:31 Tim Wescott wrote: > Depending on the problem, you may never need to convert. Speed > differences depend on the processor. Two processors, each offering a > single-cycle MAC at the same clock rate, are going to be about the same > speed. But implementing a single-cycle floating point MAC takes a lot > more hardware than doing the same thing with fixed-point. So -- all > else being equal -- you can expect the floating point processor to be > bigger, more costly, and more power-hungry. Two or three years ago I implemented both fixed and floating point libraries for some of the processors we support. When we benchmarked the results in a pure software implementation when the float and fixed point sizes used the same number of bits i.e.. ieee754 32 bit and a fixed point 8:24 for example the number of execution cycles for the basic functions were very similar. The trade-off's between float and fixed point are essentially one of dynamic range vs precision. Regards, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
From: Tim Wescott on 19 Apr 2010 16:29 Walter Banks wrote: > > Tim Wescott wrote: > >> Depending on the problem, you may never need to convert. Speed >> differences depend on the processor. Two processors, each offering a >> single-cycle MAC at the same clock rate, are going to be about the same >> speed. But implementing a single-cycle floating point MAC takes a lot >> more hardware than doing the same thing with fixed-point. So -- all >> else being equal -- you can expect the floating point processor to be >> bigger, more costly, and more power-hungry. > > Two or three years ago I implemented both fixed and floating point > libraries for some of the processors we support. When we > benchmarked the results in a pure software implementation when the > float and fixed point sizes used the same number of bits i.e.. ieee754 32 > bit and a fixed point 8:24 for example the number of execution cycles > for the basic functions were very similar. The trade-off's between float > and fixed point are essentially one of dynamic range vs precision. I believe that the biggest barrier to floating point is if you adhere to the IEEE standard, which requires a considerable amount of exception handling. I've never done it, but what I hear is that if you handle all of the exceptions per the specification, that is when code size (or logic) gets big. A DSP that has native fixed point support will do fixed point vector dot products a _lot_ faster than floating point. Beyond that -- well, it depends on the processor. My experience with fixed point on a Motorola MPC860 vs. floating point was considerably different than yours. I don't remember precisely, other than the fixed point was way faster. If it wasn't 10:1 it was 50:1. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Vladimir Vassilevsky on 19 Apr 2010 17:10
Tim Wescott wrote: > My experience with fixed point on a Motorola MPC860 vs. floating point > was considerably different than yours. I don't remember precisely, > other than the fixed point was way faster. If it wasn't 10:1 it was 50:1. I tried floating point emulation with AVR, 68HC12, TMS320C28xx, BlackFin, 8051 and like, getting somewhat 15 times difference in speed compared to optimized integer math. Nevertheless emulated floating point appears to be sufficiently fast for many practical applications. IMO the biggest tradeoff is memory footprint: it is hard to fit a floating point application in a device smaller then 8K. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |