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?
Oh... Erik, I see... you mean ignore other people's benchmarks... not your own. That's exactly what I'm doing... writing my own tests and measuring the results. I thought you were implying that the benchmarks I wrote myself were not valid because the eval version of the tools were somehow crippled or otherwise compromised, so that the actual code that was generated was by design, flawed (i.e., slow, etc.). And, you're 100% right about not lying. Can't say that I've never done it, but I sure try not to. Honesty is always the best policy. The topic of getting a full version of the tools from KEIL to eval is a dead horse as far as I'm concerned. I've asked, they've declined, except for the offer to buy it to try it and we'll give you a refund if you don't like it. I'm not complaining about that, I just can't do it that way (at least not yet). Do you really believe that the eval tools are somehow crippled relative to the floating point library?
Oh... Erik, I see... you mean ignore other people's benchmarks... not your own. Not really, I do not believe in "benchmarks" I believe in how my code, which is not written as a benchmark, perform. Do you really believe that the eval tools are somehow crippled relative to the floating point library? well, it frequently comes up that the '51 eval does not include fp. erik
Dave; I am not an employ of Keil. No, the benchmarks published by Keil on their website are not my bench marks. I use my benchmarks for a specific purpose but not to select a compiler by running a very selected program set. Yes, I doubt some of my results, just as you appear to doubt some of your test. If you are just interested in your float divide effort and some other compiler does the job for you, go for it. I was just trying to pass along some info on benchmarks in general and trying to raise a REd flag about being too myoptic in your tool selection. No matter what you say about not using other run time libs of the tools, you will be using many built-in run time functions. I'm not talking about standard lib functions like printf, etc. I suggest that you google 'Benchmarks' and look at the many comments and cautions about benchmarks. One problem is most talk about PC or workstation environments.
Slightly off topic, but I think this can be interesting when not only speed but also the correctness of the float calculations are important. Try the following program
#include <stdio.h> float a = 2.0009763; float b = 2.0009763; static float test(float tst) { tst/=a; tst*=b; return tst; } main() { int lc; float flt=1.0; for (lc=0; lc<1000; lc++) { flt=test(flt); } printf("Correct result:\t 1.000000\n"); printf("IAR result:\t 1.000000\n"); printf("ADS result:\t 1.000000\n"); printf("Keil result:\t 1.000297\n"); printf("Current compiler:\t %f\n",flt); }
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