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?
Hmmm... interesting comments. I recall you making similar comments to me about getting a 'real' version to evaluate in a prior post. Unfortunately, I can't lie to KEIL and tell them that I'm going to buy more than one seat of these tools for this project, so I don't have the same leverage that you had :-( Like I said then, for whatever it's worth, my company has purchased several copies of different KEIL tools over the years, and we've been fairly happy with them. We've bought tools from an array of other vendors too. Sadly, KEIL doesn't support all micro's from all manufacturers ;-) 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 certainly hope it's not! I hope KEIL comments on your assertion. I just downloaded and installed the current version of the eval (V2.40) and it made no difference at all on my floating point division benchmark. Not being an expert with the IDE and all the configurable options, I'll play around with them more seeing if I can figure out how to get better math performance from these tools. I've already set the compiler optimization to full with emphasis on code speed, I'm using the same MCK, the same wait states, the same target memory (flash ROM), etc. between the projects on the two toolsets, on the same eval board. The option to select ARM or THUMB mode doesn't seem to have any effect on the execution speed of my division test. QUOTE by Al Bradford: "Found that most so called benchmarks created more confusion that information. But I can safely say that IAR is NOT twice as fast as Keil. No, I will not share my results. I will use them as one input to my evals but I wouldn't bet a penny on them." QUESTION: Why would you use your results if you wouldn't bet a penny on them? QUESTION: Are you (Al) responsible for the benchmark results KEIL's posted on their website? This is what I know --- the same code I build with IAR versus KEIL tools (other than the startup code, which I've tried to insure is functionally equivalent where it matters) sure runs differently on the two different evals. Less than 3 usec's per divide for IAR, more than 8 usec's per divide for KEIL. I need floating point division performance more than just about anything else on this project, otherwise I wouldn't be so focused on it. I currently refuse to believe that the tool vendors ship functionally crippled math libraries with their evals, or purposefully release evals that by design can't compile good, efficient code. What's an eval for, anyway?
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.