From: Jim Mack on

"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
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
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
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
"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


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