New article : bitshifting vs. integer division

Thread: New article : bitshifting vs. integer division

1. Senior Member
Join Date
Dec 1969
Posts
19,082

New article : bitshifting vs. integer division

Oh, look, I know it&#039;s not generally accepted practice to announce articles (aside from ASPFAQs), but here&#039;s a new article I&#039;d like to get some discussion around :<BR><BR>http://rtfm.atrax.co.uk/articles/article_17.asp<BR><BR>j<BR><BR>

2. Senior Member
Join Date
Dec 1969
Posts
96,118

I don't get this part...

And finally, if some deluded VBScripter tells you that VBScript has an integer division operator and JScript doesn&#039;t, just smile and nod politely. You know better. <BR><BR>************<BR><BR>HUH???<BR><BR>Okay, let&#039;s see you do<BR> x = 371 19<BR>in JS code.<BR><BR>(Answer:<BR> var x = Math.floor( 371 / 19 );<BR>but how does bit shifting have anything to do with this?)<BR><BR>Other than that... <BR><BR>I&#039;m surprised that JS showed that much difference. The actual hardware operation (&#060;&#060;1 vs. *2) is maybe a dozen or two nanoseconds. But all the gobbledygook that the JS scripting language adds to the operation should *surely* adds a microsecond or two to the time.<BR><BR>Well, in fact, your times show something like that: 6 microseconds for shift, 12 for divide. But there is NO WAY that a divide operation even *takes* 6 microseconds! So how to account for the additional time?<BR><BR>I think I&#039;m going to guess that it is because when you do bitshift JS *knows* that it will work with integer inputs and produce an integer output. With divide, JS has to assume that the result will be floating point and converts operands each time through the loop. I do know that VariantChangeTypeEx (the COM function) is pretty ugly and slow, so this might make sense.<BR><BR>But I&#039;m grasping at straws. I wouldn&#039;t have been surprised at a one or even two microsecond difference. But, again, I can&#039;t see anyway that a divide (even a floating point divide) takes 6 microseconds.<BR><BR>

3. Senior Member
Join Date
Dec 1969
Posts
19,082

RE: I don't get this part...

that statement was just me being facetious as usual - there&#039;s no big grounding in fact there ;-)<BR><BR>I was pretty surprised at the difference - though &#039;Code Complete&#039; quotes something like a 90% saving in C code. It was fairly interesting to see the saving at work - I reckon a left-shift is the most useful of the two. Just one of those little interesting points you sometimes dig up, even if they&#039;re not very useful. I reckon you&#039;re probably correct about the implicit work going on behind the scenes, too.

4. Senior Member
Join Date
Dec 1969
Posts
96,118

I had to bump the loop count up to 1,000,000 to get usable times on my machine.<BR><BR>And I got:<BR><BR>divide: 1071 milliseconds<BR>shift: 977 milliseconds<BR><BR>Now *THAT* is in line with what I expected!<BR><BR>1.07 microseconds per iteration vs. 0.98 microseconds.<BR><BR>Less than 100 nanoseconds difference. Much more reasonable.<BR><BR>I would guess that it&#039;s because that old P2 has really slow floating point hardware and, as I stated, the divide has to be done in floating point.<BR><BR>(This is a dual-processor XEON machine running at 1.8GHz with 1GB of RAM. Wow! I had never even looked at the speed before! No wonder it&#039;s fast doing ordinary crap like compiling. And I thought I only had 512 MB. Amazing what you can learn when Atrax prods you to.)<BR><BR>

5. Senior Member
Join Date
Dec 1969
Posts
19,082

RE: It's your machine!

hmmm..... would this mean it&#039;d show the same sort of difference in, say, C code?<BR><BR>It&#039;s still usable, since I have a client who&#039;s still running a dual P2 webserver, which would have the same crappy hardware? That&#039;s a pretty small difference on your machine. I&#039;ll post a folow up to the article on this....

6. Senior Member
Join Date
Dec 1969
Posts
19,082

Just tried it......

.... on my AMD 2100/512Mb<BR><BR>very small difference indeed. bitshifting would edge it on an average by about 2 percent (!)

7. Senior Member
Join Date
Dec 1969
Posts
19,082

RE: Just tried it......

same sort of result on my P3 450 development box - must be a P2 thing.<BR><BR>I&#039;ll try it later on my old 133 Pentium I<BR><BR><BR><BR><BR>

8. Senior Member
Join Date
Dec 1969
Posts
96,118

I'm betting on floating point...

P1 will probably even show the divide to be worse.<BR><BR>Maybe not. I dunno where it was that they really pushed the envelope of floating point into new realms. That might have been part of the jump from P2 to P3.<BR><BR><BR>

9. Senior Member
Join Date
Dec 1969
Posts
96,118

On my 550MHz Athlon...

...at home, with 384MB of RAM:<BR><BR>division: 2.6 microseconds<BR>shift: 2.3 microseconds<BR><BR>!!!!! <BR><BR>Okay, go figure out *THEM* numbers!<BR><BR>Averages of 5 runs. But on *no* run did the shift run faster than the division!<BR><BR>Note that the cruddy old 550MHz Athlon is only 2.5 times slower than the Intel XEON 1.88GHz!<BR><BR>"By the numbers" the Intel chip, compared to the Athlon, is only effectively a 1.4GHz chip! <BR><BR>I would have to guess that AMD went *all out* in making the floating point ops *highly* optimized on the Athlon, wouldn&#039;t you?<BR><BR><BR><BR>

10. Senior Member
Join Date
Dec 1969
Posts
96,118

I am just too damned tired...

I showed *you* the RIGHT numbers here, but I had printed them backwards on my test page. So I thought something was crazy.<BR><BR>Then, re-reading the above msg, I said "wait a sec...those numbers are *right*." So I went back and looked at the page. Sigh.<BR><BR>Okay, so everything above is right except my idiocy about saying shift wasn&#039;t faster than divide. Sigh, and double sigh.<BR><BR>Anyway, the Athlon 550MHz machine *acts* like an Intel 750MHz machine, or so. Nice thing to know. Means I won&#039;t want to get rid of it quite so soon. &#060;grin /&#062;<BR><BR>

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•