Чи залежать алгоритми від комп'ютерної архітектури?

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

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

Я думаю, я пропускаю кілька великих фотографій? Спасибі.

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

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

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

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

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

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

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

Але ці алгоритми все одно роблять те саме. Архітектури не змінюють те, що вони роблять.

"Здається, паралельні алгоритми залежать від паралельних архітектур?"

На мою думку, відповідь проста: ні. Загалом я отримую лише властивості

• паралелізм
• розмір слова (неявні обмеження ресурсів)

при мисленні апаратної архітектури.

Посилаючись на паралелізм, ви можете мати будь-який паралельний алгоритм, щоб обчислювати пакетну кількість, а будь-яка паралельна арка працювати серійно, щоб алгоритм не залежав від цього. Розмір слова може бути проблемою чисельної стабільності, але не самого алгоритму. Обмеження ресурсів на зразок 64-бітного може описувати лише 2 ^ 64 різні числа, можливо, проблема, але все-таки елементи обмежені.

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

Наприклад, при квантовому обчисленні деякі величини Big-O можуть змінюватися, і тоді я б сказав це

"алгоритми не залежать від комп'ютерної архітектури"

вже не відповідає дійсності.

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

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

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

Теоретично алгоритми повністю не залежать від архітектури. Ви завжди можете наслідувати паралельну архітектуру в системі з одним випуском часу. Ви можете взагалі міркувати про алгоритми без архітектури. Книга Кнут використовує вигадану архітектуру.

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

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

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

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

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

Ще одна причина, чому алгоритми не настільки абстрактні від апаратної архітектури, - це коли потрібно відповідати деяким обмеженням .

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

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

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

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

Деякі пов’язані ключові слова, які можуть вас зацікавити:

• Місцевість довідника
• Оптимізація циклу
• Оптимізація петлевих гнізд
• Масштабований населений пункт

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

Визначення алгоритму з Вікіпедії:

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

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

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

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

Це питання та відповідь також цікаві для отримання більш широкого погляду на алгоритми.

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

Наприклад, колись кількість програм, необхідних для читання речей із пам'яті, вважалася важливішою, ніж місця, які слід прочитати. Читання речей, які розташовувалися поблизу один одного в пам’яті, було дещо дешевше, ніж читання речей, які були далеко один від одного, але не обурювали. Оскільки швидкість основного процесора зросла зі швидкістю, значно перевищує швидкість пам'яті, проте важливість послідовності доступу значно зросла. Можливо, щоб одна програма виконувала в десять разів більше інструкцій, ніж інша, і все-таки запускалася швидше, якщо 95% вибору пам’яті колишньої програми генерують хіти L1 кеша, а більшість вибору пам'яті останньої програми генерують пропуски кешу.

Крім того, певні види алгоритмів, пов'язаних з паралельною валютою, роблять різні припущення щодо того, коли дані, записані в пам'ять одним процесорним ядром, будуть «помічені» іншими ядрами. Багато процесорів мають різні способи їх читання та запису в пам'ять, із різними витратами та гарантіями щодо видимості. Деякі алгоритми будуть дуже добре працювати над архітектурами, які можуть задовольнити вимоги щодо видимості "безкоштовно", але погано над іншими, де інструкції, необхідні для цих гарантій, дорогі. Дійсно, в деяких архітектурах деякі гарантії, пов’язані з паралельною валютою, можуть бути гарантовано спрацьовуючи лише обмеженням виконання одного ядра CPU, що поділяється часом (що, звичайно, переможе точку використання одночасного алгоритму).

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

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

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

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

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

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

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

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