Huge time for crt__wcslwr

[KeepingRealBusy]

I tried to call crt__wcslwr inside the code timing macros. It produced a huge negative number. This was repeatable. I thought it might be because this was on a dual core AMD, so I brought it over to my single core laptop Intel. It fails the same way here. This was a modification of MbMiniDll_call_w_timings2.zip from JJ, trying to force a copy of wSrc to lower case just for a baseline comparison of  my later code.

Any thought, anyone?

[qWord]

It produced a huge negative number.

Probably your code(-block) runs in less then one clock.
However, for a more detailed answer you should see a fortune teller  :wink

[KeepingRealBusy]

Thank you for finding it. I was converting all wide characters from 0 to FFFFh, but started with ------- 0! Oh, well.

[MichaelW]

The most likely explanation for a very large count is that something interfered with the reference loop (the one that measures the loop overhead), making that count larger than the count for the test loop. So when the count for the reference loop is subtracted from the count for the test loop, you get a negative count, or a very large count when interpreted as an unsigned value. Within my experience delaying for several seconds before running the first test, to allow time for the system activities involved in launching the app (disk cache activities, for example) to subside, will eliminate most of these bogus counts.

Code Select Expand


;==============================================================================
    include \masm32\include\masm32rt.inc
    .686
    include \masm32\macros\timers.asm
    include \masm32\macros\ucmacros.asm
;==============================================================================
    .data
      WSTR ws, "MY OTHER BROTHER DARRYL"
    .code
;==============================================================================
start:
;==============================================================================

    invoke crt_printf, cfm$("%S\n"), ADDR ws
    invoke crt__wcslwr, ADDR ws
    invoke crt_printf, cfm$("%S\n\n"), ADDR ws

    invoke Sleep, 4000

    REPEAT 10

      counter_begin 1000, HIGH_PRIORITY_CLASS
        invoke crt__wcslwr, ADDR ws
      counter_end
      print str$(eax),13,10

    ENDM

    print chr$(13,10)

    inkey "Press any key to exit..."
    exit

;==============================================================================
end start


Typical results running on a P3:

Code Select Expand


279
278
278
278
278
278
278
278
278
278


[KeepingRealBusy]

Well, I cleaned up that little problem (starting with 0), but the huge count remains. I'm still looking.

Michael,

I will add this delay and see what happens, but I don't think it will help. The other counts surrounding it are good.

I just ran into a little problem. The call to crt__wcslwr is a CDECL and I didn't adjust the stack upon return. Went off into the wild blue when I did a ret. I have seen other calls to ctr_xxx calls (in timing strcmp and others) that have the same failing. I think that the only reason that they do not disaster is that that exit is called from within the timing loop so the bad stack is ignored.

Dave.

[jj2007]

Michael,
Given that it's Sunday: Could you please reveal to all of us whether you really have a brother named Darryl?
:bg

[MichaelW]

I don't even have one brother named Darryl, much less two. The string is from an often-repeated phrase by one of the characters in the series Newhart, specifically William Sanderson's character Larry. I think most people who were aware and living in North America at the time probably recognize the phrase, but apparently not people living elsewhere.

[KeepingRealBusy]

Man! What serendipity! Another famous quote was from "Pogo" the comics character "We has met the enemy, and he is us!" (see Wiki). The huge time for crt_wcslwr WAS caused by the missing stack adjustment. As soon as I added this correction, the time corrected to something more reasonable, 78 clocks. Apparently, the stack got near overflow and the system grew it larger, but took up a huge amount of time, at least that is my guess.

I will go back to the other topics (strcmp and strchr) and add this correction where needed (any calls to system crt_ functions that are CDECL) to see what effect this has on timings.

Dave.