Оптимизация a "while(1);" в C++0x

для меня соответствующее оправдание:

это предназначено для разрешения преобразований компилятора, таких как удаление пустых циклов, даже если завершение не может быть доказано.

предположительно, это потому, что доказательство прекращения механическисложно, и невозможность доказать завершение затрудняет компиляторы, которые в противном случае могли бы сделать полезные преобразования, такие как перемещение независящих операций из цикла до цикла после или наоборот, выполнение операций после цикла в одном потоке, в то время как цикл выполняется в другом, и так далее. Без этих преобразований цикл может блокировать все другие потоки, пока они ждут, пока один поток завершит указанный цикл. (Я использую" поток " свободно, чтобы означать любую форму параллельной обработки, включая отдельные потоки команд VLIW.)

редактировать: тупой пример:

while (complicated_condition()) {
    x = complicated_but_externally_invisible_operation(x);
}
complex_io_operation();
cout << "Results:" << endl;
cout << x << endl;

здесь, это было бы быстрее для одного потока, чтобы сделать complex_io_operation в то время как другой делает все сложные вычисления в цикле. Но без предложения, которое вы процитировали, компилятор должен доказать две вещи, прежде чем он сможет выполнить оптимизацию: 1) that complex_io_operation() не зависит от результатов цикла, и 2) что цикл завершится. Доказательство 1) довольно легко, доказательство 2) является проблемой остановки. С предложением он может предположить, что цикл завершается и получает выигрыш от распараллеливания.

Я также предполагаю, что дизайнеры считали, что случаи, когда бесконечны циклы происходят в производственном коде очень редко и обычно являются такими вещами, как управляемые событиями циклы, которые каким-то образом обращаются к вводу-выводу. В результате они пессимизировали редкий случай (бесконечные петли) в пользу оптимизации более общего случая (неинфинированные, но трудно механически доказать неинфинированные петли).

это, однако, означает, что бесконечные циклы, используемые в обучающих примерах, будут страдать в результате и будут вызывать gotchas в начальном коде. Я не могу сказать, что это полностью хорошо вещь.

EDIT: что касается проницательной статьи, которую вы сейчас ссылаетесь, я бы сказал, что "компилятор может предположить X о программе" логически эквивалентно "если программа не удовлетворяет X, поведение не определено". Мы можем показать это следующим образом: предположим, что существует программа, которая не удовлетворяет свойству X. Где бы определялось поведение этой программы? Стандарт определяет поведение только при условии, что свойство X истинно. Хотя в стандарте это явно не указано объявите поведение неопределенным, оно объявило его неопределенным опущением.

рассмотрим аналогичный аргумент:" компилятор может предположить, что переменная x назначается только не более одного раза между точками последовательности "эквивалентно"назначение x более одного раза между точками последовательности не определено".

Я думаю, что правильная интерпретация-это одна из ваших правок: пустые бесконечные циклы-это неопределенное поведение.

Я бы не сказал, что это особенно интуитивное поведение, но эта интерпретация имеет больше смысла, чем альтернативная, что компилятору произвольно разрешено игнорировать бесконечные циклы без вызова UB.

если бесконечные циклы UB, это просто означает, что не завершающие программы не считаются значимыми: согласно C++0x, они есть нет семантики.

Это тоже имеет определенный смысл. Это особый случай, когда ряд побочных эффектов просто больше не возникает (например, ничего не возвращается из main), и ряд оптимизаций компилятора затрудняется необходимостью сохранения бесконечных циклов. Например, перемещение вычислений по циклу совершенно допустимо, если цикл не имеет побочных эффектов, потому что в конечном итоге вычисление будет выполнено в любом случае. Но если цикл никогда не завершается, мы не можем безопасно переставить код через него, потому что мы может просто измените, какие операции на самом деле выполняются до зависания программы. Если мы не рассматриваем висячую программу как UB, то есть.

Я думаю, что это по линии этого типа вопрос, который ссылается на другой thread. Оптимизация может иногда удалять пустые циклы.

соответствующая проблема заключается в том, что компилятору разрешено переупорядочивать код, побочные эффекты которого не конфликтуют. Неожиданный порядок выполнения может возникнуть даже в том случае, если компилятор выдаст нескончаемый машинный код для бесконечного цикла.

Я считаю, что это правильный подход. Спецификация языка определяет способы обеспечения порядка выполнения. Если вы хотите бесконечный цикл, который не может быть переупорядочен, напишите следующее:

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

Я думаю, что этот вопрос, возможно, лучше всего сформулировать так: "если более поздний фрагмент кода не зависит от более раннего фрагмента кода, и более ранний фрагмент кода не имеет побочных эффектов ни на какой другой части системы, выходные данные компилятора могут выполнять более поздний фрагмент кода до, после или смешанный с выполнением первого, даже если первый содержит циклы,без учета того, когда и будет ли фактически завершен предыдущий код. Например, компилятор может перепишите:

void testfermat(int n)
{
  int a=1,b=1,c=1;
  while(pow(a,n)+pow(b,n) != pow(c,n))
  {
    if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
  }
  printf("The result is ");
  printf("%d/%d/%d", a,b,c);
}

как

void testfermat(int n)
{
  if (fork_is_first_thread())
  {
    int a=1,b=1,c=1;
    while(pow(a,n)+pow(b,n) != pow(c,n))
    {
      if (b > a) a++; else if (c > b) {a=1; b++}; else {a=1; b=1; c++};
    }
    signal_other_thread_and_die();
  }
  else // Second thread
  {
    printf("The result is ");
    wait_for_other_thread();
  }
  printf("%d/%d/%d", a,b,c);
}

как правило, неразумно, хотя я мог бы беспокоиться, что:

  int total=0;
  for (i=0; num_reps > i; i++)
  {
    update_progress_bar(i);
    total+=do_something_slow_with_no_side_effects(i);
  }
  show_result(total);

станет

  int total=0;
  if (fork_is_first_thread())
  {
    for (i=0; num_reps > i; i++)
      total+=do_something_slow_with_no_side_effects(i);
    signal_other_thread_and_die();
  }
  else
  {
    for (i=0; num_reps > i; i++)
      update_progress_bar(i);
    wait_for_other_thread();
  }
  show_result(total);

имея один процессор обрабатывать вычисления, а другой обрабатывать обновления индикатора выполнения, переписать будет повысить эффективность. К сожалению, это сделало бы обновления индикатора выполнения менее полезными, чем они должны быть.

Это не разрешимо для компилятора для нетривиальных случаев, если это вообще бесконечный цикл.

в разных случаях может случиться так, что ваш оптимизатор достигнет лучшего класса сложности для вашего кода (например, это было O(n^2), и вы получите O(n) или O(1) после оптимизации).

таким образом, включение такого правила, которое запрещает удаление бесконечного цикла в стандарт C++, сделало бы невозможным многие оптимизации. И большинство людей этого не хотят. Я думаю, что это довольно ответить ваш вопрос.

---

другое дело: я никогда не видел ни одного действительного примера, где вам нужен бесконечный цикл, который ничего не делает.

один пример, о котором я слышал, был уродливым взломом, который действительно должен быть решен иначе: речь шла о встроенных системах, где единственным способом вызвать Сброс было заморозить устройство, чтобы сторожевой пес перезапустил его автоматически.

Если вы знаете какой-либо действительный / хороший пример, где вам нужен бесконечный цикл, который делает ничего, пожалуйста, скажи мне.

Я думаю, стоит отметить, что циклы, которые были бы бесконечными, за исключением того, что они взаимодействуют с другими потоками через энергонезависимые, несинхронизированные переменные, теперь могут привести к неправильному поведению с новым компилятором.

другими словами, сделайте ваши глобалы изменчивыми - а также аргументы, переданные в такой цикл через указатель / ссылку.