Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: MM on 13 Mar 2010 05:21 On Sat, 13 Mar 2010 00:04:36 -0000, "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote: >"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. I am not THAT up on assembler, so is a shift left by 1 bit the equivalent of multiplying by 2? MM
From: Mike Williams on 13 Mar 2010 05:57 "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:8opmp5d1crhu5eicr8b7jv4vpijii29uif(a)4ax.com... > I am not THAT up on assembler, so is a shift left > by 1 bit the equivalent of multiplying by 2? Yes, as long as it is a straight forward shift and you are not performing an operation that rotates or that shifts in the carry bit from a previous operation. Actually it's 25 to 30 years ago when I used to write machine code and a lot has changed since then. At that time there were no internal or external FPUs (at least not in the systems I used) and there were not even any integer multiplication or division operations in the processor itself or outside of it, and so all multiply and divide and other mathematical operations (even integer multiplies and divides) had to be performed by a combination of shifts and rotates and additions and subtractions. These days things are quite different and there are all sorts of such functions built in to the CPU's ALU and in fact the built in integer divides and multiplies may have rendered shifts for such operations almost obsolete (or perhaps not?). My machine code knowledge is so out of date that I really don't know any more. There are quite a few people here who also code in machine code or ASM and who are up to date on it and I'm sure one of them will come along quite soon and fill in the details. Mike
From: Mike Williams on 13 Mar 2010 08:54 "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message news:OLJ3wvpwKHA.3408(a)TK2MSFTNGP06.phx.gbl... > Yes, as long as it is a straight forward shift . . etc I forgot to mention (although I expect that you know this already) if the leftmost bit is set before you perform the shift then that bit will end up in the carry flag (or at least that's the way it worked 25 to 30 years ago!) and you need to take account of it depending on what you are actually doing. Anyway, Jim Mack and others will no doubt be along soon and they'll ubdoubtedly have their piece to say about the out of date rubbish I've just told you ;-) Mike
From: MM on 13 Mar 2010 09:53 On Fri, 12 Mar 2010 15:45:52 -0500, "Jim Mack" <jmack(a)mdxi.nospam.com> wrote: >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. No, it's not. It's even faster than SwapEndian08. Here's my latest attempt: Function Endian32_UsingShift(ByVal n As Long) As Long Endian32_UsingShift = ((ShiftLL(n And &HFF&, 24)) _ Or (ShiftLL(n And &HFF00&, 8)) _ Or (ShiftLR(n And &HFF0000, 8)) _ Or (ShiftLR(n And &HFF000000, 24))) End Function returns 18 secs for 1 million iterations on my Sempron 2.8 on Windows 98 SE. However, SwapEndian08 returns 19 secs. The shifts are from Crescent's QuickPak Professional. MM
From: MM on 13 Mar 2010 09:55
On Sat, 13 Mar 2010 13:54:11 -0000, "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote: >"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message >news:OLJ3wvpwKHA.3408(a)TK2MSFTNGP06.phx.gbl... > >> Yes, as long as it is a straight forward shift . . etc > >I forgot to mention (although I expect that you know this already) if the >leftmost bit is set before you perform the shift then that bit will end up >in the carry flag (or at least that's the way it worked 25 to 30 years ago!) >and you need to take account of it depending on what you are actually doing. >Anyway, Jim Mack and others will no doubt be along soon and they'll >ubdoubtedly have their piece to say about the out of date rubbish I've just >told you ;-) Well, see my latest post (just before this one) on using shifts. It's faster than SwapEndian08! MM |