Информация об изменениях

Сообщение Примечание к тестам производительности от 12.03.2017 8:47

Изменено 12.03.2017 8:52 AlexGin

Примечание к тестам производительности
В этой теме я приводил ссылки на мои тесты производительности, выложенные на гит-хабе:
https://github.com/AlexGin/Math.git

Некоторые наши коллеги заметили, что если в приведенном ниже тесте:
Блокировать / комментировать участок работы с GUI, начинаются жуткие тормоза:
void MainWindow::nativeComputeTrg() // Trigonometry
{
   ui->labelMode->setText("Trigonometry - start of perform...");

   ui->progressBar->setValue(2); // start position of progress-bar

   std::time_t timeStart = std::time(0);
   double resultDbl = 0.0;    
   for(int i = 2; i < N_MULTIPLY; i++)
   {
      for( int j = 0; j < N_GENERATED; j++ )
      {
         double dbMult = (double)(i * 2 * M_PI);
         resultDbl = randDbl[j] + sin(dbMult);
         resultDbl += 0.375;
         outpDbl[j] = resultDbl;
      }
// Если блокировать (комментировать) данный участок - в тригонометрическом тесте видим жуткие тормоза:
      // if (!(i % 100000))
      // {
      //    int val = ui->progressBar->value();
      //    ui->progressBar->setValue(++val);
      //}     
   }
   std::time_t timeStop = std::time(0);
   ui->labelMode->setText("Trigonometry - complete!");

   std::string strMode("Trigonometry");
   ShowDuration(timeStart, timeStop, strMode);
   ui->pushBtnStart->setEnabled(false);
}


Смею заверить товарищей, тормозов не будет — всё будет работать великолепно — если вместо работы с GUI поставить прокачку сообщений OS Windows:
      MSG msg;
      while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {    /* Loop of message-processing: */
          ::DispatchMessage(&msg);
      }


Вариант — для применения вместе с Qt:
    if (!(i % 100000))
       QCoreApplication::processEvents();


ПРИМЕЧАНИЕ:
В Production версии я бы всё это вынес в рабочий поток, но для тестовых целей — можно сделать всё это более простым способом

ПОЯСНЕНИЕ:
Любой "оконный" вывод в современных графических операционных системах связан с обменом сообщениями операционной системы.
Без них не отработает ничего(ни вывод std::cout на консоль, ни обновление прогресс бара).
В данном случае, этот вывод (за счёт прокачки сообщений реализованной в недрах OS Windows) просто обеспечивал "сторонний эффект".
Только вот тут редкий случай, когда данный "сторонний эффект" действует положительно, а не отрицательно
Когда я явно сделал ту же прокачку — всё вернулось на свои места.


Итак, соотношение времен выполнения (в пользу MSVC) восстановлено — легким движением руки

P.S. Все замечания насчёт опций компиляции я принимаю адекватно, однако лично мне очевидно, что при любой раскладке MSVC окажется эффективнее.
Здесь нет даже "секрета Полишинеля" — есть простой и очевидный факт.
Ну а попытки "притянуть за уши" результат некоторыми товарищами, просто свидетельствуют об их субъективной оценке данного эксперимента.

P.P.S. Прошу понять меня правильно так как я никого не желаю обидеть! Иногда у хороших специалистов просто замыленный взгляд.
Примечание к тестам производительности
В этой теме я приводил ссылки на мои тесты производительности, выложенные на гит-хабе:
https://github.com/AlexGin/Math.git

Некоторые наши коллеги заметили, что если в приведенном ниже тесте:
Блокировать / комментировать участок работы с GUI, начинаются жуткие тормоза:
void MainWindow::nativeComputeTrg() // Trigonometry
{
   ui->labelMode->setText("Trigonometry - start of perform...");

   ui->progressBar->setValue(2); // start position of progress-bar

   std::time_t timeStart = std::time(0);
   double resultDbl = 0.0;    
   for(int i = 2; i < N_MULTIPLY; i++)
   {
      for( int j = 0; j < N_GENERATED; j++ )
      {
         double dbMult = (double)(i * 2 * M_PI);
         resultDbl = randDbl[j] + sin(dbMult);
         resultDbl += 0.375;
         outpDbl[j] = resultDbl;
      }
// Если блокировать (комментировать) данный участок - в тригонометрическом тесте видим жуткие тормоза:
      // if (!(i % 100000))
      // {
      //    int val = ui->progressBar->value();
      //    ui->progressBar->setValue(++val);
      //}     
   }
   std::time_t timeStop = std::time(0);
   ui->labelMode->setText("Trigonometry - complete!");

   std::string strMode("Trigonometry");
   ShowDuration(timeStart, timeStop, strMode);
   ui->pushBtnStart->setEnabled(false);
}


Смею заверить товарищей, тормозов не будет — всё будет работать великолепно — если вместо работы с GUI поставить прокачку сообщений OS Windows:
      MSG msg;
      while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {    /* Loop of message-processing: */
          ::DispatchMessage(&msg);
      }


// Вариант — для применения вместе с Qt:
    if (!(i % 100000))
       QCoreApplication::processEvents();


ПРИМЕЧАНИЕ:
В Production версии я бы всё это вынес в рабочий поток, но для тестовых целей — можно сделать всё это более простым способом

ПОЯСНЕНИЕ:
Любой "оконный" вывод в современных графических операционных системах связан с обменом сообщениями операционной системы.
Без них не отработает ничего(ни вывод std::cout на консоль, ни обновление прогресс бара).
В данном случае, этот вывод (за счёт прокачки сообщений реализованной в недрах OS Windows) просто обеспечивал "сторонний эффект".
Только вот тут редкий случай, когда данный "сторонний эффект" действует положительно, а не отрицательно
Когда я явно сделал ту же прокачку — всё вернулось на свои места.


Итак, соотношение времен выполнения (в пользу MSVC) восстановлено — легким движением руки

P.S. Все замечания насчёт опций компиляции я принимаю адекватно, однако лично мне очевидно, что при любой раскладке MSVC окажется эффективнее.
Здесь нет даже "секрета Полишинеля" — есть простой и очевидный факт.
Ну а попытки "притянуть за уши" результат некоторыми товарищами, просто свидетельствуют об их субъективной оценке данного эксперимента.

P.P.S. Прошу понять меня правильно так как я никого не желаю обидеть! Иногда у хороших специалистов просто замыленный взгляд.