I am attempting to save a file every second within +- 100ms (10% error). The problem I am having is that my timing measurement is saying that execution took 1150 ms, but in reality it appears to be 3 or 4 seconds.
What's going on?
If I issue the command, sleep(1), it appears to be very accurate. However, when I measure how long something took, it must be off by quite a bit.
I am using clock() to measure program execution. All of this stuff is within a while loop.
Walter
Your problem is that clock() reports you CPU time used by your process and it is usually different from the "real" time used.
For example following code:
#include <time.h>
#include <iostream>
#include <unistd.h>
using namespace std;
int main()
{
clock_t scl = clock();
sleep(1);
cout << "CPU clock time " << clock()-scl << endl;
}
gives
time ./a.out
CPU clock time 0
real 0m1.005s
user 0m0.000s
sys 0m0.004s
Related
I use g++ 12.2.0 (MinGW-w64 via MSYS2) and experience odd performance behavior when running the same code from VSCode (with Code Runner extension) and from the command line. For both, the command used is g++ f1.cpp -o f1 && f1.
For example purposes, given this code:
#include <iostream>
#include <chrono>
#include <string.h>
using
std::chrono::high_resolution_clock,
std::chrono::duration_cast,
std::chrono::nanoseconds;
void timeit(void (*func)(std::string), std::string message){
auto time_start = high_resolution_clock::now();
func(message);
auto time_end = high_resolution_clock::now();
auto duration = duration_cast<nanoseconds>(time_end - time_start).count();
std::cout << "Execution Time: " << duration * 1e-6f << " [ms]" << std::endl;
}
void run(std::string message){
std::cout << message.c_str() << std::endl;
}
int main() {
for (size_t i = 0; i < 100; i++)
timeit(&run, std::to_string(i));
}
VSCode Output:
...
96
Execution Time: 0.0025 [ms]
97
Execution Time: 0.0022 [ms]
98
Execution Time: 0.0034 [ms]
99
Execution Time: 0.0029 [ms]
Command Line Output:
...
96
Execution Time: 0.5091 [ms]
97
Execution Time: 0.5168 [ms]
98
Execution Time: 2.4943 [ms]
99
Execution Time: 0.7385 [ms]
The performance is significantly different as seen above.
It is also consistent on PowerShell and even the VSCode terminal itself.
I searched Stack Overflow and other sources for the best of my capability and yet left clueless.
Edit 1: I already tried running it with optimizations and up to 1e6 iterations and the issue still persists.
Edit 2: teapot418's answer was precise. It really was limited by the performance of the terminal and replacing std::endl with \n made a big difference in performance. Replacing the print operation with a different (and even more computationally heavy) operation showed equal performance. Colonel Thirty Two's answer raised an important point too which I should have clarified beforehand. Issue solved.
You are benchmarking the time of your run function, which is a single std::cout statement. Measuring I/O times of a single output line is going to have a lot of variance and depend on where stdout is getting routed to.
My psychic powers suggest that VSCode is re-routing stdout to its own output window which has a lot more buffering and performance than the default console window. And I'm guessing your console window is running under some sort of bash/unix emulation on Windows. (Or is this Linux?)
Some things to try:
You can try increasing the buffer size of the Windows console (or the console app you are using to host mingw)
Redirect to /dev/null or nul: on Windows. (e.g. f1 > /dev/null or f1 > nul:). Of course, you won't see the output, but you could change your Execution Time statement to be sent to cerr while cout is still used in the run function. But then again, I'm not sure what you are measuring.
Try compiling with -O2 optimizations. That might nullify the difference.
Try running your compiled program in a default console window instead of the Bash/Mingw/Cygin thing it might be running in now. You could try running it in powershell too.
Currently I am coding a project that requires precise delay times over a number of computers. Currently this is the code I am using I found it on a forum. This is the code below.
{
LONGLONG timerResolution;
LONGLONG wantedTime;
LONGLONG currentTime;
QueryPerformanceFrequency((LARGE_INTEGER*)&timerResolution);
timerResolution /= 1000;
QueryPerformanceCounter((LARGE_INTEGER*)¤tTime);
wantedTime = currentTime / timerResolution + ms;
currentTime = 0;
while (currentTime < wantedTime)
{
QueryPerformanceCounter((LARGE_INTEGER*)¤tTime);
currentTime /= timerResolution;
}
}
Basically the issue I am having is this uses alot of CPU around 16-20% when I start to call on the function. The usual Sleep(); uses Zero CPU but it is extremely inaccurate from what I have read from multiple forums is that's the trade-off when you trade accuracy for CPU usage but I thought I better raise the question before I set for this sleep method.
The reason why it's using 15-20% CPU is likely because it's using 100% on one core as there is nothing in this to slow it down.
In general, this is a "hard" problem to solve as PCs (more specifically, the OSes running on those PCs) are in general not made for running real time applications. If that is absolutely desirable, you should look into real time kernels and OSes.
For this reason, the guarantee that is usually made around sleep times is that the system will sleep for atleast the specified amount of time.
If you are running Linux you could try using the nanosleep method (http://man7.org/linux/man-pages/man2/nanosleep.2.html) Though I don't have any experience with it.
Alternatively you could go with a hybrid approach where you use sleeps for long delays, but switch to polling when it's almost time:
#include <thread>
#include <chrono>
using namespace std::chrono_literals;
...
wantedtime = currentTime / timerResolution + ms;
currentTime = 0;
while(currentTime < wantedTime)
{
QueryPerformanceCounter((LARGE_INTEGER*)¤tTime);
currentTime /= timerResolution;
if(currentTime-wantedTime > 100) // if waiting for more than 100 ms
{
//Sleep for value significantly lower than the 100 ms, to ensure that we don't "oversleep"
std::this_thread::sleep_for(50ms);
}
}
Now this is a bit race condition prone, as it assumes that the OS will hand back control of the program within 50ms after the sleep_for is done. To further combat this you could turn it down (to say, sleep 1ms).
You can set the Windows timer resolution to minimum (usually 1 ms), to make Sleep() accurate up to 1 ms. By default it would be accurate up to about 15 ms. Sleep() documentation.
Note that your execution can be delayed if other programs are consuming CPU time, but this could also happen if you were waiting with a timer.
#include <timeapi.h>
// Sleep() takes 15 ms (or whatever the default is)
Sleep(1);
TIMECAPS caps_;
timeGetDevCaps(&caps_, sizeof(caps_));
timeBeginPeriod(caps_.wPeriodMin);
// Sleep() now takes 1 ms
Sleep(1);
timeEndPeriod(caps_.wPeriodMin);
#include <iostream>
#include <ctime>
using namespace std;
int main()
{
clock_t t;
t = clock();
for(int i=0;i<1000000;i++)
;
t=clock()-t;
cout<<(float)t/CLOCKS_PER_SEC<<endl;
return 0;
}
I wrote a sample c++ program to measure the running time. Every time I run this code I get a different output. How is this happening? Shouldn't the time required by this program be same every time I run it.
I think that your running time you had is true. In the multitasking operating system, we have multi thread, so when your program running, maybe other program request CPU and your program to be comming delay for it.
You should read:
Easily measure elapsed time
If you are curious about the game timer program. You can use the game loop.
follows this:
How to make timer for a game loop?
On this sample code:
#include <iostream>
using namespace std;
int main()
{
cout<<"Hello World!"<<endl;
return 0;
}
I ran the following command 3 times:
perf stat -e cpu-cycles ./sample
Following are the 3 outputs on consecutive executions:
1)
Hello World!
Performance counter stats for './try':
22,71,970 cpu-cycles
0.003634105 seconds time elapsed
2)
Hello World!
Performance counter stats for './try':
18,51,044 cpu-cycles
0.001045616 seconds time elapsed
3)
Hello World!
Performance counter stats for './try':
18,21,834 cpu-cycles
0.001153489 seconds time elapsed
Why would the same program take different number of cpu-cycles on multiple runs?
I am using "Intel(R) Core(TM) i5-5250U CPU # 1.60GHz", "Ubuntu 14.04.3 LTS" and "g++ 4.8.4".
During start-up of the program the binary code is memory-mapped but loaded lazily (as needed). Hence, during the first invocation of the program some CPU cycles are spent by the kernel on (transparently) loading the binary code as execution hits instruction pages that are not yet in the RAM. Subsequent invocations take less time since they reuse the cached code, unless the underlying file has changed or the program hasn't been executed for a long time and its pages were recycled.
Normally in an IDE, when you run a program the IDE will tell you the total amount of time that it took to run the program. Is there a way to get the total amount of time that it takes to run a program when using the terminal in Unix/Linux to compile and run?
I'm aware of ctime which allows for getting the total time since 1970, however I want to get just the time that it takes for the program to run.
You can start programs with time:
[:~/tmp] $ time sleep 1
real 0m1.007s
user 0m0.001s
sys 0m0.003s
You are on the right track! You can get the current time and subtract it from the end time of your program. The code below illustrated:
time_t begin = time(0); // get current time
// Do Stuff //
time_t end = time(0); // get current time
// Show number of seconds that have passed since program began //
std::cout << end - begin << std::endl;
NOTE: The time granularity is only a single second. If you need higher granularity, I suggest looking into precision timers such as QueryPerformanceCounter() on windows or clock_gettime() on linux. In both cases, the code will likely work very similarly.
As an addendum to mdsl's answer, if you want to get something close to that measurement in the program itself, you can get the time at the start of the program and get the time at the end of the program (as you said, in time since 1970) - then subtract the start time from the end time.