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?
As to the replies to my comments, the rest refer to someone else ... getting a 'real' version to evaluate in a prior post. Unfortunately, I can't lie to KEIL 1) you should never lie. It is bad and will eventually come back and bite you in a large muscle. 2) not lying is not "unfortunate" in my book. 3) If you work for a company "known" not to use illegal copies, which "my company has purchased several copies of different KEIL tools over the years" should show there should be no problem. Sadly, KEIL doesn't support all micro's from all manufacturers ;-) That's where your brain get excersized by switching between toolsets. i use several different brands of emulators and "always" hit the wrong keys for the various functions for that reason. I once did the '51 using HiTech tools just not to switch back and forth as the project also involved an XA. I'm floored by your comment about not being able to evaluate anyone's compiler when using an eval version of their tools. Don't know if that's true or not... I Well, my opinion is "ignore the benchmarks, they are at best not telling much, at worst worthless" compile link and measure your actual job. Erik PS re benchmarks: have a look at competing manufacturers "benchmarks". Amazingly enough, they all are "the best"
Oh, one added note: When I had the opportunity to do a "real benchmark" the difference between the $1000+ toolsets was not big enough to choose one over the other for the code compactness (+-15%) or execution speed (+-20%). One exception: Tasking stated "you do not need to try our tools, they are the best" so they did not get evaluated, just dropped. None of the sub $1000 toolsets came even close. So, the choice should, in my opinion be based on 3 things: 1) and most important is the support any good? 2) do you like it and 3) does it support all uCs in the thingy. I think that all toolsets have strangths and weaknesses and, for that reason, a benchmark say nothing (does not avarage these out) creating the job does. Erik
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.