3 ms·

I tried to use it on an 8-bit AVR one time, and the native sqrtf function was faster!

by sgtnoodle 5y ago

metalliqaz 5y ago
you were doing that kind of floating point math on an AVR? good lord...
- sgtnoodle 5y ago
  Yep, for that project I implemented an RC airplane attitude controller. It would keep pitch and roll at 0 degrees with an offset based on the joystick input, toggle-able by a switch. It was fun, you could do really foolish stunts and just flip a switch to level out immediately if you got too disoriented. The AVR was reading a 6 axis IMU chip and estimating attitude using a floating point quaternion based complementary filter, at 100hz. Sqrt was used when normalizing vectors and quaternions, probably two or three times per cycle. It was also reading 6 channels from the radio receiver, and producing 6 RC PWM outputs. I believe the output was synchronized to the input, so that the throttle and servos would go limp if the radio went out of reception, rather than have the plane just keep flying level into the sunset. I vaguely remember it using about half the available CPU cycles doing all that. I even managed to get it talking to an RC simulator, so I could debug it without crashing my real plane. It worked perfectly on the first test flight!
creato 5y ago
I could see sqrtf(x) being faster than 1/rsqrt(x). An integer software implementation of sqrt and division will be similar (in fact, I think if implemented with Newton's method, sqrt will be significantly faster), and you still have to compute rsqrt. But, if you were computing 1/sqrt(x), I highly doubt the quake3 style rsqrt(x) was slower than that. If both implemented with software floats, rsqrt(x) would be strictly less work. They're almost the same computation, except you'll probably get a better initial guess for rsqrt (the "what the fuck" line), and each iteration produces more accuracy.

3 ms·

I tried to use it on an 8-bit AVR one time, and the native sqrtf function was faster!

by sgtnoodle 5y ago

I tried to use it on an 8-bit AVR one time, and the native sqrtf function was faster!

metalliqaz 5y ago
you were doing that kind of floating point math on an AVR? good lord...
- sgtnoodle 5y ago
  Yep, for that project I implemented an RC airplane attitude controller. It would keep pitch and roll at 0 degrees with an offset based on the joystick input, toggle-able by a switch. It was fun, you could do really foolish stunts and just flip a switch to level out immediately if you got too disoriented. The AVR was reading a 6 axis IMU chip and estimating attitude using a floating point quaternion based complementary filter, at 100hz. Sqrt was used when normalizing vectors and quaternions, probably two or three times per cycle. It was also reading 6 channels from the radio receiver, and producing 6 RC PWM outputs. I believe the output was synchronized to the input, so that the throttle and servos would go limp if the radio went out of reception, rather than have the plane just keep flying level into the sunset. I vaguely remember it using about half the available CPU cycles doing all that. I even managed to get it talking to an RC simulator, so I could debug it without crashing my real plane. It worked perfectly on the first test flight!
creato 5y ago
I could see sqrtf(x) being faster than 1/rsqrt(x). An integer software implementation of sqrt and division will be similar (in fact, I think if implemented with Newton's method, sqrt will be significantly faster), and you still have to compute rsqrt. But, if you were computing 1/sqrt(x), I highly doubt the quake3 style rsqrt(x) was slower than that. If both implemented with software floats, rsqrt(x) would be strictly less work. They're almost the same computation, except you'll probably get a better initial guess for rsqrt (the "what the fuck" line), and each iteration produces more accuracy.