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.

IMO the book "Computer systems : a programmer's perspective [Randal E Bryant; David R O'Hallaron]" provides a good foundation on this and other lower level system details.

I second this. Make sure that you do the labs that are available from the books web page.

RAM is plentiful even on many microcontrollers now, but it becomes much less plentiful when you start storing thousands of data points and need to start bit packing boolean flags and reducing the integer size to squeeze as much as you can in the data structure! Or you need to stream as much of that data over a serial link as possible as quickly as possible!

So I agree, knowing how data is stored is critical.

All nonfront end programmers should know this and arguably the front end ones should to.