WinNT speed vs. Win95/98

[Paul Squires]

Thanks Hutch,

99% of the time I use it to copy data from one TYPE variable to
another. Sometimes it is a straight copy, other times I only copy
one half of the first variable into the other, etc... I find
being able to specify the source address (which could be half
way within a TYPE variable) and a destination address very
convenient.

There are a couple of places in my code where I will put the
code directly instead of incurring the overhead of setting up
the function call. Thanks.

BTW, would you happen to have a super fast way to retrieve a
defined portion of a TYPE variable into a DYNAMIC string. Currently,
I am using your MemCopyD routine to copy from the VARPTR of the
TYPE to the STRPTR of the dynamic string for a given length value.
It works fine - is that way okay. It seems to be faster than using MID$.

Thanks,







------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Steve Hutchesson]

Paul,

In most instances, probably not but from memory I changed it to
LONG because I use LONG more often than DWORD. properly addressing
should be done in DWORD as LONG has less range and this may in the
future cause a problem if the addresses are higher than 2 gig which
is possible with Microsoft operating systems.

Just as an aside, what would the average length be that you are
copying as this algo using REP MOVSD is better suited for lengths
over 64 bytes long. If you were doing copying of much shorter data
there is probably a more efficient way to do it.

The other factor is if speed matters, the code is small enough to
directly inline rather than put in a function so it may be worth
considering.

Regards,

[email protected]

------------------

[Paul Squires]

Thanks Hutch,

That is exactly the memcopy routine I was using. I should have
explained better in my previous post that the GPF's were an
algorithm error and not an error due to the inline assembly.

BTW, the declaration of your routine that I was using specifies
DWORD's instead of LONGS. I am pretty sure I copied it from an
old post you made (maybe I lifted it from POFFS). Does it make
any difference????

Thanks,



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Steve Hutchesson]

Paul,

The following function works fine on any Intel or AMD processor,
its standard asm code and does nothing exciting, just make sure you
pass addresses of both source and destination to it and the length
of the copy needed.

If speed is critical and you are only calling it from one place in
the program, it would save you the stack overhead if you placed it
directly inline instead of calling it as a function but as this
function does not use LOCAL variables, the saving would not be very
big.

Regards,

[email protected]

  ' ###########################################################################
  
  FUNCTION MemCopyD(ByVal src as LONG, _
                    ByVal dst as LONG, _
                    ByVal ln as LONG) as LONG
  
      #REGISTER NONE
  
        ! cld
  
        ! mov esi, src
        ! mov edi, dst
        ! mov ecx, ln
  
        ! shr ecx, 2
        ! rep movsd
  
        ! mov ecx, ln
        ! and ecx, 3
        ! rep movsb
  
      FUNCTION = 0
  
  END FUNCTION
  
  ' ###########################################################################

------------------

[Paul Squires]

Sorry it took me so long to respond.

I banged my head over this all day and it appears the error is
triggered by the way I was processing duplicate keys! I guess
that would explain why it worked sometimes and not others. If
the original 10,000 keys had no duplicates then it would have
ran okay. I am back on the right track now.

Lance, I understand the PT policy 100% - no need to worry. I am
not distributing the PT header files or any source that references
calling the DLL. Only the DLL is being distributed. The only
reason I included it was to see if my algorithms were even in the
same ballpark as PowerTree. It looks promising for a first attempt.

BTW, you can close this thread now.

Thanks,

Paul


------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Semen Matusovski]

I also have no problems under Win2K/SP2, PIII-800.
I like Msgbox (about how fast "Comet" is)


------------------
E-MAIL: [email protected]

[Peter Lameijn]

Results on AMD Duron 800MHz, 192Mb RAM: (NT4-SP6a)
Note: from 10 times run, I get 4 times GP Error, and 6 times
a normal termination (?)


Comet:
========================
0.951 - 10508 recs/sec

PT:
========================
0.581 - 17016 rec/sec


------------------
Peter.
mailto[email protected][email protected]</A>



[This message has been edited by Peter Lameijn (edited August 01, 2001).]

[Sven Blumenstein]

Originally posted by Lance Edmonds:
Sounds like a clue in there -> mine is an AMD CPU too.

Perhaps Paul uses Inline ASM stuff wich isn't supported by
AMD CPU's? (just guessing)




------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected]s[email protected]</A>

[Scott Turchin]

Runs fine on my Intel Win2k box, 128 megs, P733...(Work machine)...

===Comet===

Keys have been added. The Index file test.btx has been created.
added 10000 keys 1.332 Recs/Sec 7510.51041371888



------------------
Scott

[Lance Edmonds]

Sounds like a clue in there -> mine is an AMD CPU too.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Sven Blumenstein]

Originally posted by Lance Edmonds:
Win2K/SP2/128Mb and I get a GPF.

I've the same configuration here at Work. Win2K with SP2 running
on a 900mhz Celeron with 128meg RAM. And it works!

At home I've a 800mhz Athlon with 785meg RAM, Win2K with SP2 -> GPF

Hope you find the error, Paul

------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected]s[email protected]</A>

[Lance Edmonds]

Win2K/SP2/128Mb and I get a GPF.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Sven Blumenstein]

Originally posted by Jack Death:
Hi, did it on Win2K, 200 MHz dual pentium Pro (lame, but all I got
with Win2k)

Comet:
========================
8.125 - 1231.26 recs/sec
8.266 - 1210.25 "

PT:
========================
3.828 - 2613.26 rec/sec
3.906 - 2561.18 "

Hmmm.... tested it here at Work and it runs perfect!

Perhaps Comet doesn't work with 785meg RAM? Here at Work I've only 128meg



------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected]s[email protected]</A>

[Lance Edmonds]

Folks, this is just a gentle reminder that the terms of the PowerTREE license do not allow distribution of source code or headers for PowerTREE itself, so Paul must omit that portion of his code from his test app if he wants to send it out...

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Jack Death]

Hi, did it on Win2K, 200 MHz dual pentium Pro (lame, but all I got
with Win2k)

Comet:
========================
8.125 - 1231.26 recs/sec
8.266 - 1210.25 "

PT:
========================
3.828 - 2613.26 rec/sec
3.906 - 2561.18 "



------------------

[Sven Blumenstein]

>I expect you see the first message box then everything explodes?

Yes, Sir!

------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected]s[email protected]</A>

[Paul Squires]

Thanks again Sven,

The source for the Comet Indexing System is compiled directly
into the EXE, that is why I can't post the source to the demo.

At what point do you get the failure. There should be an initial
message box titled "Comet Insert Test", then it inserts the 10,000
records, then another message box "Comet Results", then it does
the same thing for PowerTree.

I expect you see the first message box then everything explodes?

Thanks,



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Sven Blumenstein]

Still GPF's at the same position:

00402FBB 0F AF 0D AC D4 40 00 imul        ecx,dword ptr ds:[40D4ACh]
00402FC2 03 4D 0C             add         ecx,dword ptr [ebp+0Ch]
00402FC5 8B 1D 8C D4 40 00    mov         ebx,dword ptr ds:[40D48Ch]
00402FCB 3B 04 8B             cmp         eax,dword ptr [ebx+ecx*4] ; <--- GPF
00402FCE 7C 05                jl          00402FD5
00402FD0 E9 78 00 00 00       jmp         0040304D
00402FD5 8B 85 74 FF FF FF    mov         eax,dword ptr [ebp-8Ch]
00402FDB F7 2D 38 D4 40 00    imul        dword ptr ds:[40D438h]
00402FE1 03 45 0C             add         eax,dword ptr [ebp+0Ch]

Is the Source for the Demo App such a secret? If not, send it
to my home mail address. With the PB Debugger, I can
find out the exact position. (Or just do it yourself on a Win2K System).


------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected]s[email protected]</A>

[Paul Squires]

Thanks Sven,

Could you download the demo again and give it another run. I
commented out some inline assembler that may be causing
the GPF and used a regular BASIC function instead.

Could you please let me know if it still GPF's on Win2K.

It runs fine on my Win95 and Win98 system. The inline assembler
is a call to Hutch's MemCopyD routine which I may be calling
incorrectly and Win95/98 is just not reporting it.

Thanks,



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Sven Blumenstein]

Hmm.... it causes a GPF under Win2K...
The GPF is caused in the Exe. Not in the DLL.
------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected][email protected]</A>

[This message has been edited by Sven Blumenstein (edited July 31, 2001).]