Thread: Execution speed slow initially, then speeds up

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.

Originally Posted by _Mike

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.

Originally Posted by megafiddle

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

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.

How about branch prediction, could that make such a big 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).

That is expected. GDI is extremely slow by graphics standards. It is made to be robust which is not always fast.

Originally Posted by VirtualAce

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.

Originally Posted by KIBO

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?