Програми, які стверджують, що вони не є "багатоядерними"

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

Як це може бути? Багато програм (особливо ігор) по своїй суті використовують паралельність, а оскільки ОС відповідає за планування завдань на процесорі, то ці програми не є по суті перевагою наявних кількох ядер? Що би означало в цьому контексті «скористатися кількома ядрами»? Чи справді такі розробники забороняють планування завдань ОС і примушування спорідненості або їх власне планування? (Звучить як головне питання стабільності).

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

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

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

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

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

Існують більші архітектурні виклики в боротьбі з ефективною одночасністю

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

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

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

Суть:

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

Багато програм (особливо ігри) по суті використовують паралельність,

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

У C, C ++ та C # вам потрібно чітко сказати програмі для запуску нових потоків та / або процесів.

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

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

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

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

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

Це не повна відповідь. Це застереження.

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

• 14 секунд для однопотокової версії.
• 15 секунд для 2-різьбової версії.

Це було про те, чого я очікував.

Потім я спробував це на більш новій, двоядерній машині.

• 11 секунд для однопотокової версії.
• 20 секунд для 2-різьбової версії.

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