InString Speed Test!

[ecube]

My results

msvcrt strstr          126
windows api strstr  1112(ugh)
Masm InString        220
InStringL               89 (don't know who wrote this one but is fantastic code)
ntdll strstr                   (undocumented? I couldn't get it to work)

[attachment deleted by admin]

[hutch--]

cube,

On my work PIV the MSVCRT strstr is faster than the InstringL proc. The API is very slow and the MASM32 module carries a bit too much overhead. It was never classed as fast, it just generally worked.

[ecube]

hutch--,
Really? I tested on many strings InStringL is always the fastest, seems to get better with longer strings IMO anyway.

[hutch--]

Cube,

What box are you running the tests on ? I did the test on a 2.8 gig Northwood core PIV.

[lingo]

E^cube,
It is my old Instring proc (at the end with L as Lingo)
http://www.asmcommunity.net/board/index.php?topic=13638.msg134462#msg134462

It is still the fastest proc
at my box with P4 3.6 GHz   :lol

times:
     timing msvcrt strstr - 319
     timing strstr - 1830
     timing InString - 337
     timing InStringL- 148

Regards,
Lingo   

[Seb]

Results on my AMD Athlon 64 X2 Dual Core:

Code Select Expand


msvcrt strstr   124
windows api strstr   1089
Masm InString   217
InStringL   89


Edit:

While I'm at it, would anybody mind explaining why Lingo's code is so much faster than the rests? Does having prologue and epilogue turned off make any difference in terms of speed? This is not the first time I've seen lingo's cryptic and very-hard-to-read code beat other codes, so I must ask: why? :dazzled:

[MichaelW]

The NTDLL strstr appears to be slightly slower than the MSVCRT strstr. Also, InString returns a character position instead of an address, so it's probably doing more work.



[attachment deleted by admin]

[EduardoS]

While I'm at it, would anybody mind explaining why Lingo's code is so much faster than the rests? Does having prologue and epilogue turned off make any difference in terms of speed? This is not the first time I've seen lingo's cryptic and very-hard-to-read code beat other codes, so I must ask: why? :dazzled:

Maybe he is skilled?  :8)

[Seb]

While I'm at it, would anybody mind explaining why Lingo's code is so much faster than the rests? Does having prologue and epilogue turned off make any difference in terms of speed? This is not the first time I've seen lingo's cryptic and very-hard-to-read code beat other codes, so I must ask: why? :dazzled:

Maybe he is skilled?  :8)

Yes, obviously he is. ::)

[ecube]

Results on my AMD Athlon 64 X2 Dual Core:

Code Select Expand


msvcrt strstr   124
windows api strstr   1089
Masm InString   217
InStringL   89


Edit:

While I'm at it, would anybody mind explaining why Lingo's code is so much faster than the rests? Does having prologue and epilogue turned off make any difference in terms of speed? This is not the first time I've seen lingo's cryptic and very-hard-to-read code beat other codes, so I must ask: why? :dazzled:

Yes hes very skilled , if you look at his code it makes sense he doesn't use the stack-frame and access the parameters directly(prologue and epilogue is turning off the ebp setup code,)

mov edi, dword ptr [esp+8] ;param 1
mov esi, dword ptr [esp+12] ;param 2
mov ecx, dword ptr [esp+16] ;param 3

instead of
mov edi, param1
mov esi, param 2
mov ecx,param 3


also if you read his code hes checks 2 things at once, uses byte alignment, and reading somethings in dwords. As Donkey has mentioned before the cpu reads everything in dwords, not bytes or words, all dwords, just shifts up and down when needed, so he uses a lot of speed techniques, all in all lingo is a n asm all-star.

[hutch--]

It did have that look of Lingo's code.  :bg

Something that is worth checking is doing a test on a much longer string, from memory the test piece was using a very short string and this may account for the bad result with the API which usually have SEH and other things around them to slow them up. A longer test piece would remove those factors to a large degree.

I was thinking of loading an external file of 16 or 32k just so you get past the minor overhead factors.

[Seb]

all in all lingo is a n asm all-star.

Agreed.

With the risk of going off-topic in the discussion, I have a question for lingo: Would you mind mind telling us curious fokes what optimization manuals or papers you read? I'm very interested in every aspect of Assembly code optimization, so it'd be greatly appreciated if you shared your resources with your fellow comrades at the MASM forum. :U

[hutch--]

Seb,

I think Lingo IS the optimisation manual, he has been producing very fast algos for a long time now.  :U

[ecube]

all in all lingo is a n asm all-star.

Agreed.

With the risk of going off-topic in the discussion, I have a question for lingo: Would you mind mind telling us curious fokes what optimization manuals or papers you read? I'm very interested in every aspect of Assembly code optimization, so it'd be greatly appreciated if you shared your resources with your fellow comrades at the MASM forum. :U

I'm not lingo but http://www.mark.masmcode.com/ and http://www.masm32.com/board/index.php?topic=5464.0 are good optimization pages.

[Seb]

Seb,

I think Lingo IS the optimisation manual, he has been producing very fast algos for a long time now.  :U

Hear, hear! :cheekygreen:

I'm not lingo but http://www.mark.masmcode.com/ and http://www.masm32.com/board/index.php?topic=5464.0 are good optimization pages.

Thanks!