I've been trying to figure out why the below math benchmark code appears to run about twice as fast on the same eval board, depending on whether I use KEIL or IAR tools to build the project. The pulse on LED1 is about 6 usec's with the KEIL tools, while it's less than 3 usec's with the IAR tools. Basically, my code temporarily disables interrupts, drives an I/O pin high, does a math operation, and then drives the I/O pin low again. The function that does this is called repeatedly so that triggering on the pulse with an oscilloscope gives a pretty good indication of the chip+tools math performance. EX: float f1,f2,f3; f1 = (float)rand()/((float)rand()+1.0); f2 = (float)rand()/((float)rand()+1.0); AIC_DCR = 0x00000001; PIOA_SODR = LED1; f3 = f1 / f2; PIOA_CODR = LED1; AIC_DCR = 0x00000003; Can anyone tell me whether they've looked into which toolset does floating point math faster, and why the code generated with the KEIL tools seems to only run about 1/2 as fast as the same code generated with IAR tools? Can anyone give me a suggestion for what I could do (software changes only) to speed up the math on the KEIL generated code?
Thanks Anders. I tried your test and got the same results. When I changed the initial value of flt to 1.0000001, the IAR tools ended up setting flt to 1.00000012 after the loop, while the answer with the KEIL tools remained unchanged at 1.000297. One more thing to look into and consider, agreed.
Do the IAR tools support a floating point format other than IEEE 754? Note that 754 is optimized for range and precision, not speed of arithmetic. There are other floating point formats that are more amenable to software arithmetic, and will also produce different results for any given sequence of operations. (No finite floating point representation is completely accurate.)
OOPS! I found out what the most significant factor was that made the IAR version of the project do math so much faster... Can't believe I didn't notice it before... The IAR project was configured to run from RAM while the KEIL project was configured to run from ROM...!! When the IAR project was re-configured to run from ROM it slowed down considerably... to ~5.1 usec's per divide, versus KEIL's ~8.2 usec's. Still significant, but not as significant as I thought it was. Very sorry for the confusion... totally my bad! Still looking into the accumulated error anomaly... Dave :-x
I don't particulary care for binary floating point. Check out http://www2.hursley.ibm.com/decimal/ for where I hope floating point on embedded controllers is heading. Don't know how much extra silicon this'll take, but it sounds pretty good.
FWIW, IAR's website states that they support IEEE-754 floating point arithmetic.
FWIW, IAR's website states that they support IEEE-754 floating point arithmetic. Yes, but it doesn't say whether or not they support anything else -- or at least I couldn't find it there -- and if so, what the default setting would be.
Just curious. Are you running ARM mode or THUMB mode? Jon
you just confirmed my previous statement: "the difference between the $1000+ toolsets was not big enough to choose one over the other" Erik
that should have been "the difference in performance between .... The original post suggested that the decision should be based on other named issues. Erik PS would it be possible to get an "edit" fonction, 8052 has it, so does SILabs. Yes, I know "preview" is there, but the hindsight usually appear a bit more than preview time after the posting.
I'm still an ARM/KEIL newbie, so I don't know if there's more to it than this, but it doesn't make any difference if I check or un-check the "Use Thumb Mode" checkbox on the compiler project options. The timing for the division remains the same no matter what the state of that checkbox is.
5.1 usec's versus 8.2 usec's is almost a 40% savings in execution time. If you've got a very large amount of division to do all the time, that is significant. If you're running several PID loops where the processes are related to each other, even small errors can accumulate and throw things off too. Don't get me wrong, I'm not trying to say the KEIL math performance is horrid or anything. And I'm not saying that the test a previous poster referred to is a perfect test. But, I think there's still more to look into. I agree with Erik that the bottom line is how well the code generated with a particular set of tools really works for your particular application, and whether or not there's a significant difference between those results and the results obtained from other tools. I also agree that support is a very big factor in the tool selection process. I am truly impressed, pleased and grateful for the quality and amount of advice and concern that posters in this forum have provided to me as I've been looing into this and other matters. Many thanks to all of you...!
would it be possible to get an "edit" fonction Thanks Erik. I'll add it to the list. We have made a couple of other enhancements to the forum in the last 2-3 days. 1) We have blocked replies to older forum threads and 2) We improved the speed of the thread list display (previously there was a 3-4 second delay--it should be almost instantaneous, now). Jon