> Sometimes I deal with circular buffers, so if find this interesting. I > always wrap around using an if-statement mainly for clarity: > > ++idx; > if(idx >= RING_SIZE) > idx = 0;
My take on this (and I know I started this... Sorry!) is that unless you *really* need the performance edge - i.e. for some tricky, resource limited embedded app or something - then you should go with the conditional test. It is (arguably) slowest, but is clear and easy to understand. Pretty much all the alternatives are harder to comprehend. > But, from what is being said here, the conditional version is > more expensive > than the arithmetic version? I guess that makes sense since > the condition > version results in a CMP/setting flags/JGE where the > arithmetic version is > one instruction (IDIV). In principle, any conditional test that actually causes a branch is expensive, as it will (probably) mean the pipelines need to be flushed and refilled, may cause cache misses, etc., etc. However, if the branch predictor guesses right, you might not take the branch, making it pretty cheap. *Possibly* cheaper than the IDIV operation, in this case. The arithmetic version needs the remainder, so *in principle* you need to do divide/ multiply/ subtract - but on x86 (for example) IDIV returns the remainder in EDX for a 32-bit operation, so it is pretty cheap to do. But probably still more expensive than a simple binary and operation... > Along those lines, how does this apply to fmod()? Well. Can of worms... > What is your experiences with the efficiency of fmod()? In > your opinion, > which would be "better"? I develop using the GNU C/C++ > libraries, if that makes a difference. The C libs I've actually looked at recently (newlib and glibc) both have fairly complicated code to implement the fmod family of functions, so that (at library build time) the "best" option is set for the hardware in question. In general they do a decent job. [Aside: But, at least one of the commercial toolchains we use has a fmod() implementation that returns bogus results on embedded PPC targets at runtime (I won't say which tool vendor, but it seems like it may be related to a newlib issue - if you really care, I'm sure google will turn something up...) ] So... Harking back to your example, if the value of "radians" is many cycles too large, your conditional test might iterate many times, and that does tend to get expensive, so the fmod would likely be cheaper. But if "radians" is generally within one cycle of the bounded range, and if the branch predictor guesses right, then the conditional test can be quickest. Anyway - what it comes down to is: If it *really* matters, time it and see which is best, with your tools, on your platform, otherwise, go with whichever you find easiest to understand. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
