Чи потрібно щось робити на багатоядерному процесорі?

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

Чи є щось, що потрібно зробити на багатоядерному процесорі?

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

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

$T$$n$$\sim Tn$

Питання: при яких обмеженнях?

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

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

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

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

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

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

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

Дозвольте проілюструвати деякими цифрами. Припустимо, у вас є конвеєр даних (3D-рендерінг тощо), який має 4 етапи обробки, на кожному етапі є 256 KiB програмного коду, і ви зручно мати 4 процесора з 256 KiB кешу L2. Якщо ви спробуєте запустити цю обробку на одному процесорі, то перемикання між чотирма завданнями буде дорогим і спричинить великі пропуски кешу. З іншого боку, якщо ви запускаєте його в чотирьохядерній системі, обчислення потенційно може бути дуже плавним, помилки кешу мінімальні, а контекстні комутатори відсутні. (Як бічне зауваження, це пов'язано з поняттям закріплення певних додатків до певних ядер - наприклад, лише виконання операцій з ядром ОС в одному ядрі або обробка TCP / IP тощо)

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

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

Насправді, якщо ви можете продемонструвати, що ваш алгоритм може бути вирішений машиною Тьюрінга (це практично кожен алгоритм, який нас цікавить), можна довести, що алгоритм може бути виконаний не лише одним основним процесором, а фактично a державна машина з дуже довгим шматочком стрічки для пам’яті!

ШАХИ детектор гонки на насправді використовує це , щоб знайти випадки гонки. Він запускає все однопоточне і систематично досліджує всі можливі переплетення між потоками, намагаючись знайти випадки, коли тест провалюється через гоночний випадок. CHESS залежить від того, що ви можете запустити будь-яке багатопотокове додаток на одному ядрі.

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

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

Інший ліміт виникає з шинами даних. Розглянемо блакитний ген / P як приклад. JUGENE, особливий суперкомп'ютер Blue Gene / P, має 144 терабайти пам'яті. Вони просто не роблять єдиних процесорів, які можуть отримати доступ до всієї цієї пам'яті.

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

Інші відповіді дотримуються обмеженого погляду на паралелізм як "розподілену одночасність". Це дає деякі відповіді: у чистій моделі обчислення à la Turing кілька ядер не пропонують переваги; Єдина перевага, яку ви можете отримати, - це ефективність.

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

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

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

$k$

$k$$k$$k$

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

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

• врахуйте, що кожен процесор має незалежний "[x]%" шанс вийти з ладу під час обчислення. може бути розроблена система, згідно з якою за допомогою зв'язку загальна відмовність системи перевершує окремі компоненти. це було застосовано багато десятиліть тому, наприклад, у системах космічного човника. останнім часом існують базові протоколи, розроблені для його використання, наприклад Paxos, які вирішують так звану проблему консенсусу . більш ґрунтовним прикладом є компанія Google, яка має безліч фірмових алгоритмів, щоб по суті побудувати свій суперкомп'ютер (и) з індивідуально ненадійних елементів у поєднанні з алгоритмами, стійкими до відмов.

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

• Класичний аналіз паралелізму робить висновок, що існує близько 7 "основних" типів проблемних моделей, які розкладаються на особливі паралельні розбиття виконання. див . Пейзаж досліджень паралельних обчислень: Вид з Берклі

• тут є деякий елемент відкритого теоретичного питання, що стосується ефективності роботи, що розглядається в більшості інших відповідей. питання про те, чи існують якісь проблеми, які "є за своєю суттю швидшими" паралельно, ніж послідовні, також відома як P =? NC проблема, де NC вважається класом "ефективно паралельних" алгоритмів, а P - "ефективним [послідовним] алгоритмами "