Чи вплине обладнання та реалізація на складність алгоритмів часу / простору?

Я навіть не студент CS, тому це може бути дурним питанням, але будь ласка, майте на собі ...

У епоху перед комп'ютером ми можемо реалізувати структуру даних масиву лише на зразок масиву ящиків. Оскільки вам потрібно знайти ящик з відповідним індексом, перш ніж витягувати з нього значення, часова складність пошуку масиву становить , припускаючи двійковий пошук. $O(log(n))$

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

Інший приклад - словники Python. Хоча можна отримати складність доступу до словника за допомогою неправильно написаного перевантаженого магічного методу (або смішно невдача, тобто ключі, що мають багато хеш-зіткнень), зазвичай це вважається . У цьому випадку часова складність залежить як від реалізації хеш-таблиці словників Python, так і від виконання ключами хеш-функцій. $O(n)$ __hash__ $O(1)$

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

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

— налзок
джерело

Коментарі не для розширеного обговорення; ця розмова перенесена в чат .

— Жил "ТАК - перестань бути злим"

Відповіді:

Звичайно. Звичайно. Ось як можна примирити свій дискомфорт.

Коли ми аналізуємо час роботи алгоритмів, ми робимо це стосовно певної моделі обчислення . Модель обчислення визначає такі речі, як час, який потрібно для виконання кожної основної операції (це час пошуку масиву час або time?). Час виконання алгоритму може залежати від моделі обчислення. $O(\log n)$ $O(1)$

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

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

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

— DW
джерело

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

— Глибокий Джоші

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

— Госвін фон Бредерлоу

O (1)

$O(1)$

O (n)

$O(n)$

@CortAmmon: Навіть на великому масиві використання лінійного пошуку може бути швидшим, ніж використання хеш-карти, якщо всі, крім кількох елементів, на яких шукається, знаходяться дуже близько до початку. Наприклад, якщо 50% елементів відповідають першому, 25% - другому, 12,5% - третьому і т. Д., За винятком того, що один непарний елемент буде відповідати чомусь, що може бути десь у масиві, очікувана кількість порівнянь з виконати пошук M у списку розміру N буде 2M + N.

— supercat

@DeepJoshi SIMD інструкції не змінюють складність алгоритмів. Вони змінюють лише мультиплікативну константу.

— Жил 'SO- перестань бути злим'

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

$O(\log n)$ $O(1)$

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

— Девід Річербі
джерело

Справедливості, ви пропустили всі частини між "контролер пам'яті встановлює напруги на адресних проводках на двійкове представлення сімнадцяти" і "дані повертаються". Один з цих творів майже напевно - це двійкове дерево пошуку такого типу, яке описано в ОП; але він, тим не менш, виконується в постійному часі, оскільки log n становить приблизно 64, для всіх n .

— Квомплусон

@Quuxplusone Яка частина пам'яті використовує двійковий пошук? У адресних рядках безпосередньо вибираються комірки пам'яті.

— Девід Річербі

Ми працюємо далеко за межами моєї сфери знань, але те, що я намагався мати на увазі, - це те, що декодер адреси буде реалізований з точки зору дерева деміксерів . (Припускаючи, що ми безпосередньо вражаємо фізичну пам’ять, ігноруючи будь-які додаткові ускладнення, пов'язані з кешуванням .) Знову ж, все це додаткове ускладнення додає лише O(lg size-of-memory), тобто незначне - але це саме той біт, про який просили ОП!

— Квомплусон

Ні, апаратне забезпечення не впливає на складність алгоритмів.

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

Пошук правильного ящика (як доступ до елемента масиву) використовує алгоритм "відкритий N-й елемент безпосередньо за індексом", а не алгоритм "пошук лінійно" або "робити двійковий пошук". Алгоритми не змінені, а вибір.

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

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

Або тому, що припущення, які колись були правдивими (або здебільшого істинними), вже не мають права. Наприклад, як, наприклад, кожна операція в основному однакова (лише невеликі постійні відмінності, які не мають значення), або це не має різниці, у яких місцях пам'яті ви отримуєте доступ у якому порядку. Аналізуючи складність, ви можете зробити висновок, що деякий алгоритм значно перевершує, оскільки йому потрібно лише стільки операцій. На практиці ви можете виявити, що кожна операція викликає гарантований пропуск кешу (або ще гірше, помилка сторінки), яка вводить k, який настільки величезний, що він вже не незначний, але домінує над усім.
Якщо алгоритм A займає 500 операцій для обробки набору даних заданого розміру, а алгоритм B займає лише 5, але B викликає 5 несправностей, які спалюють по двадцять мільйонів циклів кожен, то, незважаючи на те, що може вам сказати аналіз або здоровий глузд, A краще.

Це призвело до кумедних сюрпризів, таких як, наприклад, у зозулі Хайшинг кілька років тому. Що було значно вищим, оскільки [довгий список переваг]. Після охолодження hype виявилося, що він значно поступається, оскільки він гарантував два пропуски кешу (помилки для великих наборів даних) при кожному доступі.

Подібне сталося з ідентифікацією та обробкою підмножини даних. Найчастіше правильним рішенням в даний час є: "просто зробіть все" , тобто замість того, щоб зрозуміти, що потрібно для того, щоб перевірити і зробити це, обробляти повний набір даних лінійно, навіть якщо вам, можливо, потрібна лише половина. Тому що, повірте чи ні, це швидше через відсутність непередбачуваних гілок, не пропущено кеш, немає помилок сторінки.
Потрібно прочитати перші 8 КБ та останні 3 КБ файлу 3 МБ? Ну, прочитайте повний файл і викиньте те, що не хочете, бо пошук між ними буде вдесятеро повільнішим, ніж просто читання цілої речі.

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

Отже, впливають не самі алгоритми , а їх корисність та вибір.

— Деймон
джерело