Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Let your compiler figure it out!</p> <p>Seriously, if you're really concerned about optimizations at this level (and you shouldn't be unless it shows up in a profile), you should get used to looking at your compiler's assembly language output. You will be amazed what the compiler is doing on your behalf.</p> <p>All the people who are recommending math tricks either have bad compilers or they are underestimating their compilers. For example, try compiling this function:</p> <pre><code>unsigned long div1000000(unsigned long n) { return n / 1000000UL; } </code></pre> <p>Compiled with gcc 4.3.3 on x86 (-O3, -fomit-frame-pointer), I get:</p> <pre><code>$ objdump -d div.o -M intel test2.o: file format elf32-i386 Disassembly of section .text: 00000000 &lt;div1000000&gt;: 0: b8 83 de 1b 43 mov eax,0x431bde83 5: f7 64 24 04 mul DWORD PTR [esp+0x4] 9: c1 ea 12 shr edx,0x12 c: 89 d0 mov eax,edx e: c3 ret </code></pre> <p>In other words, the compiler took <code>n / 1000000UL</code> and turned it into <code>(unsigned long long)(n * 0x431bde83) &gt;&gt; (0x12 + 32)</code>. Why does that work? Off the top of my head, I have no idea! But the compiler decided that it would be faster than issuing a native divide.</p> <p>Moral of the story:</p> <ul> <li>don't optimize this unless you're sure it's a bottleneck.</li> <li>don't do fancy arithmetic (multiplying by the reciprocal, shifts, etc) unless you already know what your compiler is doing and you think you can beat it.</li> <li>benchmark the result -- only leave in a wart like fancy bitmath if you have demonstrated that you've outdone your compiler.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload