У яких областях програмування час роботи алгоритму насправді є важливою проблемою?

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

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

Швидкість завжди затребувана. Я думаю, ти прав. Ось декілька прикладів, за якими користуються попит на акуратні алгоритми:

1. Криптографія

2. Пошук великих баз даних

3. Сортування та злиття

4. Пошук тексту (неіндексований), включаючи підстановку

5. Математичні проблеми при інтенсивних обчисленнях

6. Моделювання

7. Додатки для майнінгу даних

8. Анімація

9. AI

10. Комп'ютерне бачення

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

Взагалі кажучи, будь-яке використання величезних наборів даних буде проблемою. Коли у вас є щось, що погано масштабується з n, і ви робите насправді величезну кількість, у вас є проблеми. Я підозрюю, що якщо ви зайшли на бета-сторінку Computational Science і трохи поскакали, ви могли б знайти багато проблем, що потребують кращих, швидших алгоритмів. Деякі області, в які я зіткнувся:

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

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

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

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

Маючи більше доступних ресурсів, пізніше може знадобитися розчавити більше даних. Сьогодні вам потрібно проаналізувати файл журналу 10 МБ зі 100 000 рядків. Через рік у вас може виникнути файл журналу об'ємом 100 ГБ з 1 000 000 000 рядків. Якщо обсяг даних зростає швидше, ніж ресурси ресурсів, пізніше у вас виникають проблеми.

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

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

Кілька років тому мені довелося написати алгоритм, який сортував пробірки, розміщені на nстелажах, на дві окремі секції: тобто один підмножина пробірок був обраний, а решта - "не вибрані", а кінцевим результатом буде те, що немає стійки на ньому була б і "вибрана", і "не обрана" трубка (були деякі додаткові вимоги, такі як стиснення). Кожна стійка містила максимум 100 трубок.

Алгоритм повинен був використовуватися для управління роботом для сортування труб у фармацевтичній лабораторії.

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

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

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

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

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

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

Ефективність алгоритму нині не є основною проблемою, оскільки ми використовуємо ефективні алгоритми. Якщо ви використовували алгоритм O (n!), Він буде повільним для будь-якого обладнання.

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

Це стає особливо проблематичним, оскільки багато програм не мають належної перевірки на стрес: люди пишуть код, який добре працює для невеликих наборів тестових даних, але, стикаючись з кількома тисячами разів більше даних, код переривається. Те, що добре працює для десяти записів, швидко вибухає, коли набір даних збільшується. Приклад із реального світу: фрагмент коду, який повинен був очистити елементи, які вже не були пов'язані з жодною категорією, використовував трирівневу вкладену петлю, яка є O (n ^ 3). Маючи лише 10 записів у тестовій базі даних, це означало 1000 перевірок - цілком здійсненно і не вводило помітних затримок. Однак виробнича база даних швидко заповнюється близько 1000 рядків, і раптом код робить мільярд перевірок кожного разу.

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

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

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

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

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

Аналогічна річ з подібно поділом Catmull-Clark, який є дуже рудиментарним матеріалом у комп'ютерній графіці. Але сьогодні конкурентоспроможними, гарячими та надзвичайно ефективними є реалізація GPU, яка наближає підрозділ CC за допомогою Gregory Patches, популяризованого Чарльзом Лупом та пізніше прийнятого Pixar. Більш прямолінійна реалізація процесора зараз застаріла не обов'язково тому, що вона витіснилася з точки зору алгоритмічної складності, а тому, що її витіснила те, що добре грає з GPU.

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

Я колись стикався з проблемою, коли алгоритм зазвичай працював в O (n), але в рідкісних і вкрай малоймовірних обставинах знадобиться час O (n ^ 3) - "рідкісні" обставини були каталогом, що містить файли з іменами, які були дійсними в в одній операційній системі, але не в іншій.

Ніхто ніколи не стикався з проблемами. Тоді один клієнт застосував стратегію для іменування файлів, які систематично запускалися б у випадку O (n ^ 3), і за допомогою декількох 100 файлів система прийшла у віртуальну зупинку. Результатом було те, що алгоритм потрібно було змінити.

Ще три, про які не було сказано:

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

2) Багато проблем з оптимізацією. (Редагувати: з тих пір, як я написав цю відповідь, я потрапив у неї. Моєю метою було обрізати зайві контури, щоб залишити всі вузли, пов'язані з мінімальною вагою сполучних шляхів. Мій оригінальний підхід працював досить добре, поки я не перемістив більше обрізки до цього розпорядку, тоді я зрозумів, що це 2 ^ п. Тепер це n ^ 2, хоча це іноді може дати дещо неоптимальний результат.)

3) Речі, які повинні працювати з великою кількістю даних в режимі реального часу. Подумайте про DVD: Зазвичай ви отримуєте 2 години відео у 4,7 Гб. Розгляньте типовий відеофайл з однаковою роздільною здатністю: ці 2 години відео, як правило, приходять менше 1 Гб. Причиною цього є те, що, коли специфікація DVD була закладена, ви не змогли зробити досить дешевий DVD-програвач, який міг би швидко розшифрувати більш сучасні формати.

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

• Фізичне моделювання:
  • Прогноз погоди
  • Кліматичні імітації
  • Моделювання вибухаючих зірок тощо.
  • Моделювання вибуху ядер
  • Аеродинамічні моделювання автомобілів / літаків / поїздів тощо.
  • ...
• Обчислення зображень із даних радіотелескопа
• Біологічні застосування:
  • Речі з послідовностями ДНК (я не дуже в них)
  • Біохімічні речі, такі як згортання білка
  • Моделювання того, як нервові клітини працюють разом для обробки інформації
  • Моделювання інших складних взаємодій, таких як екосистеми
  • ...
• ...

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

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