3

I have a function which has a factor that needs to be adjusted according to the load on the machine to consume exactly the wall time passed to the function. The factor can vary according to the load of the machine.

void execute_for_wallTime(int factor, int wallTime) 
{
   double d = 0;
   for (int n = 0; n<factor; ++n)
      for (int m = 0; wall_time; ++m)
        d += d * n*m;
}

Is there a way to dynamically check the load on the machine and adjust the factor accordingly in order to consume the exact wall time passed to the function?

The wall time is read from the file and passed to this function. The values are in micro seconds, e.g:

73
21
44
Zeeshan Hayat
  • 401
  • 6
  • 13
  • 1
    Why do you think you need `volatile` there? –  May 19 '18 at 23:44
  • I guess you can't just nanosleep() for wallTime microseconds, but need to perform operations. You will then have to call the clock when the function starts and every iteration, check the difference and compare to walltime, then return when time is up. Is this what you are trying to do? – Attersson May 19 '18 at 23:48
  • @Attersson Yeah, exactly the same thing. I don´t want to use sleep, I want to perform the operation instead. – Zeeshan Hayat May 19 '18 at 23:52
  • @NeilButterworth I removed volatile. I am not sure why it was even there. – Zeeshan Hayat May 19 '18 at 23:53
  • Unless you are running this on an RTOS, then what you want isn't possible. –  May 19 '18 at 23:57

1 Answers1

3

According to OP comment:

#include <sys/time.h>

int deltaTime(struct timeval *tv1, struct timeval *tv2){
    return ((tv2->tv_sec - tv1->tv_sec)*1000000)+ tv2->tv_usec - tv1->tv_usec;
}
//might require longs anyway. this is time in microseconds between the 2 timevals

void execute_for_wallTime(int wallTime) 
{
    struct timeval  tvStart, tvNow;
    gettimeofday(&tvStart, NULL);

    double d = 0;
    for (int m = 0; wall_time; ++m){
      gettimeofday(&tvNow, NULL);
      if(deltaTime(tvStart,tvNow) >=wall_time) { // if timeWall is 1000 microseconds,
                                                 // this function returns after
                                                 // 1000 microseconds (and a
                                                 // little more due to overhead)
           return;
      }
      d += d*m;
   }
}

Now deal with timeWall by increasing or decreasing it in a logic outside this function depending on your performance calculations. This function simply runs for timeWall microseconds.

For C++ style, you can use std::chrono.

I must comment that I would handle things differently, for example by calling nanosleep(). The operations make no sense unless in actual code you plan to substitute these "fillers" with actual operations. In that case you might consider threads and schedulers. Besides the clock calls add overhead.

Attersson
  • 4,755
  • 1
  • 15
  • 29
  • Is there a way to completely get rid of the factor variable and to just pass the wall time to the function? The function tries to consume the wall time according to the passed value. – Zeeshan Hayat May 20 '18 at 00:08
  • @ZeeshanHayat Done. How about now? – Attersson May 20 '18 at 00:11
  • It seems to be working fine. Thanks. Actually, due to some requirements, I need to consume computation power for specific wall time. I am running multiple threads and each thread consumes some cpu power. – Zeeshan Hayat May 20 '18 at 01:07
  • You are welcome.I have worked with time functions for a long time and this is quite easy for me. Glad to help! – Attersson May 20 '18 at 01:08
  • this function works fine for a single thread program but it gives very different values in the multithreaded program. Any idea why? – Zeeshan Hayat Jun 08 '18 at 10:56
  • Yes of course. Since a thread quantum may vary, a content switch may happen at whatever point in the execution. For example the timestamp was just recorded but then a content switch occurred. Ages later, the thread resumes and this timestamp, now outdated, is used. For this reason, a single thread, possibly the main thread, should handle all the timing and expose timestamps for the current time to every thread. Threads will only record their start time and compare it to the global timeNow. It is never guaranteed when and for how long a thread executes but, jittering apart, it will work better. – Attersson Jun 08 '18 at 11:10
  • Another reason this may happen is concurrency, in case many threads seek to write to the same resource but assume times. Since serialization and therefore order is not guaranteed, you will have to handle ordering and concurrency. – Attersson Jun 08 '18 at 11:15