Re: Bit-order reversal (little-endian <--> big-endian)
- From: "David J Mark" <nntp45534-22@xxxxxxxxxxxx>
- Date: Fri, 30 Dec 2005 14:57:44 GMT
"Michael C" <nospam@xxxxxxxxxx> wrote in message
news:e$wky8TDGHA.532@xxxxxxxxxxxxxxxxxxxxxxx
> "David J Mark" <nntp45534-22@xxxxxxxxxxxx> wrote in message
> news:kb8tf.92237$lh.16000@xxxxxxxxxxxxxxxxxxxxxxxxx
>>Uh yeah. Of course we are talking about VB!
>
> VB is actually a very fast language. I remember demonstrating this to the
> resident C++ guru at work with a simple function that manipulated longs. I
> actually had vb running faster until he realised I was counting down to
> zero while he was counting up. Once he switched over to count down his was
> faster but only by a very small margin. If you have a function in VB that
> passes in longs and returns a long and you can manage to keep all the
> calculations as longs then VB will be extremely fast because most of the
> VB code will translate directly to assembly code. In many cases one line
> of VB code will translate to one instruction.
>
>>I benchmarked your solution against mine.
>
> Really you made a new solution, using all my suggestions and benchmarked
> that against mine. In fact, you just used my solution with one minor
No. I bench-marked my original. As I stated. THEN I added the two
changes. Yours below is different as it has unneeded loops (as I mentioned
in the previous post.)
> modification and benchmarked it against itself! Notice any similarities?
> :-)
>
> While lX > 0
> lResult = lResult * 2
> lResult = lResult Or (lX And 1)
> lX = lX \ 2
> lCount = lCount + 1
> Wend
>
> Do
> BitReverse1 = (BitReverse1 * 2) Or (DataBits And 1&)
> DataBits = DataBits \ 2&
> BitCount = BitCount - 1
> Loop While BitCount > 0
>
> In the one line you did write you left in all the same inefficencies:
See above. You are making the same bad assumption. I did not change
anything in the version I tested. The only thing I did with your do loop is
copy and paste it into a benchmark app.
>
> ReverseBits8 = lResult * 2& ^ (IIf(Nibble, 4&, 8&) - lCount)
>
> Putting an & on the end of 2, 4 and 8 isn't going to help, in fact it
> could have made it worse as vb might have stored it as a double otherwise.
> This is
I am too tired to look it up, but as I recall, I added the suffixes to avoid
the type conversion on one test and it didn't help. If you are sure that
you have some gee-whiz way to optimize the compilation of this one line of
code, then post it. Posting that it doesn't help is not really helpful in
and of itself.
> the steps I think it will go through (I'm not certain about all of them),
> each of which on it's own is quite inefficient:
> 1) Convert 4& and 8& to variants to pass into IIf
> 2) Return a variant from IIf
> 3) Do a variant subtraction of lCount from the result, returning the
> result as variant
> 4) Convert the variant to a double
> 5) Convert 2& to a double
> 6) Call the power function and return a double
> 7) Convert lResult to a double and multiply it by the result from the
> power function
> 8) Convert the result of that back to a long.
Wonderful, but you went to all that trouble to enumerate those to what end?
Nobody really cares about all of that. This is example code. If you have a
better example for that one line of code. Then post it. I really don't
care much about any of this as I am not the OP.
Certainly you can use a standard if then statement instead of the IIF. I
didn't as I tacked on the IIF as an afterthought (as I mentioned.) The IIF
is not pertinent at this point in the discussion. If you think about it, it
never really was.
>
> Also, I'm not sure how you benchmarked but the results where so different
> on my machine I had to check several times to make sure I'd done the
> testing correctly. For 2,560,000 iterations of each (10,000 iterations of
> each of the values from 0 to 255) mine took 188ms and yours 2515. This is
> what I would expect as the few extra iterations mine does would be far
> outweighed by the thousands of lines of assembly executed on the last line
> of your
I just ran a loop of 10,000 and I don't recall what the data was. Suffice
to say that my results were different.
> function. If you seperate out just that part and compare 2 ^ P to a loop
> you'll see that the loop is 4 times faster. Try this function against 2 ^
> P
So there's another thing that could optimize the last line. You could use a
lookup for the power of 2 (as somebody already stated.) Ultimately, my
design is faster (all things equal) as it avoids extra iterations. There's
really no arguing that. All of this other stuff about IIF is interesting
and all, but it is the design that should be considered first. Optimization
of individual lines of code is an afterthought. So take my design, optimize
the last line and you have a perfect solution. If you start with your
solution, you can't get there (unless you change your loop to look like
mine.)
>
> Public Function Power1(ByVal P As Long) As Long
> Dim x As Long
> Power1 = 1
> For x = 1 To P
> Power1 = Power1 * 2
> Next
> End Function
>
> Michael
>
.
- References:
- Bit-order reversal (little-endian <--> big-endian)
- From: Bob O`Bob
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: Rick Rothstein [MVP - Visual Basic]
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: Bob O`Bob
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: David J Mark
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: Michael C
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: David J Mark
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: Michael C
- Bit-order reversal (little-endian <--> big-endian)
- Prev by Date: Re: Default Error
- Next by Date: Re: Help with FTP
- Previous by thread: Re: Bit-order reversal (little-endian <--> big-endian)
- Next by thread: Re: Bit-order reversal (little-endian <--> big-endian)
- Index(es):
Relevant Pages
|