How to calculate GFLOPs for a funtion in c++ program?

2.3k views Asked by At

I have a c++ code which calculates factorial of int data type, addition of float data type and execution time of each function as follows:

long Sample_C:: factorial(int n)
{
    int counter;
    long fact = 1;
    for (int counter = 1; counter <= n; counter++)
    {
        fact = fact * counter;
    }
    Sleep(100);
    return fact;
}

float Sample_C::add(float a, float b)
{

    return a+b;
}

int main(){
    Sample_C object;
    clock_t start = clock();
    object.factorial(6);
    clock_t end = clock();
    double time =(double)(end - start);// finding execution time of factorial()
    cout<< time;
    clock_t starts = clock();
    object.add(1.1,5.5);
    clock_t ends = clock();
    double total_time = (double)(ends -starts);// finding execution time of add()
    cout<< total_time;
    return 0;
}

Now , i want to have the mesure GFLOPs for "add " function. So, kindly suggest how will i caculate it. As, i am completly new to GFLOPs so kindly tell me wether we can have GFLOPs calculated for functions having only foat data types? and also GFLOPs value vary with different functions?

1

There are 1 answers

0
ilent2 On

If I was interested in estimating the execution time of the addition operation I might start with the following program. However, I would still only trust the number this program produced to within a factor of 10 to 100 at best (i.e. I don't really trust the output of this program).

#include <iostream>
#include <ctime>

int main (int argc, char** argv)
{
  // Declare these as volatile so the compiler (hopefully) doesn't
  // optimise them away.
  volatile float a = 1.0;
  volatile float b = 2.0;
  volatile float c;

  // Preform the calculation multiple times to account for a clock()
  // implementation that doesn't have a sufficient timing resolution to
  // measure the execution time of a single addition.
  const int iter = 1000;

  // Estimate the execution time of adding a and b and storing the
  // result in the variable c.
  // Depending on the compiler we might need to count this as 2 additions
  // if we count the loop variable.
  clock_t start = clock();
  for (unsigned i = 0; i < iter; ++i)
  {
    c = a + b;
  }
  clock_t end = clock();

  // Write the time for the user
  std::cout << (end - start) / ((double) CLOCKS_PER_SEC * iter)
      << " seconds" << std::endl;

  return 0;
}

If you knew how your particular architecture was executing this code you could then try and estimate FLOPS from the execution time but the estimate for FLOPS (on this type of operation) probably wouldn't be very accurate.

An improvement to this program might be to replace the for loop with a macro implementation or ensure your compiler expands for loops inline. Otherwise you may also be including the addition operation for the loop index in your measurement.

I think it is likely that the error wouldn't scale linearly with problem size. For example if the operation you were trying to time took 1e9 to 1e15 times longer you might be able to get a decent estimate for GFLOPS. But, unless you know exactly what your compiler and architecture are doing with your code I wouldn't feel confident trying to estimate GFLOPS in a high level language like C++, perhaps assembly might work better (just a hunch).

I'm not saying it can't be done, but for accurate estimates there are a lot of things you might need to consider.