Hacker News new | comments | ask | show | jobs | submit login

Also the ability to understand and check the performance impact of these choices. For example at a old job on an embedded motor controller the previous engineer had learned 'floats are slow never use them on a microcontroller' and went and removed them from the code wherever he found them. However in the motor control update loop this meant using longs (or possibly even long longs, I don't remember) in a couple calculations. A quick check with a pin toggle showed this was significantly slower than just using floats.

I'm an ME who went into embedded systems, so I'm not sure what qualifies as low level for a web developer and if checking timing using an oscilloscope or saleae is feasible for the type of work OP wants to do. But even just looking at the assembly would have made things obvious in my example.

EDIT- This made me realize that a rudimentary understanding of the assembly language for your architecture will be very valuable. Doesn't have to be enough to actually write any code in it, but it's great to be able to take a look at what was generated when things are acting weird.






Some of the bigger microcontrollers have native hardware support for floats, and in that case they are very performant.

Without that though, performance is really really bad. The inner loop of a motor controller is no place for them...


Fixpoint arithmetic is going to be significantly more efficient than floating point in many cases, except where you need to use relatively-uncommon operations/functions (which are hardware-accelerated in the FPU), or in cases where the same value might span multiple orders of magnitude (i.e. a direct win for the floating point representation). The inner loop of a microcontroller is not generally one of these cases, though exceptions might be out there.

I was surprised it was faster, from what I remember to avoid floating point operations several large values had to be multiplied together then divided which required using a long long to avoid overflow. The division operation was quite slow. Thinking back I'm not 100% sure it was in the inner control loop but at the very least it was required to generate the new motor position.

Anyway a bit toggle tells all, and if you're making speed optimizations you should be checking that things actually got faster.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: