Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: MM on 12 Mar 2010 10:09 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 12 Mar 2010 13:56 "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 12 Mar 2010 15:05 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 12 Mar 2010 15:45 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 12 Mar 2010 19:04
"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 |