Execution speed slow initially, then speeds up

This is a discussion on Execution speed slow initially, then speeds up within the Windows Programming forums, part of the Platform Specific Boards category; What compiler/linker arguments are you using? I haven't used pelles before but I assume it has something similar to the ...

  1. #16
    Registered User
    Join Date
    Jan 2010
    Posts
    412
    What compiler/linker arguments are you using? I haven't used pelles before but I assume it has something similar to the debug/release modes in visual studio.

    My results, with VS2010 default settings, were
    Release build: both loops always takes 600-700ms.
    Debug build: on most attempts both loops takes 1100-1200ms to execute, but rarely the first loop takes ~3900ms and then the following ones takes ~1100ms again.

    I'm not entirely sure, but I think it has something to do with speedstep as I can see the cpu frequency changing in cpu-z. Although why it only affects debug and not release I have no answer for. Perhaps the extra buffer security checks in debug mode does something weird.

  2. #17
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by _Mike View Post
    What compiler/linker arguments are you using? I haven't used pelles before but I assume it has something similar to the debug/release modes in visual studio.
    No it doesn't... You have to set debug information into the compiler and linker separately either in the project dialog or by command line flags.

    However, if you join the forums there is an addin you can dowload that does mimic that kind of behaviour... it puts 3 extra buttons on the project tree for REL DBG and PRF builds.

  3. #18
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by megafiddle View Post
    Thanks for testing it.

    I consistantly get about 4203 mSec for the 1st and 2047 mSec for all those after.
    In Pelles C there is a feature for delayed loading of certain DLLs and windows code loads lots of them. This loading activity may be slowing your first pass through the loop... Lookin in your linker settings and make sure to remove dealyimp.lib and keep the "DLLs with delayed loading" bar completely empty... It might also help to set the compiler optimizations for "Optimize for speed" not "Optimize for speed (more)" and set floating point to "fast" instead of "precise"...


    If I remove the 1st call to the loop from WinMain, and only call it in response to a key,
    it runs at 2047 mSec right from the very 1st call.
    This could well be because the message dispatcher isn't running yet... The startup phases of windows can be a bit sluggish until it can get rid of that initial flood of messages... It might be better to move the first call to the WM_CREATE message that is pitched as soon as the dispatcher starts up...

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by CommonTater View Post
    In Pelles C there is a feature for delayed loading of certain DLLs and windows code loads lots of them. This loading activity may be slowing your first pass through the loop... Lookin in your linker settings and make sure to remove dealyimp.lib and keep the "DLLs with delayed loading" bar completely empty... It might also help to set the compiler optimizations for "Optimize for speed" not "Optimize for speed (more)" and set floating point to "fast" instead of "precise"...




    This could well be because the message dispatcher isn't running yet... The startup phases of windows can be a bit sluggish until it can get rid of that initial flood of messages... It might be better to move the first call to the WM_CREATE message that is pitched as soon as the dispatcher starts up...
    The code which is being timed is pure computation, with no function calls at all. I don't see how it could be affected by either of those issues. Unless the initial call to GetTickCount() is delay-loading a DLL and the counter is somehow including that delay. To rule that out, make a call to GetTickCount() first thing in main() to get the delay-load out of the way.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #20
    Registered User
    Join Date
    Mar 2011
    Posts
    406
    I tried a couple things. Adding a few extra calls to GetTickCount() before the loop, made
    no difference. Also adding SetPixel(hdc, x, y, spectrum[i]) inside the loop allows me to
    watch the progress, and its noticeably slower visually also (6015 vs 3859 indicated time).
    So it seems it is distributed throughout the loop, and not a single 2 second delay.
    I'll move the first call to the WM_CREATE message as suggested. WinMain isn't really the
    best place to call it from anyway.

    I was mainly concerned that I had a bug somewhere, but it looks like there's no problem
    in the code.

  6. #21
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    How about branch prediction, could that make such a big difference?

  7. #22
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Also adding SetPixel(hdc, x, y, spectrum[i]) inside the loop allows me to
    watch the progress, and its noticeably slower visually also (6015 vs 3859 indicated time).
    That is expected. GDI is extremely slow by graphics standards. It is made to be robust which is not always fast.

  8. #23
    Registered User
    Join Date
    Mar 2011
    Posts
    406
    Quote Originally Posted by VirtualAce View Post
    That is expected. GDI is extremely slow by graphics standards. It is made to be robust which is not always fast.
    I don't mean that it was just slower with the SetPixel() calls, which it was.

    I meant that the difference between the first call from within WinMain, and the subsequent calls,
    was still there with the SetPixel() calls. Adding the SetPixel() allows a visual indication of the loop
    progress, as it is called within the innermost loop. It's just an independant alternative to the timer.


    Quote Originally Posted by KIBO View Post
    How about branch prediction, could that make such a big difference?
    Do you mean the execution of the if statements? It should be the same in all cases.
    Or something else?

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Execution speed test in c++
    By nick2price in forum C++ Programming
    Replies: 1
    Last Post: 03-12-2009, 04:23 PM
  2. upload / download speeds
    By Dino in forum Tech Board
    Replies: 20
    Last Post: 11-25-2008, 08:06 PM
  3. Speed of pointers vs. speed of arrays/structs
    By Kempelen in forum C Programming
    Replies: 32
    Last Post: 06-27-2008, 10:16 AM
  4. Unbelievable wind speeds
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 12
    Last Post: 09-09-2004, 03:42 PM
  5. Questions on Speed of Execution
    By wavering in forum C Programming
    Replies: 22
    Last Post: 01-20-2002, 01:04 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21