Оптимізація відключення "в той час (1);" в C ++ 0x

Оновлено, дивіться нижче!

Я чув і читав, що C ++ 0x дозволяє компілятору надрукувати "Привіт" для наступного фрагмента

#include <iostream>

int main() {
  while(1) 
    ;
  std::cout << "Hello" << std::endl;
}

Це, мабуть, має щось спільне з потоками та можливостями оптимізації. Мені здається, що це може здивувати багатьох людей.

Хтось має добре пояснення, чому це потрібно було дозволити? Для довідки, останній C ++ 0x чернетка говорить на6.5/5

Цикл, який за межами for-init-заяви у випадку заяви для заяви,

• не здійснює дзвінків до функцій вводу / виводу бібліотеки та
• не отримує доступу та не змінює летючі об'єкти;
• не виконує жодних операцій синхронізації (1.10) або атомних операцій (п. 29)

може припускати, що реалізація припиняється. [Примітка: Це призначено для того, щоб дозволити трансформації компілятора, такі як видалення порожніх циклів, навіть коли припинення неможливо довести. - кінцева примітка]

Редагувати:

Ця прониклива стаття говорить про цей текст Стандартів

На жаль, слова "невизначена поведінка" не вживаються. Однак у будь-який час, коли стандарт каже, що "компілятор може вважати P", мається на увазі, що програма, яка має властивість not-P, має невизначену семантику.

Це правильно, і чи дозволяється компілятору надрукувати "Bye" для вищевказаної програми?

Тут є ще більш проникливий потік , який стосується аналогічної зміни на C, розпочатої хлопцем, виконаною вище зв'язаною статтею. Серед інших корисних фактів вони представляють рішення, яке, здається, також стосується C ++ 0x ( оновлення : з n3225 це більше не працюватиме - див. Нижче!)

endless:
  goto endless;

Здається, компілятору не дозволяється оптимізувати це, бо це не цикл, а стрибок. Інший хлопець підсумовує запропоновані зміни у C ++ 0x та C201X

Записуючи цикл, програміст запевняє або про те, що цикл робить щось із видимою поведінкою (виконує введення-виведення, доступ до летючих об'єктів або виконує синхронізацію чи атомні операції), або що він врешті-решт припиняється. Якщо я порушую це припущення, написавши нескінченний цикл без побічних ефектів, я брешу на компілятор, і поведінка моєї програми не визначена. (Якщо мені пощастить, компілятор може попередити мене про це.) Мова не забезпечує (більше не надає?) Спосіб виразити нескінченний цикл без видимої поведінки.

Оновлення 3.1.2011 з n3225: Комітет перемістив текст до 1.10 / 24 і сказав

Реалізація може припускати, що з часом будь-який потік виконує одне з наступних дій:

• припинити,
• здійснити дзвінок у функцію вводу / виводу бібліотеки,
• отримати доступ або змінити летючий об'єкт, або
• виконати операцію синхронізації або атомну операцію.

gotoТрюк буде НЕ працювати більше!

Хтось має добре пояснення, чому це потрібно було дозволити?

Так, Ганс Бом надає обґрунтування цього в N1528: Чому невизначена поведінка для нескінченних циклів? , хоча це документ WG14, обгрунтування стосується і C ++, і документ стосується як WG14, так і WG21:

Як правильно зазначає N1509, поточна чернетка по суті надає невизначеної поведінки нескінченним циклам в 6.8.5p6. Основна проблема для цього полягає в тому, що він дозволяє коду переміщатися через потенційно не закінчується цикл. Наприклад, припустимо, що у нас є такі петлі, де count і count2 - глобальні змінні (або їх адреса взята), а p - локальна змінна, адреса якої не взята:

for (p = q; p != 0; p = p -> next) {
    ++count;
}
for (p = q; p != 0; p = p -> next) {
    ++count2;
}

Чи можна об'єднати ці дві петлі та замінити їх наступними циклами?

for (p = q; p != 0; p = p -> next) {
        ++count;
        ++count2;
}

Без спеціального розподілу в 6.8.5p6 для нескінченних циклів це буде заборонено: Якщо перша петля не закінчується, оскільки q вказує на круговий список, оригінал ніколи не пише в count2. Таким чином, він може бути запущений паралельно з іншим потоком, який отримує доступ або оновлює count2. Це вже не є безпечним для перетвореної версії, яка робить доступ до count2, незважаючи на нескінченний цикл. Таким чином, перетворення потенційно вводить перегони даних.

У таких випадках малоймовірно, що компілятор зможе довести припинення циклу; слід було б зрозуміти, що q вказує на ациклічний список, який, на мою думку, виходить за межі можливостей більшості компіляторів, що часто використовується, і часто неможливий без інформації про всю програму.

Обмеження, накладені циклами, що не закінчуються, є обмеженням на оптимізацію кінцевих циклів, для яких компілятор не може довести припинення, а також на оптимізацію фактично не закінчених циклів. Перші набагато частіше зустрічаються, ніж останні, і часто цікавіше оптимізувати.

Очевидно також, що для-циклів із цілою змінною циклу, в яких компілятору буде складно довести припинення, і, таким чином, компілятору буде важко реструктурувати петлі без 6.8.5p6. Навіть щось подібне

for (i = 1; i != 15; i += 2)

або

for (i = 1; i <= 10; i += j)

здається нетривіальним впоратися. (У першому випадку для підтвердження закінчення потрібна деяка основна теорія чисел, в другому випадку нам потрібно знати щось про можливі значення j, щоб це зробити. Обгортання непідписаних цілих чисел може ускладнити дещо з цих міркувань далі. )

Це питання, схоже, стосується майже всіх перетворень циклу реструктуризації, включаючи паралелізацію компілятора та оптимізацію кеш-пам'яті, обидві вони, ймовірно, набувають значущості і вже часто важливі для числового коду. Це, мабуть, обернеться значною вартістю на користь того, що ми можемо писати нескінченні цикли найбільш природним способом, тим більше, що більшість з нас рідко пише навмисно нескінченні цикли.

Основна відмінність C - це те, що C11 забезпечує виняток для керування виразами, які є постійними виразами, що відрізняється від C ++ і робить ваш конкретний приклад добре визначеним у C11.

Для мене відповідним обґрунтуванням є:

Це покликане дозволити трансформації компілятора, такі як видалення порожніх циклів, навіть коли припинення неможливо довести.

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

EDIT: Німий приклад:

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

Тут було б швидше зробити один потік, complex_io_operationа інший виконує всі складні обчислення в циклі. Але без наведеного вами застереження компілятор повинен довести дві речі, перш ніж він зможе зробити оптимізацію: 1) що complex_io_operation()не залежить від результатів циклу, і 2), що цикл закінчиться . Довести 1) досить просто, довести 2) - проблема зупинки. За допомогою пункту може бути припущено, що цикл закінчується та отримує виграш паралелізації.

Я також уявляю, що дизайнери вважали, що випадки, коли у виробничому коді трапляються нескінченні цикли, є дуже рідкісними, і це зазвичай такі речі, як керовані подіями петлі, які певним чином отримують доступ до вводу / виводу. Як результат, вони песимізували рідкісний випадок (нескінченні петлі) на користь оптимізації більш поширеного випадку (нескінченного, але важко механічно довести нескінченні, петлі).

Це, однак, означає, що в результаті страждають нескінченні цикли, які використовуються у прикладах навчання, і піднімуть gotchas у коді для початківців. Я не можу сказати, що це абсолютно гарна річ.

EDIT: Стосовно проникливої ​​статті, яку ви зараз посилаєте, я б сказав, що "компілятор може вважати X про програму" логічно еквівалентний "якщо програма не задовольняє X, поведінка не визначена". Ми можемо показати це так: припустимо, існує програма, яка не задовольняє властивості X. Де було б визначено поведінку цієї програми? Стандарт визначає лише поведінку, припускаючи, що властивість X є істинною. Хоча Стандарт прямо не оголошує поведінку невизначеною, він оголосив її невизначеною упущенням.

Розглянемо аналогічний аргумент: "компілятор може припустити, що змінна x призначається тільки максимум один раз між точками послідовності", що еквівалентно "присвоєнню x більше одного разу між точками послідовності не визначено".

Я думаю, що правильне тлумачення - це те, що ви редагували: порожні нескінченні петлі - це не визначена поведінка.

Я б не сказав, що це особливо інтуїтивна поведінка, але ця інтерпретація має більше сенсу, ніж альтернативна, що компілятору дозволено ігнорувати нескінченні цикли, не викликаючи UB.

Якщо нескінченними циклами є UB, це просто означає, що незакінчені програми не вважаються значущими: згідно з C ++ 0x, вони не мають семантики.

Це теж має певний сенс. Це особливий випадок, коли низка побічних ефектів просто більше не виникає (наприклад, з них нічого не повертається main), а ряд оптимізацій компілятора перешкоджає необхідності збереження нескінченних циклів. Наприклад, переміщення обчислень по циклу цілком справедливо, якщо цикл не має побічних ефектів, оскільки, зрештою, обчислення будуть виконані в будь-якому випадку. Але якщо цикл ніколи не завершиться, ми не можемо спокійно переставити код через нього, тому що ми могли б бути просто зміни , які операції на насправді отримати виконується до програми зависань. Якщо ми не ставимося до програми, що висить, як UB, тобто.

Я думаю, що це узгоджується з питаннями такого типу , в яких йдеться про іншу тему . Оптимізація може періодично видаляти порожні петлі.

Відповідне питання полягає в тому, що компілятору дозволено переупорядковувати код, побічні ефекти якого не суперечать. Дивовижний порядок виконання може виникнути, навіть якщо компілятор створив машину без закінчення машинного коду для нескінченного циклу.

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

volatile int dummy_side_effect;

while (1) {
    dummy_side_effect = 0;
}

printf("Never prints.\n");

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

недійсний тестфермат (int n)
{
  int a = 1, b = 1, c = 1;
  while (pow (a, n) + pow (b, n)! = pow (c, n))
  {
    якщо (b> a) a ++; інакше, якщо (c> b) {a = 1; b ++}; інакше {a = 1; b = 1; c ++};
  }
  printf ("Результат є");
  printf ("% d /% d /% d", a, b, c);
}

як

недійсний тестфермат (int n)
{
  if (fork_is_first_thread ())
  {
    int a = 1, b = 1, c = 1;
    while (pow (a, n) + pow (b, n)! = pow (c, n))
    {
      якщо (b> a) a ++; інакше, якщо (c> b) {a = 1; b ++}; інакше {a = 1; b = 1; c ++};
    }
    signal_other_thread_and_die ();
  }
  else // Друга нитка
  {
    printf ("Результат є");
    wait_for_other_thread ();
  }
  printf ("% d /% d /% d", a, b, c);
}

Як правило, це не безпідставно, хоча я можу переживати, що:

  int total = 0;
  для (i = 0; num_reps> i; i ++)
  {
    update_progress_bar (i);
    total + = do_something_slow_with_no_side_effects (i);
  }
  show_result (всього);

став би

  int total = 0;
  if (fork_is_first_thread ())
  {
    для (i = 0; num_reps> i; i ++)
      total + = do_something_slow_with_no_side_effects (i);
    signal_other_thread_and_die ();
  }
  ще
  {
    для (i = 0; num_reps> i; i ++)
      update_progress_bar (i);
    wait_for_other_thread ();
  }
  show_result (всього);

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

Це не вирішується для компілятора для нетривіальних випадків, якщо він зовсім нескінченний цикл.

У різних випадках може статися, що ваш оптимізатор досягне кращого класу складності для вашого коду (наприклад, це був O (n ^ 2), і ви отримаєте O (n) або O (1) після оптимізації).

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

Інша річ: я ніколи не бачив жодного поважного прикладу, коли тобі потрібна нескінченна петля, яка нічого не робить.

Один із прикладів, про які я чув, - це некрасивий злом, який насправді слід вирішити інакше: мова йшла про вбудовані системи, де єдиним способом запустити скидання було заморозити пристрій, щоб сторожова собака перезапустила його автоматично.

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

Я думаю, що варто зазначити, що петлі, які були б нескінченними, за винятком того, що вони взаємодіють з іншими потоками за допомогою енергонезалежних, не синхронізованих змінних, тепер можуть спричинити неправильну поведінку з новим компілятором.

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