Чи корисне поширене використання інформатики «ігнорування констант» при порівнянні класичних обчислень з квантовими обчисленнями?

Даніель Санк згадав у коментарі , відповідаючи на (мою) думку, що постійне прискорення на проблему, що приймає алгоритм багаточленного часу, є мізерним,$10^8$

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

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

Але я розумію, що це дещо інша ситуація, як зараз:

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

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

Отже, моє питання:

Порівнюючи ефективність алгоритмів на квантовому комп'ютері з алгоритмами на класичному комп’ютері, чи є практикою «ігнорування» констант хорошою практикою?

Загальне використання „ігнорування констант” в „Комп’ютерній науці” корисне лише тоді, коли відмінності в продуктивності різних видів архітектури апаратного забезпечення або програмного забезпечення можна ігнорувати за допомогою невеликого масажу. Але навіть у класичних обчисленнях важливо знати про вплив архітектури (кешування поведінка, використання жорсткого диска), якщо ви хочете вирішити складні проблеми чи великі проблеми.

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

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

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

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

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

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

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

По-перше, не існує масштабування аналізів квантових пристроїв, як у нас, для алгоритмів на апаратному забезпеченні CMOS. Так говорити про$O\left(f\left[N\right]\right)$є недоліком. По-друге, зважаючи на відсутність теоретичного підгрунтя, нам доведеться робити масштабні аналізи за допомогою експериментів. Однак доступні в даний час розміри проблем ($N$) досить обмежені. Як такий, ми навіть не знаємо, чи знаходимося в асимптотичній межі ("справжня поведінка пристрою").

Тому знехтувати префакторами (тобто постійними факторами) може бути передчасно. Пуристи стверджують, що лише покращення масштабування ("зміна нахилу") - це справжнє прискорення. Я погоджуюся, однак, якщо ваш квантовий пристрій масштабує, а також найкращі класичні алгоритми ще має$10^{10}$ prefactor, я б назвав це корисним для додатків.

На жаль, сучасний стан техніки - це масштабування D-Wave настільки ж добре, як найкращі алгоритми, але лише з a $\approx300$Перевага фактора перед кодом, що працює на одному ядрі Більше того, це проблема синтетичного орієнтиру, а не застосування інтересу. Далеко не руйнівний ... Докладнішу інформацію див. На https://arxiv.org/abs/1711.01368 .

Не можна ігнорувати постійні фактори при порівнянні квантових обчислень з класичними обчисленнями. Вони занадто великі.

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

Речі по дну - це чарівні державні заводи. У них розмір фізичних кубітів 150K. Оскільки ворота AND використовує 150 Кбіт за 0,6 мілісекунд, ми гадаємо, що об'єм квантового затвора І в просторі становить приблизно 90 кубічних секунд.

Одна з цілей моїх колег - використовувати 1 процесор на 100 кубітів під час виправлення помилок. Тому ми можемо сказати, що 90 кубічних секунд вимагає 0,9 cpu секунд роботи. Ми зробили квантові конструкції в декілька разів ефективнішими, оскільки було зроблено вищезазначене зображення, тому давайте назвемо його на 0,1 cpu секунди.

(Є багато припущень, які враховують ці оцінки. Що таке архітектура, коефіцієнт помилок тощо. Я лише намагаюся передати ідею порядку порядку.)

Для виконання 64-бітного додавання потрібно 63 І ворота. 63 * 0,1 cpu секунд ~ = 6 cpu секунд. Кількісно 64-бітове додавання коштує дорожче, ніж процесор. Класично 64-бітове додавання коштує менше, ніж наносекунда CPU. Тут легко постійна різниця факторів у 10 мільярдів. Якщо порівнювати з паралельною класичною машиною, наприклад, GPU, цифри стають ще гіршими. Не можна ігнорувати постійні фактори з такою кількістю цифр.

Наприклад, розглянемо алгоритм Гровера, який дозволяє шукати задовольняючий вхід функції в оцінках функції sqrt (N) замість N оцінок. Додайте постійний коефіцієнт 10 мільярдів і вирішіть, де квантовий комп'ютер починає вимагати меншої кількості оцінок:

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

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

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

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

Але по-перше, я вважаю, що коротка екскурсія є несекретною.

Коли у нас дієвий алгоритм?

Коли Даніель Санк запитав мене, що б я робив, якби був алгоритм розбиття простих чисел на a $10^6$прискорення фактора на тестовому наборі серйозних випадків, я спершу відповів, що сумніваюся, це буде пов’язано з алгоритмічними вдосконаленнями, але іншими факторами (або машиною, або реалізацією). Але я думаю, зараз у мене інша реакція. Дозвольте додати вам тривіальний алгоритм, який може визначати дуже великі числа протягом мілісекунд і, тим не менш, дуже неефективний :

1. Візьміть набір $P$ (досить великих) прайменів.
2. Обчислити $P^2$, набір усіх композитів з рівно двома факторами $P$. Для кожного композиту збережіть, яку пару простих ліній використовують для його побудови.
3. Тепер, коли дано екземпляр від $P^2$, просто подивіться на факторизацію в нашій таблиці та повідомте про це. В іншому випадку повідомте про "помилку"

Я сподіваюся, що очевидно, що цей алгоритм є сміттям, оскільки він працює лише правильно, коли наш вхід є $P^2$. Однак чи можемо ми побачити це, коли алгоритм заданий як чорний ящик і "за збігом" лише тест із вхідними даними$P$? Звичайно, ми можемо спробувати перевірити багато прикладів, але це зробити дуже просто$P$ дуже великий, але алгоритм неефективний для входів з $P^2$ (можливо, ми хочемо використовувати хеш-карту чи щось таке).

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

Отже, я б зараз відповів: "Пробудьте мене, коли буде кращий показник ефективності".

Як нам тоді зробити краще?

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

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

Перевага статистичного тестування при параметризації (наприклад, це наш алгоритм $O(n^3)$? ) полягає в тому, що модель більш загальна, і тому її важче «обдурити», як у попередньому розділі. Це не неможливо, але принаймні статистичні твердження про те, чи є це розумним, можуть бути виправдані.

Отже, що робити з константами?

Я думаю, що лише констатуючи "$10^9$ прискорення, вау! "- це поганий спосіб вирішення цієї справи. Але я також думаю, що повністю знехтувати цим результатом також погано.

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