I’ve noticed that the FP libraries that get linked in on the HiFive1 are extremely slow for a 32 bit processor with fast hardware 32x32->64 multiply.
At 16 Mhz, float add&sub are around 7 us, mul around 40.5 us.
I don’t have an AVR Arduino here at the moment, but I’ve always counted them as near enough to 10 us for add/sub/mul at 16 MHz on an 8 bit AVR. Maybe a little less.
Ah … HiFive1 double add/sub are around 5 us, and mul 40 us. (at 16 MHz)
Double is faster than float! So everything is being done in double and converted back and forth from float.
I expect the HiFive1 math library is IEEE compliant. The AVR one is far from it! Speed optimised.
(in an earlier post-midnight version I forgot to measure and take off the loop control overhead)
I was actually very surprised how fast software FP is on the 8 bit AVRs when I first got one a few years back. Someone did a great job on that library.
Sorry to take so long to reply - missed the notification email, I guess.
The 153 seconds was observed at the 320 MHz clock rate.
I wonder how different the gcc FP libraries are for ESP8266 and HiFive - the delta in performance is pretty large (61s @ 80 Mhz, vs. 62 @ 180 MHz). Have to dig up a ESP8266 vs. HiFive DMIPS comparison.
That’s unbelievable! With the hardware resources available vs an 8 bit AVR, 153 seconds should be about right at 16 MHz. Given a reasonable performance-oriented FP library, of course.
It’s been a while since I wrote a raytracer… how is the scene itself generated? Is it generated on the fly (in memory) or stored in flash (program memory). If the latter and we have to keep hitting flash that will also slow it down.
Looking at the video https://www.youtube.com/watch?v=H9uUO-UQtzE it’s a classic simple ray-tracing scene with a chequered plain and a few balls of varying size and reflectivity. The description should only be a few hundred bytes.
It would be important to make sure the scene description is copied into RAM, not accessed directly from flash.
Simply making sure any global variables or arrays are (somewhat perversely) not “const” should be sufficient.
Again: it would be good to have the source code, so we can try it ourselves.