Чи алгоритми (і ефективність взагалі) стають менш важливими?

29

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

efficiency

— Квора Фен
джерело

2

"і так, і ні"!

— vzn

4

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

— Пітер Шор

2

Якщо розмір введення достатньо великий, різниця в порядку набору між алгоритмами важлива незалежно від того, наскільки швидко працює машина. Але я час від часу обманюю внесення змін, щоб "оптимізувати" постійну різницю факторів, лише щоб зрозуміти, що використання виразів, вбудованих у синтаксичний цукор мови програмування <cough> Python </cough>, значно швидше, ніж моя "оптимізація".

— kojiro

див. також закон муру

— vzn

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

— vzn

31

Мені дуже подобається приклад із книги « Вступ до книги Алгоритми» , який ілюструє значення ефективності алгоритму:

Порівняємо два алгоритми сортування: сортування вставки та об'єднання сортування . Їх складність становить і $O(n^2) = c_1n^2$ $O(n\log n) = c_2n \lg n$ відповідно. Зазвичай сортування злиття має більший постійний коефіцієнт, тому припустимо . $c_1 < c_2$

Щоб відповісти на ваше запитання, ми оцінюємо час виконання більш швидкого комп’ютера (A), що працює з алгоритмом сортування вставки, проти алгоритму сортування впорядкованого комп'ютера (B).

Ми припускаємо:

розмір задачі на введення - 10 мільйонів чисел: ; $n=10^7$
комп'ютер A виконує інструкцій в секунду (~ 10 ГГц); $10^{10}$
комп'ютер B виконує лише інструкцій в секунду (~ 10 МГц); $10^7$
постійні коефіцієнти (що трохи завищено) та (насправді менше). $c_1=2$ $c_2=50$

Так що з цими припущеннями потрібно

для комп'ютера A для сортування

\frac{2 \cdot (10^{7})^{2} інструкції}{10^{10} інструкції / другий} = 2 \cdot 10^{4} секунд

$\frac{2 \cdot (10^7)^2 \text{ instructions}} {10^{10} \text{ instructions}/\text{second}} = 2 \cdot 10^4 \text{ seconds}$

чисел та

10^{7}

$10^7$

\frac{50 \cdot 10^{7} \lg 10^{7} інструкції}{10^{7} інструкції / другий} \approx 1163 рік секунд

$\frac{50 \cdot 10^7 \lg 10^7 \text{ instructions}} {10^{7} \text{ instructions}/\text{second}} \approx 1163 \text{ seconds}$

для комп’ютера B.

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

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

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

— Павло Зайченков
джерело

4

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

— Bartosz Przybylski

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

займає

роботи, і вам потрібно обчислити

для

різних

. Послідовно вартість часу становить

f (x)

$f(x)$

n^{2}

$n^2$

\sum_{i = 1}^{n} f (x_{i})

$\sum_{i=1}^n f(x_i)$

n

$n$

x_{i}^{'} s

$x_i's$

O (n \cdot n^{2} + n) = O (n^{3})

$O(n\cdot n^2 + n) = O(n^3)$ , тоді як паралельно з

процесорами робота -

.

n

$n$

O (n^{2} + n) = O (n^{2})

$O(n^2 + n) = O(n^2)$

— Нік Алгер

"Тож комп'ютер, який у 1000 разів повільніше, може вирішити проблему в 17 разів швидше". Це помилкове твердження, оскільки ви одночасно поєднуєте швидкість обладнання та різні алгоритми. Скоріше порівняйте комп'ютер A проти комп'ютер B для кожного типу сортування окремо. (Чому я не можу використовувати сортування об'єднань на комп’ютері A або сортування вставок на комп’ютері B?)

— AquaAlex

3

@AquaAlex, мета прикладу - показати, що повільний комп'ютер може перевершити швидкий лише за допомогою вибраного алгоритму. Ми могли б порівняти час виконання для кожного типу сортування окремо або запустити сортування злиття на A та сортування вставок на B. Але показано, що швидший комп'ютер зазвичай працює краще, ніж повільний, просто не має сенсу.

— Павло Зайченков

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

— AquaAlex

36

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

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

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

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

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

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

— Юваль Фільм
джерело

"алгоритми ще не мертві" ... зовсім навпаки, ми, ймовірно, живемо через "золотий вік алгоритмів" ....

— vzn

12

Знання алгоритмів набагато більше, ніж те, як писати швидкі алгоритми.

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

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

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

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

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

Щодо важливості ефективності програмного забезпечення, я наведу Закон Вірта:

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

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

— Дай
джерело

7

Так , вони є "відносно" менш важливими для широкої промисловості. Текстовий редактор може бути "досить швидким", і він може не потребувати великих вдосконалень. Значна частина ІТ-зусиль спрямована на те, щоб переконатися, що компонент A, написаний на Java, працює з компонентом B, написаним на C, правильно спілкується через чергу черги повідомлень, написане на Cobol (чи щось таке), або для виходу товару на ринок тощо.

Крім того, архітектура ускладнилася. Коли у вас були прості старі прості процесори, де ви мали 1 інструкцію за цикл, і ви писали в збірці, оптимізації були «легкими» (вам просто потрібно було порахувати кількість інструкцій). На даний момент у вас немає простого процесора, але повністю конвеєрного, суперскалярного, нестандартного процесора з перейменуванням реєстру та кешами декількох рівнів. І ви пишете не в зборах, а в C / Java / тощо. де код складений / JITed (як правило, для кращого коду, ніж ви або я написав би у збірці), або в Python / Ruby / ..., де інтерпретується код, і ви розділені кількома рівнями абстракції від машини. Мікрооптималізації важкі, і більшість програмістів досягли б протилежного ефекту.

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

Однак є й інші випадки, коли «швидкість» від алгоритмів все ще є вибором, коли важлива швидкість (HPC, вбудовані пристрої тощо). Ви знайдете в багатьох університетських групах, що спеціалізуються на компіляторах та / або оптимізації програмного забезпечення. Наприклад, простий порядок впорядкування циклу може отримати прискорення в тисячу разів лише тому, що він ефективно використовує кеш - хоча це може бути прикордонним прикладом розрив пам’яті процесора зростає в 1000 разів за останні 30 років. Також архітектура комп’ютерів є частиною CS. Тому багато поліпшень швидкості обчислень насправді є частиною загального поля CS.

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

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

— Мацей П'єхотка
джерело

2

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

Теоретична інформатика - Це наука, що розвивається, а це означає, що з часом ми знайдемо нові і кращі способи вирішення проблем, тобто, вдосконалені алгоритми пошуку та сортування, наприклад.
Більші громади / великі бібліотеки - Оскільки багато роботи було зроблено іншими людьми, ми можемо просто побудувати на своїй роботі та використовувати алгоритми, які вони вже створили та навіть зашифрували. І ці бібліотеки будуть оновлюватися з часом, що дозволяє нам автоматичний доступ до більш ефективних програм / алгоритмів.
Розвиток - Зараз у нас є проблема, на яку я думаю. Багато програмістів не є вченими-комп’ютерами, тому вони пишуть код для вирішення бізнес-задач, а не технічних / теоретичних проблем, і з задоволенням використовують сортування бульбашок, наприклад, швидкий сорт. І тут швидкість апаратних засобів дозволяє поганим програмістам уникнути використання поганих алгоритмів та поганих методів кодування. Пам'ять, швидкість процесора, місця для зберігання цих речей вже не є головною проблемою, і кожні кілька місяців речі стають все більшими, швидшими та дешевшими. Я маю на увазі поглянути на нові мобільні телефони. Зараз вони більш досконалі, ніж комп'ютери / сервери на мейнфреймі 1970-х - 80-х років. Більше сховища, більше процесорної потужності, швидша пам'ять.
UI & DATA - Інтерфейс користувача / Досвід користувачів та DATA зараз вважаються важливішими, ніж надефективний код у більшості областей розвитку. Тому швидкість стає і видається лише тоді, коли користувачеві доведеться довго чекати. Якщо ми надаємо користувачеві гарний зовнішній вигляд і він отримує хорошу відповідь від програми, він задоволений. І якщо бізнес знає, що всі дані зберігаються надійно та надійно, і вони можуть їх отримати та маніпулювати в будь-який час, їм все одно, скільки місця йому потрібно.

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

— AquaAlex
джерело

1

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

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

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

Також, наприклад, Список однойменних законів, Вікіпедія :

Закон Паркінсона - «Робота розширюється так, щоб заповнити доступний час для її завершення». Створений К. Норткот Паркінсоном (1909–1993), який також придумав свою суперечку: "Витрати збільшуються для досягнення доходу". У комп’ютерах: програми розгортаються, щоб заповнити всю наявну пам'ять.

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

В економіці парадокс Джевона (/ ˈdʒɛvənz /; іноді ефект Джевона) - це твердження, що технологічний прогрес, що підвищує ефективність використання ресурсу, як правило, збільшує (а не зменшує) швидкість споживання цього ресурсу.

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

— взн
джерело

Чому потік? Мені здається, що згадка про закон Паркінсона та парадоксу Джевона є дуже показовою.

— Ювал Фільм

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

— Джухо

1

Це не «проблеми з граматикою», це інший стиль. Це як би сказати, що носій мови робить "помилки", говорячи власною мовою, а насправді або мова змінюється, або є регіональна дисперсія. У цьому випадку це ідіоматичний стиль vzn.

— Yuval Filmus

-3

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

— Енді
джерело

Не буде істинним зворотом - якщо у вас є "нескінченне" сховище, вам не потрібно буде турбуватися про складність простору. «Проблема» полягає не в тому, що накопичувач зростає, а в тому, що дані для роботи зростають в синхронізації, заповнюючи прискорення, пропоновані збільшенням обчислювальної потужності та пам’яті - що добре, ми хочемо моделювати космос більш реалістично, складаючи більше білка тощо. (PS. Я не проголосував)

— Maciej Piechotka

4

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

— Рафаель