Що швидше: поки (1) або поки (2)?

Це було питання інтерв'ю, яке йому задав вищий менеджер.

Що швидше?

while(1) {
    // Some code
}

або

while(2) {
    //Some code
}

Я сказав, що обидва мають однакову швидкість виконання, оскільки вираз усередині whileповинен нарешті оцінити до trueабо false. У цьому випадку обидва оцінюють trueта не містять додаткових умовних інструкцій всередині whileумови. Отже, обидва матимуть однакову швидкість виконання, і я вважаю за краще (1).

Але інтерв'юер впевнено сказав: "Перевірте основи. while(1)Це швидше, ніж while(2)". (Він не перевіряв мою впевненість)

Це правда?

Дивіться також: Чи "for (;;)" швидше, ніж "while (TRUE)"? Якщо ні, то чому люди його використовують?

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

Використовуючи gcc, я склав дві наступні програми для збирання з різними рівнями оптимізації:

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

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

Для довідки, ось створена збірка (використовуючи gcc main.c -S -masm=intelпрапор оптимізації):

З -O0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

З -O1:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

З -O2і -O3(той же вихід):

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Насправді збірка, що генерується для циклу, однакова для кожного рівня оптимізації:

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Важливі біти:

.L2:
    jmp .L2

Я не можу читати складання дуже добре, але це, очевидно, безумовний цикл. jmpІнструкція беззастережно скидає програму назад на .L2етикетці, навіть НЕ порівнюючи значення проти істини, і, звичайно , відразу ж робить це знову , поки програма не буде якимось - то чином закінчилася. Це безпосередньо відповідає коду C / C ++:

L2:
    goto L2;

Редагувати:

Цікаво, що навіть без оптимізації , наступні цикли дають такий же вихід (безумовний jmp) у збірці:

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

І навіть на мій подив:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

Речі стають трохи цікавішими за допомогою визначених користувачем функцій:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

У -O0цих двох прикладах насправді виклик xта порівняння для кожної ітерації.

Перший приклад (повернення 1):

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Другий приклад (повернення sqrt(7)):

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Однак -O1вгорі і вище вони обидва виробляють таку ж збірку, що і попередні приклади (безумовне jmpповернення до попередньої мітки).

TL; DR

Під GCC різні петлі складаються на однакові збірки. Компілятор оцінює постійні значення і не заважає виконувати фактичне порівняння.

Мораль історії полягає в наступному:

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

Так, while(1)набагато швидше , ніж while(2), для людини , щоб читати! Якщо я бачу while(1)в незнайомій кодовій базі, я одразу знаю, що задумав автор, і мої очні яблука можуть перейти до наступного рядка.

Якщо я побачу while(2), я, мабуть, зупиняться на своїх слідах і спробую з’ясувати, чому автор не написав while(1). Чи палив авторський палець по клавіатурі? Чи користувачі цієї кодової бази використовують while(n)як незрозумілий механізм коментування, щоб петлі виглядали інакше? Це грубе вирішення несправжнього попередження в якомусь зламаному інструменті статичного аналізу? Або це підказка, що я читаю згенерований код? Це помилка внаслідок непродуманого пошуку і заміни всіх, або поганого злиття, або космічного променя? Можливо, цей рядок коду повинен зробити щось кардинально інше. Можливо, це слід було прочитати while(w)або while(x2). Я б краще знайти автора в історії файлу і надіслати їм електронний лист "WTF" ... і тепер я порушив свій ментальний контекст.while(2)while(1) зайняв би частку секунди!

Я перебільшую, але лише небагато. Читання коду дійсно важливо. І це варто згадати в інтерв'ю!

Існуючі відповіді, що показують код, сформований певним компілятором для певної цілі з певним набором опцій, не відповідають повністю на питання - якщо тільки запитання не було задано у конкретному контексті ("Що швидше використовувати gcc 4.7.2 для x86_64 з опціями за замовчуванням? ", наприклад).

Що стосується визначення мови, то в абстрактній машині while (1) оцінюється ціла константа 1та while (2)оцінюється ціла константа 2; в обох випадках результат порівнюється для рівності нулю. Мовний стандарт абсолютно нічого не говорить про відносну ефективність двох конструкцій.

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

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

int n = 4;
switch (n) {
    case 2+2: break;
    case 4:   break;
}

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

Стандарт C ( N1570 6.8.5p4) говорить про це

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

Отже, відповідні постійні вирази є 1 == 0і 2 == 0обидва оцінюють за intзначенням 0. (Ці порівняння неявні в семантиці whileциклу; вони не існують як фактичні вирази С.)

Збочно наївний компілятор може створити різний код для двох конструкцій. Наприклад, для першого він може створити безумовний нескінченний цикл (трактуючи 1як окремий випадок), а для другого він може створити явне порівняння часу виконання, еквівалентне 2 != 0. Але я ніколи не стикався з компілятором С, який би насправді так поводився, і я серйозно сумніваюся, що такий компілятор існує.

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

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

Підсумок: while (1)і while(2) майже напевно мають однакові показники. Вони мають однакову семантику, і немає жодної вагомої причини жоден компілятор не генерувати однаковий код.

І хоча це абсолютно законно для компілятора, щоб генерувати швидший код для, while(1)ніж для while(2), це однаково законно для компілятора, щоб генерувати швидший код для, while(1)ніж для іншого появи while(1)в тій же програмі.

(Існує ще одне запитання, яке мається на увазі в тому, що ви задали: Як ви маєте справу з інтерв'юером, який наполягає на неправильному технічному питанні. Це, мабуть, буде гарним питанням для сайту Workplace ).

Почекай хвилинку. Інтерв'юер, чи схожий він на цього хлопця?

Досить погано, що сам інтерв'юер провів це інтерв'ю, що робити, якщо інші програмісти цієї компанії "пройшли" цей тест?

Ні. Оцінка тверджень 1 == 0і 2 == 0 повинна бути однаково швидкою. Ми можемо уявити погані реалізації компілятора, де одна може бути швидшою, ніж інша. Але немає вагомих причин, чому один повинен бути швидшим, ніж інший.

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

Відмова: Це НЕ оригінальний мультфільм Ділберта. Це просто машу .

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

До речі, якщо ви відповіли

Обидва фрагменти коду однаково швидкі, тому що обидва займають нескінченний час для завершення

сказав би інтерв'юер

Але while (1)можна робити більше ітерацій за секунду; ви можете пояснити, чому? (це нісенітниця; ще раз перевірити свою впевненість)

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

Ось приклад коду, згенерованого компілятором у моїй системі (MS Visual Studio 2012), з оптимізаціями вимкнено:

yyy:
    xor eax, eax
    cmp eax, 1     (or 2, depending on your code)
    je xxx
    jmp yyy
xxx:
    ...

З увімкненими оптимізаціями:

xxx:
    jmp xxx

Тож згенерований код точно такий же, принаймні, з оптимізуючим компілятором.

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

1 = 00000001
2 = 00000010

Якщо "дорівнює нулю?" алгоритм починається з правого боку числа і повинен перевіряти кожен біт, поки він не досягне нульового біта, while(1) { }цикл повинен буде перевірити вдвічі більше бітів за ітерацію, ніж while(2) { }цикл.

Для цього потрібна дуже неправильна ментальна модель того, як працюють комп'ютери, але у неї є своя внутрішня логіка. Один із способів перевірки - запитати, while(-1) { }чи while(3) { }буде однаково швидкий, чи while(32) { }буде ще повільніше .

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

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

Але я, звичайно, не знаю, я просто пропоную один варіант.

Я думаю, що підказку можна знайти в "запитанні старшого керівника". Ця людина, очевидно, перестала програмувати, коли стала менеджером, і тоді йому знадобилося кілька років, щоб стати старшим менеджером. Ніколи не втрачав інтересу до програмування, але ніколи не писав рядки з тих днів. Тож його посилання - це не "якийсь пристойний компілятор там", як згадують деякі відповіді, а "упорядник, з яким ця людина працювала 20-30 років тому".

У той час програмісти витрачали чималий відсоток свого часу на тестування різних методів для того, щоб зробити свій код швидшим та ефективнішим, оскільки час ЦП "центрального мінікомп'ютера" був таким цінним. Як і люди, що писали компілятори. Я здогадуюсь, що єдиний компілятор, який його компанія зробив доступним на той час, був оптимізований на основі "часто зустрічаються тверджень, які можна оптимізувати", і, скориставшись деяким ярликом, стикався з деяким часом (1) і оцінював усе інше, включаючи деякий час (2). Маючи такий досвід, можна пояснити свою позицію та впевненість у ній.

Найкращим підходом до прийняття на роботу є, мабуть, такий, який дозволяє старшому керівнику захопитися і викладати 2-3 хвилини на тему "старі добрі програми програмування", перш ніж ВИ плавно ведуть його до наступної теми інтерв'ю. (Тут важливий гарний час - занадто швидкий, і ви перериваєте історію - занадто повільно, і вас позначають як когось із недостатньою увагою). Скажіть йому в кінці інтерв'ю, що вам буде дуже цікаво дізнатися більше про цю тему.

Ви мали б запитати його, як він дійшов до цього висновку. Під будь-яким порядним компілятором там два компілюються в одній інструкції asm. Отже, він повинен був сказати вам і компілятору. І навіть так, вам доведеться дуже добре знати компілятор і платформу, щоб навіть зробити теоретично освічену здогадку. Зрештою, це насправді не має значення на практиці, оскільки є й інші зовнішні фактори, такі як фрагментація пам'яті або завантаження системи, які впливатимуть на цикл більше, ніж ця деталь.

Заради цього питання, я повинен додати, що я пам’ятаю, що Дуг Гвін з комітету C писав, що деякі ранні компілятори C без проходу оптимізатора генерують тест у збірці для while(1)(порівняння з for(;;)яким цього не було б).

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

• без оптимізатора пройти компілятор генерує тест і для, while(1)і дляwhile(2)
• за допомогою оптимізатора пройти компілятор доручає оптимізувати (з безумовним стрибком) все, while(1)тому що вони розглядаються як ідіоматичні. Це не дозволить while(2)пройти тест, а отже, змінить продуктивність між ними.

Я, звичайно, додам інтерв'юеру, що не врахування while(1)та while(2)однакова конструкція є ознакою низької якості оптимізації, оскільки це еквівалентні конструкції.

Ще одне питання про таке, щоб переконатися, чи набралися ви сміливості сказати своєму менеджеру, що він / вона помиляється! І як м'яко ви можете це спілкувати.

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

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

Моя відповідь була б; це не так важливо, я скоріше зосереджуюсь на бізнес-проблемі, яку ми вирішуємо. Зрештою, саме за це я буду платити.

Більше того, я б став на вибір, while(1) {}тому що це частіше, а іншим товаришам по команді не потрібно було б витрачати час, щоб з'ясувати, чому хтось піде на більшу кількість, ніж 1.

Тепер підемо написати якийсь код. ;-)

Якщо ви переживаєте за оптимізацію, вам варто скористатися

for (;;)

тому що тестів немає. (цинічний режим)

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

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

Раніше я програмував код C і Assembly, коли ця дурниця могла змінити щось. Коли це все змінилося, ми написали це в Асамблеї.

Якби мені задали це запитання, я повторив би відому цитату Дональда Кнута 1974 року про передчасну оптимізацію і пішов, якби інтерв'юер не сміявся і рухався далі.

Можливо, інтерв'юер поставив таке німе запитання навмисно і хотів, щоб ви зробили 3 бали:

1. Основні міркування. Обидві петлі нескінченні, про продуктивність важко говорити.
2. Знання про рівні оптимізації. Він хотів почути від вас, якщо ви дозволите компілятору зробити будь-яку оптимізацію для вас, це оптимізувало б умову, особливо якщо блок не був порожнім.
3. Знання про мікропроцесорну архітектуру. Більшість архітектур мають спеціальну інструкцію процесора для порівняння з 0 (хоча і не обов'язково швидше).

Ось проблема: Якщо ви насправді пишете програму і вимірюєте її швидкість, швидкість обох циклів може бути різною! Для трохи розумного порівняння:

unsigned long i = 0;
while (1) { if (++i == 1000000000) break; }

unsigned long i = 0;
while (2) { if (++i == 1000000000) break; }

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

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

Вони обидва рівні - однакові.

Відповідно до специфікацій, все, що не дорівнює 0, вважається істинним, тому навіть без оптимізації, а хороший компілятор не генерує жодного коду на час (1) або поки (2). Компілятор генерував би просту перевірку != 0.

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

І так витратити на це ще більше часу ...

"while (2)" є смішним, тому що,

"while (1)" і "while (true)" історично використовуються для створення нескінченного циклу, який очікує, що "перерва" буде викликана на певному етапі всередині циклу на основі умови, яка неодмінно відбудеться.

"1" просто існує для того, щоб завжди оцінювати справжнє, а тому говорити "в той час як (2)" приблизно так само нерозумно, як сказати "в той час, як (1 + 1 == 2)", що також оцінить як істинне.

А якщо ви хочете бути абсолютно нерозумним, просто використовуйте: -

while (1 + 5 - 2 - (1 * 3) == 0.5 - 4 + ((9 * 2) / 4)) {
    if (succeed())
        break;
}

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

Це залежить від компілятора.

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

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

Я маю на увазі: це насправді не питання, пов'язане з мовою (С).

Оскільки люди, які хочуть відповісти на це запитання, хочуть отримати найшвидший цикл, я б відповів, що обидва однаково складаються в один і той же код складання, як зазначено в інших відповідях. Тим не менш, ви можете запропонувати інтерв'юеру скористатися «розкручуванням циклу»; a do {} while цикл замість циклу while.

Обережно: Вам потрібно забезпечити, щоб цикл принаймні завжди працював один раз .

Петля повинна мати стан розриву всередині.

Також для такого типу циклу я особисто вважаю за краще використовувати do {} while (42), оскільки будь-яке ціле число, крім 0, буде виконувати цю роботу.

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

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

#define while(x) sleep(x);

це дійсно зробить while(1)удвічі швидше (або вдвічі повільніше), ніж while(2).

Єдина причина, з якої я можу подумати, чому це while(2)буде повільніше, це:

1. Код оптимізує цикл для

   cmp eax, 2

2. Коли відбувається віднімання, ви по суті віднімаєте

   а. 00000000 - 00000010 cmp eax, 2

   замість

   б. 00000000 - 00000001 cmp eax, 1

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