Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: Jim Mack on 18 Mar 2010 09:51 "Karl E. Peterson" wrote: Jim Mack wrote: > When we had this exact discussion here a couple of years ago, I placed > that function into a DLL, using a Typelib, and others here timed it > against the vbspeed code. > I wonder if it might've been this thread? > > http://groups.google.com/group/microsoft.public.vb.winapi/browse_thread/thread/be07e101f58d0ff8/7a29b0df16095b51 > > Or whether you're remembering another off-group list discussion? I > think that latter one was where I first became aware of Mike's endian > swap method. Could have been where the discussion started, but I remember going through a couple of iterations of modifying a copy of Stamina for testing, since it didn't use 486 instructions (for 386 compatibility). So this probably did move off-list after a while. BTW, some names in that thread I'd forgotten about... (-: -- Jim
From: Karl E. Peterson on 18 Mar 2010 15:47 Mike Williams wrote: > "Karl E. Peterson" <karl(a)exmvps.org> wrote... >> Mike Williams wrote: >>> 12.3 nanoseconds - Jim Mack's DLL as a Public function in module >>> 9.4 nanoseconds - Compiled VB code using all optimizations >>> 3.1 nanoseconds - Jim Mack's DLL exposed as a TypeLib >>> The results speak for themselves. >> >> I tend to consider those numbers suspicious. >> > > . . hmmm. I wonder if it is really me you view as suspicious, or just the > numbers ;-) LOL! I'd truly hate to disappoint you with the wrong answer. ;-) > I've just repeated the same tests this morning, in the cold > light of day and after a fresh boot up on my 2.4 GHz Q6600 Quad running > Vista, and on this machine I'm getting similar results, which are as > follows: > > 10.9 nanoseconds - Jim Mack's DLL as a Public function in module > 9.9 nanoseconds - Compiled VB code using all optimizations > 3.3 nanoseconds - Jim Mack's DLL exposed as a TypeLib Something else would seem to be afoot. Of course, I don't have the tests before me, so I must suspect them. >> It's almost incomprehensible to me that the added GetLastError call >> of the Declare'd function could quadruple the overhead. > > Well I've just tried timing a call to GetLastError and I'm getting a time of > about 10.8 nanoseconds for that call alone. Was it wrapped in a typelib, to avoid the overhead of VB calling it again and assigning its return to Err.LastDllError? <g> > It's quite probable that using > such a call would end up with the system calling GetLastError twice, and if > that is the case then GetLastError would be about 5.4 nanoseconds. Ahhhh, so much for replying inline without reading ahead... >> Am I misunderstanding how you describe that first test? > > I'm not sure, but I don't think you are. It is just a Private Declare > Function to Jim Mack's DLL in the Form's General declarations section (I get > very similar resuts if I instead declare it as Public in a Module). The > thing is, Jim Mack's machine code is using only a couple of instructions and > is very efficient whereas the optimized machine code that the VB compiler > comes up with for the specific case of the "vbspeed" VB code will almost > certainly be nowhere near as efficient. I'm sure that compilers are > extremely good these days, and certainly very much better than they were > when I was a lad (;-)), but they are not actually human (well, at least not > yet!) and they cannot always analyse your code to see what job you actually > want to perform in the way that a human can. Believe it or not I used to be > quite good at machine code, but that was more than twenty years ago and I'll > admit that I know zilch about machine code on modern processors! > > The speed difference is real, Karl. I'm not making it up ;-) Maybe I need to see it with my own eyes to believe it. Just doesn't sound possible. (Have you convinced Jim yet? <g>) > differences here are nanoseconds if the routines are called just once, but > the percentage difference is very large and they can add up to a signifant > saving if such routines are called a very large number of times. I definitely understand the significance there. > course if a routine such as Jim Mack's was turned into a routine that > accepts a pointer to a couple of arrays and if it reads the data in one > array and fills the other with the result of the endian swap (or perhaps > fills the existing array with it) then passing such an array to his DLL > (whether exposed as a TypeLib or called as a standard declared function or > whatever) will result in a time that is orders of magnitude faster than > passing the same array to the vbspeed VB code. That's pretty much what I did with Mike's code. I had a case where I had to plow through 100s of MBs flopping them about, so I wrote it into a single function call across the address range. If I could knock that from a few seconds down to an eyeblink, I'd be a happy camper. (I was working with Doubles, btw.) > For what it's worth, here is the code I used to perform the tests. I hope to have an hour to throw at this, this afternoon! Thanks... Karl -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 18 Mar 2010 15:53 Jim Mack wrote: > "Karl E. Peterson" wrote: > Jim Mack wrote: >> When we had this exact discussion here a couple of years ago, I placed >> that function into a DLL, using a Typelib, and others here timed it >> against the vbspeed code. > >> I wonder if it might've been this thread? >> >> http://groups.google.com/group/microsoft.public.vb.winapi/browse_thread/thread/be07e101f58d0ff8/7a29b0df16095b51 >> >> Or whether you're remembering another off-group list discussion? I >> think that latter one was where I first became aware of Mike's endian >> swap method. > > Could have been where the discussion started, but I remember going > through a couple of iterations of modifying a copy of Stamina for > testing, since it didn't use 486 instructions (for 386 compatibility). > > So this probably did move off-list after a while. > > BTW, some names in that thread I'd forgotten about... (-: Wow, now that you say that, we have had a lot of attrition (turnover?)... So, confidentially <g>, do Mike's results make sense to you??? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Jim Mack on 18 Mar 2010 16:35 Karl E. Peterson wrote: > > So, confidentially <g>, do Mike's results make sense to you??? I'm just getting back to this after a few days at SxSW (incredible scene, but I was working), and I glossed over a lot of messages. So I'm not positive which results you're talking about. But if you mean the ones where my (typelib) bendian.dll beat SwapEndian08, which in turn edged out my (Declared) bendian.dll, then I'm not terribly surprised or suspicious. It's always been true that Declared functions are slower than tlb-exposed ones (to avoid GetLast etc). But my recollection, as I expressed upthread, was that we'd explored these paths before and that an external function just couldn't beat Swap08. I never did the tests myself, I just went by others' reports. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Mike Williams on 18 Mar 2010 17:58
"Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:eBvYhPtxKHA.3536(a)TK2MSFTNGP06.phx.gbl... > I hope to have an hour to throw at this, this afternoon! Thanks... Okay. One other thing I should mention (since I'm basically an honest person ;-)) is something that has only just occurred to me in that I can squeeze quite a few more nanoseconds out of the vbspeed SwapEndian08 function in the test code I sent you by unwrapping it, which does speed it up quite a bit, although even then it is still about 60 per cent slower than Jim Mack's DLL when exposed in Project / References. Maybe you could check the results you are getting at your end from the code I recently posted, and then look at the other thing. Mike |