Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: Mike Williams on 14 Mar 2010 07:02 "MM" <kylix_is(a)yahoo.co.uk> wrote in message news:4vbpp5tpjnqh06i0befva6tstdvc4p8n6s(a)4ax.com... > No, the comparisons are very similar. Here are my final results, > done just now with the COMPILED app (compiled to native > code, optimise for fast code, advanced optimisations all unchecked): Those timings simply do not represent the speed of the different "endian swap" methods, for two main reasons. The first reason is that you are timing the code using a method that has a best resolution of one second for the overall result and the second reason, which is by far the most important reason, is that you are totally swamping the very small time of the "endian swap" code itself with the very large time required to get the data from the TextBox's Text property and convert it from a string into a Long. It's a bit like comparing the weight of two peas by placing each of them into a builder's skip and weighing the skips. It is also, incidentally, the reason why your code returns similar results in the IDE as it does in a native code compiled exe, because as well as the "n = "&H" & Text1" line taking a very long time to execute it is also an example of a "bottom heavy" statement (the opposite of the "top heavy" stuff I was talking about earlier). In such "bottom heavy" statements the time of execution of the compiled version is very large compared to the "pcode" overhead of the statement itself, and such statements run at similar speeds in the IDE (or as a pcode compiled exe) as they do in a native code compiled exe. In order to get the true timing of the things you are testing (the actual different methods of performing an edian swap) you need to get that "n = "&H" & Text1" out of the loop which is being timed. When you do that you will find that it all runs orders of magnitude faster and so you will then also need to use a timing method with a much higher resolution. Mike
From: MM on 14 Mar 2010 08:14 On Sun, 14 Mar 2010 11:02:05 -0000, "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote: >"MM" <kylix_is(a)yahoo.co.uk> wrote in message >news:4vbpp5tpjnqh06i0befva6tstdvc4p8n6s(a)4ax.com... > >> No, the comparisons are very similar. Here are my final results, >> done just now with the COMPILED app (compiled to native >> code, optimise for fast code, advanced optimisations all unchecked): > >Those timings simply do not represent the speed of the different "endian >swap" methods, for two main reasons. The first reason is that you are timing >the code using a method that has a best resolution of one second for the >overall result and the second reason, which is by far the most important >reason, is that you are totally swamping the very small time of the "endian >swap" code itself with the very large time required to get the data from the >TextBox's Text property and convert it from a string into a Long. It's a bit >like comparing the weight of two peas by placing each of them into a >builder's skip and weighing the skips. It is also, incidentally, the reason >why your code returns similar results in the IDE as it does in a native code >compiled exe, because as well as the "n = "&H" & Text1" line taking a very >long time to execute it is also an example of a "bottom heavy" statement >(the opposite of the "top heavy" stuff I was talking about earlier). In such >"bottom heavy" statements the time of execution of the compiled version is >very large compared to the "pcode" overhead of the statement itself, and >such statements run at similar speeds in the IDE (or as a pcode compiled >exe) as they do in a native code compiled exe. In order to get the true >timing of the things you are testing (the actual different methods of >performing an edian swap) you need to get that "n = "&H" & Text1" out of the >loop which is being timed. When you do that you will find that it all runs >orders of magnitude faster and so you will then also need to use a timing >method with a much higher resolution. > >Mike I've just repositioned n = "&H" & txtNumber outside the loop. Timings are: 1. CopyMem 13 13 13 2. Shifts 10 10 11 3. SwapEndian08 10 10 11 4. Bendian 11 10 10 5. String 16 15 16 The previous timings (with n = "&H" & txtNumber inside the loop): 1. CopyMem 19 19 19 2. Shifts 17 16 17 3. SwapEndian08 17 17 17 4. Bendian 18 17 17 5. String 22 22 22 Presumably the overhead for calling the function is the same in each case, since VB will be passing a pointer. Same with the return value being allocated to txtResult. So I do not understand where you're coming from when you state that "it all runs orders of magnitude faster", since the comparisons are very similar, i.e. Shifts, Swaps, and Bendians were all practically identical before (17), and they still are (10), after repositioning the n = "&H"... bit. MM
From: Jim Mack on 14 Mar 2010 08:57 MM wrote: > > So I do not understand where you're coming from when you state that > "it all runs orders of magnitude faster", since the comparisons are > very similar, i.e. Shifts, Swaps, and Bendians were all practically > identical before (17), and they still are (10), after repositioning > the n = "&H"... bit. If that's the way you'll actually use the function in code, then the comparison is valid for your purpose. It points up what smart programmers have said forever: optimize only in conjunction with a profiler. Fine tuning something that sits in the middle of a slow or rarely-used function is wasted effort. But in 'shootouts' of fastest code (like the vbspeed challenges), what matters is how the core function operates. You strip it down to the minimum, even subtract loop overhead, etc. It's still up to the end programmer to use the fastest code in a sensible way. So what you're doing with these various bits isn't testing how fast each one is, you're testing how it affects some larger bit of code. As Mike said, it's a bit like weighing pebbles by placing them on a brick resting on your scale. Pretty much, all pebbles are going to look the same then. Not a bad thing, just different from what we were doing. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Jim Mack on 14 Mar 2010 09:00 Mike Williams wrote: > > Do you mind if I hang on to your DLL to use > myself if I should ever find the need to perform such "endian" > swaps at a rapid rate? Not at all -- use away. I'll correct the "As Long" in the text. -- Jim
From: Nobody on 14 Mar 2010 10:02
"MM" <kylix_is(a)yahoo.co.uk> wrote in message news:4vbpp5tpjnqh06i0befva6tstdvc4p8n6s(a)4ax.com... > In each case I entered the string 4B3B2B1B into txtNumber. The same > calling routine was used in all cases: > > Dim start As Date > Dim n As Long > Dim count As Long > start = Now > For count = 1 To 1000000 > n = "&H" & txtNumber > txtResult = Hex$(Endian32_UsingCopyMem(n)) ' This line changes > as per method used - see below > Next > MsgBox "CopyMem: " & DateDiff("s", start, Now) > > 1. txtResult = Hex$(Endian32_UsingCopyMem(n)) > 2. txtResult = Hex$(Endian32_UsingShift(n)) > 3. txtResult = Hex$(SwapEndian08(n)) > 4. txtResult = Hex$(Endian32_UsingBendian(n)) > 5. txtResult = Hex$(Endian32_UsingString(n)) Besides what Mike suggested, you need to move txtResult = Hex$() outside the loop because you are also measuring the conversion to a Hex string in the loop. Try saving the result into a Long variable, then convert the string after the MsgBox. Also, use Timer function because it has a resolution of about 10 to 20 ms, so timing code would be: Dim start As Single start = Timer ' Loop here MsgBox "Time taken: " & Timer - start To see Timer resolution, use this tool: ClockRes: http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx Or you can use this VB code: Option Explicit Private Declare Function GetSystemTimeAdjustment Lib "kernel32" ( _ lpTimeAdjustment As Long, lpTimeIncrement As Long, _ lpTimeAdjustmentDisabled As Long) As Long Private Sub Form_Load() Dim lTimeAdjustment As Long Dim lTimeIncrement As Long Dim lTimeAdjustmentDisabled As Long GetSystemTimeAdjustment lTimeAdjustment, lTimeIncrement, _ lTimeAdjustmentDisabled ' Convert to milliseconds Debug.Print lpTimeIncrement / 10000 End Sub New computers and OS'es usually have the clock set to 15.625 ms, or 0.015625 Seconds. This translates to 64 times/Second precisely, or 64 Hz. |