Коли використовувати DAG (спрямовану ациклічну графіку) в програмуванні?

Нещодавно я знайшов рамку під назвою ecto .

У цьому рамках базовий компонент під назвою "плазма" - це ecto Directed Acyclic Graph. В екто плазмою можна керувати планувальник ecto.

Мене цікавить, у чому перевага цього механізму, і в яких інших ситуаціях ми можемо використовувати концепцію DAG?

Приємне запитання.

• Код може бути представлений DAG, що описує входи та виходи кожної з арифметичних операцій, що виконуються в коді; таке представлення дозволяє компілятору ефективно виконувати загальне усунення підвыражения.
• Більшість систем управління джерелами управління реалізують зміни як DAG.
• Кілька мов програмування описують системи значень, які пов'язані один з одним направленим ациклічним графіком. Коли одна величина змінюється, її наступники перераховуються; кожне значення оцінюється як функція своїх попередників у DAG.
• DAG зручно виявляти тупикові місця, оскільки вони ілюструють залежності між набором процесів та ресурсів.
• У багатьох рандомізованих алгоритмах обчислювальної геометрії алгоритм підтримує DAG історії, що представляє особливості деякої геометричної побудови, які були замінені пізнішими функціями більш тонкого масштабу; На запити розташування точок можна відповісти, як і на дві вищезгадані структури даних, шляхом слідування шляхів у цій DAG.
• Як тільки у нас є DAG в пам'яті, ми можемо записати алгоритми для обчислення максимального часу виконання всього набору.
• Під час програмування систем електронних таблиць графік залежності, який з'єднує одну клітинку до іншої, якщо перша комірка зберігає формулу, яка використовує значення у другій комірці, повинна бути спрямованим ациклічним графіком. Цикли залежностей заборонені, оскільки вони призводять до того, що клітини, що беруть участь у циклі, не мають чітко визначеного значення. Крім того, вимагати ациклічності залежностей дозволяє використовувати топологічний порядок для планування перерахунку значень комірок при зміні електронної таблиці.
• За допомогою DAG ми можемо записати алгоритми для оцінки обчислень у правильному порядку.

Редагувати:

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

Хороші ресурси:

• http://www.biomedcentral.com/1471-2288/8/70
• http://www.ncbi.nlm.nih.gov/pubmed/12453109
• http://www.ericsink.com/vcbe/html/directed_acyclic_graphs.html
• http://xlinux.nist.gov/dads/HTML/directAcycGraph.html

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

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

Якщо ви все ще хочете мати певні стосунки з програмуванням, то врахуйте наступні моменти:

• DAG (відомий як Wait-For-Graphs - більше технічних деталей ) є зручним у виявленні тупикових ситуацій, оскільки вони ілюструють залежності між набором процесів та ресурсів (обидва - це вузли в DAG). Тупик трапиться, коли буде виявлено цикл.
• Коли у вас є DAG в пам'яті, ви можете написати алгоритми для:
  • переконайтесь, що обчислення оцінені у правильному порядку ( топологічне сортування )
  • якщо обчислення можна проводити паралельно, але кожен обчислення має максимальний час виконання, ви можете обчислити максимальний час виконання всього набору

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

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

Я працював у XSLT, можливо, 4 роки. Мені було страшно, намагаючись пояснити, чому це не дуже хороша мова програмування загального призначення, але DAG - це причина. Зокрема, XSLT - це мова, керована даними. Ви визначаєте функції (так, у сенсі функціонального програмування), але не обов'язково викликати ці функції зі свого коду. Швидше, XSLT встановлює комбінацію вибору та ітерації через вузли вхідного XML-документа. Це дозволяє структурі вхідних даних визначати, які функції викликаються та в якому порядку.

Це було дуже цікаво і дуже круто, поки ваша програма не зіткнулася з умовами даних, які ви не тестували о 2:30 ранку, і вам довелося прокинутися і виправити це. Коли ви дозволяєте даним визначати DAG, то визначення DAG стає всіма можливими умовами введення - які для будь-якого нетривіального ділового додатку виходять за межі незрівнянних; вони немислимі.

Спочатку я подумав, що функціональне програмування може не бути DAG, тому що порядок виконання іноді не зрозумілий, або навіть продуманий програмістом. Але функціональна програма визначає залежності. Насправді декларативний характер функціонального програмування можна вважати таким, що визначає лише залежності (a ^ 2 = b ^ 2 + c ^ 2), не вказуючи порядок виконання (не має значення, чи спочатку квадрат "b" чи "c" , до тих пір, поки вони обидва будуть квадратними, перш ніж їх додавати разом).

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

Приємне запитання - дякую за публікацію!

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

Мені цікаво, у чому перевага плазми в Ecto ...

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

в яких інших ситуаціях ми можемо використовувати концепцію DAG?

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

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

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

Додаючи ще одну відповідь, оскільки не бачили посилання на побудову систем, таких як makeDAG, щоб з'ясувати залежності для побудови.

Детальніше тут