From: MM on
On Fri, 12 Mar 2010 09:44:28 -0000, "Mike Williams"
<Mike(a)WhiskyAndCoke.com> wrote:

>"MM" <kylix_is(a)yahoo.co.uk> wrote in message
>news:qfqjp55b82u5dlkbpihknnugu21tsdho3g(a)4ax.com...
>
>> [In response to 'Nobody's post] I'll write up a speed
>> comparison test later, including the htonl one and the
>> VB ones. That routine you provided seems quite
>> complicated with all the ANDs and ORs. I do have
>> access to assembler/C written shifts in vbhlp32.dll,
>> which is a free non-COM library that I am using
>> already. Maybe a routine could be built up using
>> shifts, as that is the approach I've seen in C and
>> Pascal examples.
>
>Shifts would obviously be much less complicated and faster than native VB
>code (which has to get around the fact that VB does not provide real shift
>methods and the fact that it does not provide unsigned Longs) but generally
>any code that calls a declared function to perform a very small task is
>slowed down by the overhead of the call itself, and so in many cases the
>speed difference is not quite what you might expect it to be.
>
>I've just tested a few different methods of performing your "endian swap",
>including a CopyMemory method and the native VB method posted by 'Nobody'
>and the call to htonl in "wsock32.dll" method that you mentioned. All tests
>were performed as a standard native code compiled exe of course, which is
>how your app will almost certainly be compiled.
>
>The Copymemory method used a number of calls to Copymemory and, as expected,
>was the slowest of the three. The call to htonl in wsock32.dll was the
>fastest, but the straight VB code posted by 'Nobody' came a respectable
>second. I'm not sure whether it can be optimized a little further (maybe,
>but possibly not) but it is quite useful even as it stands. Here are the
>results I got on my own machine (a relatively slow Celeron laptop):
>
>0.215 microseconds for the CopyMemory method
>0.056 microseconds for Nobody's VB method
>0.025 microseconds for wsock32.dll method

Oh, that's impressive! Especially the wsock32.dll method.Maybe I'll
relax my "dependency fear" and take another look. Would I be right in
saying that a Declare Function for htonl() would work on:

Windows 98 SE
Windows 2000
Windows XP
Windows Vista (32-bit)
Windows 7 (32-bit)

without modification?

MM
From: Mike Williams on
"MM" <kylix_is(a)yahoo.co.uk> wrote in message
news:7glkp5pusfvt7k8csmorojgpcjdr26k7ea(a)4ax.com...
>>0.215 microseconds for the CopyMemory method
>>0.056 microseconds for Nobody's VB method
>>0.025 microseconds for wsock32.dll method
>
> Oh, that's impressive! Especially the wsock32.dll method.
> Maybe I'll relax my "dependency fear" and take another
> look. Would I be right in saying that a Declare Function
> for htonl() would work on [various version of Windows]

Quite probably, but I wouldn't bother because the straight VB code method
posted by Donald Lessau, which he got from
http://www.xbeat.net/vbspeed/c_SwapEndian.htm is even faster than a call to
wsock.dll htonl. Here are the timings on my own machine when run as a
standard native code compiled exe:

0.215 microseconds for the CopyMemory method
0.056 microseconds for Nobody's VB code method
0.025 microseconds for wsock32.dll method
0.018 microseconds for the VB code method posted by Donald Lessau

Mike


From: MM on
On Fri, 12 Mar 2010 18:56:41 -0000, "Mike Williams"
<Mike(a)WhiskyAndCoke.com> wrote:

>"MM" <kylix_is(a)yahoo.co.uk> wrote in message
>news:7glkp5pusfvt7k8csmorojgpcjdr26k7ea(a)4ax.com...
>>>0.215 microseconds for the CopyMemory method
>>>0.056 microseconds for Nobody's VB method
>>>0.025 microseconds for wsock32.dll method
>>
>> Oh, that's impressive! Especially the wsock32.dll method.
>> Maybe I'll relax my "dependency fear" and take another
>> look. Would I be right in saying that a Declare Function
>> for htonl() would work on [various version of Windows]
>
>Quite probably, but I wouldn't bother because the straight VB code method
>posted by Donald Lessau, which he got from
>http://www.xbeat.net/vbspeed/c_SwapEndian.htm is even faster than a call to
>wsock.dll htonl. Here are the timings on my own machine when run as a
>standard native code compiled exe:
>
>0.215 microseconds for the CopyMemory method
>0.056 microseconds for Nobody's VB code method
>0.025 microseconds for wsock32.dll method
>0.018 microseconds for the VB code method posted by Donald Lessau

But the fastest shown on the page is Mike D Sutton's SwapEndian08 at
0.010�s. It's also a lot more concise. Now I wonder what would happen
if Mike D Sutton's code were changed to use assembler shifts instead
of multiplication, division etc! Here are the possible calls
available:

integer = vbShiftLeft(integer, count)
long = vbShiftLeftLong(long, count)
integer = vbShiftRight(integer, count)
long = vbShiftRightLong(long, count)

MM
From: Jim Mack on
MM wrote:
>
> But the fastest shown on the page is Mike D Sutton's SwapEndian08 at
> 0.010�s. It's also a lot more concise. Now I wonder what would
> happen if Mike D Sutton's code were changed to use assembler shifts
> instead of multiplication, division etc! Here are the possible calls
> available:
>
> integer = vbShiftLeft(integer, count)
> long = vbShiftLeftLong(long, count)
> integer = vbShiftRight(integer, count)
> long = vbShiftRightLong(long, count)

It would be markedly slower. Guaranteed.

--
Jim

From: Mike Williams on
"MM" <kylix_is(a)yahoo.co.uk> wrote in message
news:t67lp5dhr36arbekqbi7f82etr2i57bsqa(a)4ax.com...

>> [Mike W wrote] Quite probably, but I wouldn't bother
>> because the straight VB code method posted by Donald
>> Lessau, which he got from
>> http://www.xbeat.net/vbspeed/c_SwapEndian.htm is
>> even faster
>> 0.215 microseconds for the CopyMemory method
>> 0.056 microseconds for Nobody's VB code method
>> 0.025 microseconds for wsock32.dll method
>> 0.018 microseconds for the VB code method posted
>> by Donald Lessau
>
> [MM wrote] But the fastest shown on the page is Mike
> D Sutton's SwapEndian08 at 0.010�s. It's also a lot
> more concise.

The code I mentioned, the code that was posted by Donald Lessau, /IS/ Mike
Sutton's SwapEndian08 code! It runs at 0.018 microseconds on my own machine
because it happens to be a fairly old and modest Celeron laptop that is
obviously slower than the machine used to test the routines on the vbspeed
site.

> Now I wonder what would happen if Mike D Sutton's
> code were changed to use assembler shifts instead
> of multiplication, division etc! Here are the possible
> calls available: [snipped].

The code itself would probably run faster simply because it is neat machine
code (although I think that the VB6 compiler might actually produce a shift
when it is asked to provide an integer divide by a power of two, although I
haven't actually tested it yet to see and overall it would probably not be
as fast anyway). However, I think that if you were calling such a machine
routine in order to perform just one conversion then the overhead of the
call might wipe out all the speed benefits of the assembler code, and even
perhaps negate them.

Mike



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1