Причина небажаного перемикання контексту

Я намагаюся проаналізувати багатопоточну програму, яку я написав на декількох великих машинах (32-ядерні, 256 ГБ оперативної пам'яті). Я помітив, що між роботами, продуктивність програми може різко варіюватися (70-80%). Я не можу знайти причину цієї гігантської дисперсії в роботі програми, але, аналізуючи результати утиліти "time" на великій кількості тестів, я помітив, що кількість небажаних контекстних перемикачів високо співвідноситься з продуктивність програми (очевидно, менше контекстних перемикачів призводить до підвищення продуктивності та навпаки).

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

update: I decided to test my program on a different (and smaller) machine. The other machine is a 4-core (with hypertheading) linux box with 8Gb of RAM, and a much newer kernel --- 3.2.0 vs 2.6.18 on the other machine. On the new machine, I'm unable to reproduce the bi-modal performance profile. This leads me to believe that the issue is either due to a hardware issue (as was suggested in the comments) or to a particularly pathological case at the kernel level that has since been fixed. My current best hypothesis is that it may be a result of the fact that the new machine has a kernel with the completely fair scheduler (CFS) while the old machine does not. Is there a way to test this hypothesis (to tell the new machine to use a different/older scheduler) without having to recompile an ancient kernel version for the new machine?

9
Під "небажаними контекстними перемикачами" ви маєте на увазі "якийсь інший процес, який хотів запустити", або "МОЙ процес зробив щось таке, що призвело до того, що система зупинила його, поки система виконала певну роботу, наприклад, очікуючи, що деякі файлові дані будуть завантажені з диска або мережа "?
додано Автор Mats Petersson, джерело
Просто тому, що ви не самотні, не обов'язково означає, що на вашому комп'ютері недостатньо ресурсів для виконання завдання. Але якщо інші люди поділяють машину, то це важко - якщо, звичайно, ви не можете просити адміністратора персоналу вас правильно підняти пріоритет ваших завдань, над завданнями інших людей або щось подібне. Якщо на машині є конкуруючі завдання, машина буде розділяти ресурси ЦП між завданнями - так працює багатокористувацька система ...
додано Автор Mats Petersson, джерело
Просто тому, що ви не самотні, не обов'язково означає, що на вашому комп'ютері недостатньо ресурсів для виконання завдання. Але якщо інші люди поділяють машину, то це важко - якщо, звичайно, ви не можете просити адміністратора персоналу вас правильно підняти пріоритет ваших завдань, над завданнями інших людей або щось подібне. Якщо на машині є конкуруючі завдання, машина буде розділяти ресурси ЦП між завданнями - так працює багатокористувацька система ...
додано Автор Mats Petersson, джерело
Ви хотіли спробувати скористатися кодом top під час роботи вашої програми? Що б не перешкоджало вам, ймовірно, використовується багато процесорів ....
додано Автор Tony Delroy, джерело
Ви хотіли спробувати скористатися кодом top під час роботи вашої програми? Що б не перешкоджало вам, ймовірно, використовується багато процесорів ....
додано Автор Tony Delroy, джерело
Ви хотіли спробувати скористатися кодом top під час роботи вашої програми? Що б не перешкоджало вам, ймовірно, використовується багато процесорів ....
додано Автор Tony Delroy, джерело
@MatsPetersson yeah - "По-перше, у мене немає кореневих привілеїв на машині" не рекомендує використовувати його виключно.
додано Автор Martin James, джерело
Попросіть системного адміністратора, який має привілеї, дізнатись.
додано Автор Martin James, джерело
Попросіть системного адміністратора, який має привілеї, дізнатись.
додано Автор Martin James, джерело
@MatsPetersson yeah - "По-перше, у мене немає кореневих привілеїв на машині" не рекомендує використовувати його виключно.
додано Автор Martin James, джерело
@MatsPetersson yeah - "По-перше, у мене немає кореневих привілеїв на машині" не рекомендує використовувати його виключно.
додано Автор Martin James, джерело
Я думаю - інші користувачі запланували великі роботи cron.
додано Автор Martin James, джерело
Я думаю - інші користувачі запланували великі роботи cron.
додано Автор Martin James, джерело
Я думаю - інші користувачі запланували великі роботи cron.
додано Автор Martin James, джерело
Як часто це відбувається? Чи можливо, що іноді файл кешується, а іноді це не так? Ви вручну читаєте файл у пам'ять або використовуєте mmap?
додано Автор kfsone, джерело
Як часто це відбувається? Чи можливо, що іноді файл кешується, а іноді це не так? Ви вручну читаєте файл у пам'ять або використовуєте mmap?
додано Автор kfsone, джерело
Ви знаєте про pthread_cond_t?
додано Автор Varvarigos Emmanouil, джерело
Ви знаєте про pthread_cond_t?
додано Автор Varvarigos Emmanouil, джерело
Дуже погано ви стурбовані Linux, а не Solaris/Mac OS/FreeBSD - DTrace зробить коротку роботу розслідування, як це. Докладніше див. Цю серію повідомлень блогів: pt1 , < a href = "http://blog.bignerdranch.com/1968-hoked-on-dtrace-part-2/" rel = "nofollow noreferrer"> pt2 , pt3 , pt4
додано Автор Dan, джерело
Дуже погано ви стурбовані Linux, а не Solaris/Mac OS/FreeBSD - DTrace зробить коротку роботу розслідування, як це. Докладніше див. Цю серію повідомлень блогів: pt1 , < a href = "http://blog.bignerdranch.com/1968-hoked-on-dtrace-part-2/" rel = "nofollow noreferrer"> pt2 , pt3 , pt4
додано Автор Dan, джерело
Виконання будь-якої атомної операції? Це недешево з багатьма процесорами. Інакше ця проблема все ще залишається надто абстрактною. Ви повинні перетворити вашу програму на мінімалістський зразок коду та опублікувати її. Ви самі знайдете проблему, або люди знайдуть основний недолік з розробкою алгоритму.
додано Автор DanielKO, джерело
Виконання будь-якої атомної операції? Це недешево з багатьма процесорами. Інакше ця проблема все ще залишається надто абстрактною. Ви повинні перетворити вашу програму на мінімалістський зразок коду та опублікувати її. Ви самі знайдете проблему, або люди знайдуть основний недолік з розробкою алгоритму.
додано Автор DanielKO, джерело
Виконання будь-якої атомної операції? Це недешево з багатьма процесорами. Інакше ця проблема все ще залишається надто абстрактною. Ви повинні перетворити вашу програму на мінімалістський зразок коду та опублікувати її. Ви самі знайдете проблему, або люди знайдуть основний недолік з розробкою алгоритму.
додано Автор DanielKO, джерело
Перше, чого слід спостерігати - це помилкове спільне використання. Я не можу розібратися в цьому просторі, але перегляньте stackoverflow.com/questions/10143676/ … та розділ 4 першокласника kernel.org/pub/linux/kernel/people/paulmck/perfbook/… . Крім того, це може бути апаратна проблема; Я одноразово працював із 264-ядерним ультрафіолетом SGI, який періодично сповільниться через апаратну відмову, подібно до вашого сценарію "два режими".
додано Автор DanielKO, джерело
Перше, чого слід спостерігати - це помилкове спільне використання. Я не можу розібратися в цьому просторі, але перегляньте stackoverflow.com/questions/10143676/ … та розділ 4 першокласника kernel.org/pub/linux/kernel/people/paulmck/perfbook/… . Крім того, це може бути апаратна проблема; Я одноразово працював із 264-ядерним ультрафіолетом SGI, який періодично сповільниться через апаратну відмову, подібно до вашого сценарію "два режими".
додано Автор DanielKO, джерело
Як ви дізналися, що ви не поступаються і не чекаєте? Чи виділяє ваша програма пам'ять, виконує системні виклики або використовує будь-яку бібліотеку, яка їх виконує? Чи є ваша програма пам'яттю-вводом-виводом?
додано Автор DanielKO, джерело
Як ви дізналися, що ви не поступаються і не чекаєте? Чи виділяє ваша програма пам'ять, виконує системні виклики або використовує будь-яку бібліотеку, яка їх виконує? Чи є ваша програма пам'яттю-вводом-виводом?
додано Автор DanielKO, джерело
Як ви дізналися, що ви не поступаються і не чекаєте? Чи виділяє ваша програма пам'ять, виконує системні виклики або використовує будь-яку бібліотеку, яка їх виконує? Чи є ваша програма пам'яттю-вводом-виводом?
додано Автор DanielKO, джерело
О, я забув GNU час, що має ці додаткові речі. Як визначається кількість незначних помилок сторінки? Також, інші питання, які я попросив.
додано Автор DanielKO, джерело
О, я забув GNU час, що має ці додаткові речі. Як визначається кількість незначних помилок сторінки? Також, інші питання, які я попросив.
додано Автор DanielKO, джерело
О, я забув GNU час, що має ці додаткові речі. Як визначається кількість незначних помилок сторінки? Також, інші питання, які я попросив.
додано Автор DanielKO, джерело
Перше, чого слід спостерігати - це помилкове спільне використання. Я не можу розібратися в цьому просторі, але перегляньте stackoverflow.com/questions/10143676/ … та розділ 4 першокласника kernel.org/pub/linux/kernel/people/paulmck/perfbook/… . Крім того, це може бути апаратна проблема; Я одноразово працював із 264-ядерним ультрафіолетом SGI, який періодично сповільниться через апаратну відмову, подібно до вашого сценарію "два режими".
додано Автор DanielKO, джерело
Цікаво, що я бачу дуже подібний профіль продуктивності, якщо я видаляю фактичні записи атома з коду; тому програма просто читає у файлі та виконує певну обробку на підсловах (наприклад, обчислює хеш-функцію). Дуже дивно.
додано Автор nomad, джерело
Спасибі @ gerty3000! Я насправді стурбований продуктивністю в Mac OS, але я просто не маю доступу до стільки машин для тестування на цій платформі. Насправді, було б цікаво подивитися, чи ця проблема навіть спливає в OSX, так як я вважаю, що планувальник абсолютно інший, і, якщо це джерело неприємностей, у OSX взагалі не може бути ніяких проблем.
додано Автор nomad, джерело
Спасибі @ gerty3000! Я насправді стурбований продуктивністю в Mac OS, але я просто не маю доступу до стільки машин для тестування на цій платформі. Насправді, було б цікаво подивитися, чи ця проблема навіть спливає в OSX, так як я вважаю, що планувальник абсолютно інший, і, якщо це джерело неприємностей, у OSX взагалі не може бути ніяких проблем.
додано Автор nomad, джерело
Різниця, яку я повідомила, полягає у багатьох зворотних трасах. Проте продуктивність чергується між "швидкими" та "повільними" режимами. Файл аналізується потоком читача, який заповнює паралельну чергу з подвійним закінченням, і дані потім витягуються з черги іншими потоками для обробки. Однак я не думаю, що це пов'язано з кешуванням файлів, оскільки режими ефективності зникають, коли не обробляються нитки обробки даних (наприклад, коли я просто читаю файл).
додано Автор nomad, джерело
Різниця, яку я повідомила, полягає у багатьох зворотних трасах. Проте продуктивність чергується між "швидкими" та "повільними" режимами. Файл аналізується потоком читача, який заповнює паралельну чергу з подвійним закінченням, і дані потім витягуються з черги іншими потоками для обробки. Однак я не думаю, що це пов'язано з кешуванням файлів, оскільки режими ефективності зникають, коли не обробляються нитки обробки даних (наприклад, коли я просто читаю файл).
додано Автор nomad, джерело
@DanielKO - Програма звітує ~ 3920000 Невеликі розбіжності сторінок за пробіг (тут дисперсія крихітна) та 0 Основні несправності сторінки за пробіг. Кількість несправностей сторінки, здається, незалежно від того, чи отримую я "гарну" або "погану" продуктивність.
додано Автор nomad, джерело
Цікаво, що я бачу дуже подібний профіль продуктивності, якщо я видаляю фактичні записи атома з коду; тому програма просто читає у файлі та виконує певну обробку на підсловах (наприклад, обчислює хеш-функцію). Дуже дивно.
додано Автор nomad, джерело
Хоча у мене немає привілеїв адміністратора, я на машині "єдиний" (принаймні, коли я виконував попередній профіль). Інші користувачі, які мають доступ до машини, є членами нашої досить малої дослідницької групи, тому, якщо мені потрібен деякий час, щоб провести аналіз продуктивності, я можу попросити їх самостійно використовувати машину на деякий час. Той факт, що це трапляється, коли я один на машині, припускає, що, можливо, відбувається переривчастий системний процес, який викликає переривання, але я не знаю, як перевірити напевно.
додано Автор nomad, джерело
Хоча у мене немає привілеїв адміністратора, я на машині "єдиний" (принаймні, коли я виконував попередній профіль). Інші користувачі, які мають доступ до машини, є членами нашої досить малої дослідницької групи, тому, якщо мені потрібен деякий час, щоб провести аналіз продуктивності, я можу попросити їх самостійно використовувати машину на деякий час. Той факт, що це трапляється, коли я один на машині, припускає, що, можливо, відбувається переривчастий системний процес, який викликає переривання, але я не знаю, як перевірити напевно.
додано Автор nomad, джерело
Хоча у мене немає привілеїв адміністратора, я на машині "єдиний" (принаймні, коли я виконував попередній профіль). Інші користувачі, які мають доступ до машини, є членами нашої досить малої дослідницької групи, тому, якщо мені потрібен деякий час, щоб провести аналіз продуктивності, я можу попросити їх самостійно використовувати машину на деякий час. Той факт, що це трапляється, коли я один на машині, припускає, що, можливо, відбувається переривчастий системний процес, який викликає переривання, але я не знаю, як перевірити напевно.
додано Автор nomad, джерело
Під "небажаними контекстними перемикачами" я маю на увазі те, що, відповідно до ОС, це не результат обробки, який дає або чекає, а скоріше результат ОС, який насильно перекриває мій процес з якихось інших цілей.
додано Автор nomad, джерело
Під "небажаними контекстними перемикачами" я маю на увазі те, що, відповідно до ОС, це не результат обробки, який дає або чекає, а скоріше результат ОС, який насильно перекриває мій процес з якихось інших цілей.
додано Автор nomad, джерело
Під "небажаними контекстними перемикачами" я маю на увазі те, що, відповідно до ОС, це не результат обробки, який дає або чекає, а скоріше результат ОС, який насильно перекриває мій процес з якихось інших цілей.
додано Автор nomad, джерело
@DanielKO - Утиліта time фактично розбиває контекстні перемикачі за добровільним/небажаним. Визначення небажаного контексту перемикає тут, коли ваш процес попереджає ОС з якихось інших причин, крім того, що він добровільно відмовляється від керування (наприклад, прибутковість/очікування). Це може статися, коли закінчується його часовий інтервал, і існує більш пріоритетний процес для запуску, і, мабуть, в ряді інших умов.
додано Автор nomad, джерело
@DanielKO - Утиліта time фактично розбиває контекстні перемикачі за добровільним/небажаним. Визначення небажаного контексту перемикає тут, коли ваш процес попереджає ОС з якихось інших причин, крім того, що він добровільно відмовляється від керування (наприклад, прибутковість/очікування). Це може статися, коли закінчується його часовий інтервал, і існує більш пріоритетний процес для запуску, і, мабуть, в ряді інших умов.
додано Автор nomad, джерело
@DanielKO - Утиліта time фактично розбиває контекстні перемикачі за добровільним/небажаним. Визначення небажаного контексту перемикає тут, коли ваш процес попереджає ОС з якихось інших причин, крім того, що він добровільно відмовляється від керування (наприклад, прибутковість/очікування). Це може статися, коли закінчується його часовий інтервал, і існує більш пріоритетний процес для запуску, і, мабуть, в ряді інших умов.
додано Автор nomad, джерело
@DanielKO - програма не виділяє пам'ять динамічно, але виділяє фіксовану кількість пам'яті передньою. Він читається у файлі з диска та підраховує кількість випадків фіксованих підслово, які відбуваються у файлі, тому існує значне введення/виведення. Тим не менш, я протестував частину вводу-виводу програми окремо, і це не є вузьким місцем (я можу читати більше підслова, ніж я можу обробити). Крім того, продуктивність виглядає рівномірною, коли я просто виконую введення/виведення (тобто я не бачу великої кількості небажаних контекстних перемикачів, що призводить до зниження продуктивності).
додано Автор nomad, джерело
@DanielKO - програма не виділяє пам'ять динамічно, але виділяє фіксовану кількість пам'яті передньою. Він читається у файлі з диска та підраховує кількість випадків фіксованих підслово, які відбуваються у файлі, тому існує значне введення/виведення. Тим не менш, я протестував частину вводу-виводу програми окремо, і це не є вузьким місцем (я можу читати більше підслова, ніж я можу обробити). Крім того, продуктивність виглядає рівномірною, коли я просто виконую введення/виведення (тобто я не бачу великої кількості небажаних контекстних перемикачів, що призводить до зниження продуктивності).
додано Автор nomad, джерело
@TonyD - Yea; Я спостерігав за "вершиною" під час роботи програми, і не дивно, що це не схоже на те, що у системі все ще багато чого іншого; в основному просто на рівні системи (і т.д. dbus-daemon, graceptor (працює ROCKS кластер програмне забезпечення) та деякі інші різні низького навантаження речі).
додано Автор nomad, джерело
@TonyD - Yea; Я спостерігав за "вершиною" під час роботи програми, і не дивно, що це не схоже на те, що у системі все ще багато чого іншого; в основному просто на рівні системи (і т.д. dbus-daemon, graceptor (працює ROCKS кластер програмне забезпечення) та деякі інші різні низького навантаження речі).
додано Автор nomad, джерело
@DanielKO - Програма звітує ~ 3920000 Невеликі розбіжності сторінок за пробіг (тут дисперсія крихітна) та 0 Основні несправності сторінки за пробіг. Кількість несправностей сторінки, здається, незалежно від того, чи отримую я "гарну" або "погану" продуктивність.
додано Автор nomad, джерело
@DanielKO - Програма звітує ~ 3920000 Невеликі розбіжності сторінок за пробіг (тут дисперсія крихітна) та 0 Основні несправності сторінки за пробіг. Кількість несправностей сторінки, здається, незалежно від того, чи отримую я "гарну" або "погану" продуктивність.
додано Автор nomad, джерело
@ DanielKO - Насправді, так, я роблю атомні операції. Розрахунок підслово зберігається у великій масі цілих атомних чисел (std :: atomic ). Я не розумію, чому це може призвести до проблеми продуктивності іноді, але не до інших. Процес продуктивності насправді дивний в тому, що існують два "режими"; швидкий і повільний, і кожне виконання програми потрапляє до одного з них (тобто він ніколи не виконується на рівні між швидким і повільним виконанням). Чи є спосіб глибше розкопатись в атоміках, щоб побачити, чи вони викликають проблему?
додано Автор nomad, джерело
@ DanielKO - Насправді, так, я роблю атомні операції. Розрахунок підслово зберігається у великій масі цілих атомних чисел (std :: atomic ). Я не розумію, чому це може призвести до проблеми продуктивності іноді, але не до інших. Процес продуктивності насправді дивний в тому, що існують два "режими"; швидкий і повільний, і кожне виконання програми потрапляє до одного з них (тобто він ніколи не виконується на рівні між швидким і повільним виконанням). Чи є спосіб глибше розкопатись в атоміках, щоб побачити, чи вони викликають проблему?
додано Автор nomad, джерело
@ DanielKO - Насправді, так, я роблю атомні операції. Розрахунок підслово зберігається у великій масі цілих атомних чисел (std :: atomic ). Я не розумію, чому це може призвести до проблеми продуктивності іноді, але не до інших. Процес продуктивності насправді дивний в тому, що існують два "режими"; швидкий і повільний, і кожне виконання програми потрапляє до одного з них (тобто він ніколи не виконується на рівні між швидким і повільним виконанням). Чи є спосіб глибше розкопатись в атоміках, щоб побачити, чи вони викликають проблему?
додано Автор nomad, джерело
Цікаво, що я бачу дуже подібний профіль продуктивності, якщо я видаляю фактичні записи атома з коду; тому програма просто читає у файлі та виконує певну обробку на підсловах (наприклад, обчислює хеш-функцію). Дуже дивно.
додано Автор nomad, джерело

9 Відповіді

Ви згадали, що є 32 ядра, але якою точною макетом обладнання? Наприклад, скільки пакетів має машина, скільки ядер, як обмінюватися кешем тощо. Для обміну даної інформації я особисто хотів би поділитися виходом likwid-topology-g .

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

Для закріплення (ака спорідненості ) ви можете використовувати явні виклики Pthread або ви можете спробувати інший інструмент із комплекту Likwid, який називається licwid-pin - див. тут .

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

6
додано
Дякую за пропозицію. Я намагався встановити близькість моїх потоків безпосередньо за допомогою pthreads (і це працює), але я все ще бачу варіативність продуктивності. Це змушує мене вважати, що це питання, швидше за все, є результатом старого ядра/планувальника. Однак я не знав про ліквідові інструменти, і вони здаються дуже корисними. Крім того, я переконав адміністратора створити групу sudoers, щоб я міг насправді використовувати ці інструменти для профілювання. Я думаю, що пропозиція сама по собі може бути ціною щедрості.
додано Автор nomad, джерело
Варіанти відбуваються протягом досить великого шкали часу (наприклад, 120 до 200 секунд). Якщо це відбулося лише з дуже високою роздільною здатністю (наприклад, 5мс проти 9мс), я, напевно, не був би настільки стурбований і не був би впевнений, що це не просто помилка вимірювання.
додано Автор nomad, джерело
Дякую за щедрість! Цікаво, що спорідненість не покращила відтворюваність. Що я хотів би спробувати побачити далі (незважаючи на використання профілератора), чи залежить мінливість від часу роботи користувача чи часу ядра. Для цього має бути достатньо утиліт "час". Коли я глибше занурююсь у питання планування, я буду робити VTune з розширеними точками зі стеками (що збирає інформацію про контекстний перемикач) або можливості трасування трафіку ftrace. Одна важлива річ, яку я повинен був поцікавити, полягає в тому, як довго триває робоча навантаження. Ви сказали 80% мінливість - але це 5 секунд проти 9 секунд або 5 мс проти 9 мс?
додано Автор Alexey Alexandrov, джерело
120 або 200 секунд дійсно цікаво. Чи є у вас будь-яка залежність від пропускної здатності мережі у вашому робочому навантаженні? Це може йти настільки складно, як читати велику кількість даних з мережевого ресурсу. Залежно від завантаження мережі ви можете отримати різну швидкість. Але це не дасть вам двомодального результату. У всякому разі, коли ви знайдете кінцеву причину, було б дуже корисно знати, що це було - залиште нас опублікованим, якщо ви отримаєте шанс! :)
додано Автор Alexey Alexandrov, джерело

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

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

Linux не є системою реального часу. Він просто намагається бути максимально ефективним у середньому випадку.

Є кілька речей, які ви можете зробити, щоб мінімізувати дисперсію ефективності:

Зменшити кількість ниток до мінімуму, необхідного. Не розбивайте різні аспекти вашої проблеми на нитки. Просто поділіться на теми, коли це дійсно необхідно, наприклад, для подання процесорів з незалежними (!) Номерами хрускінгових завдань. Спробуйте зробити якомога більше причинно пов'язаних робіт в одному потоці, наскільки це можливо. Ви потоки повинні вимагати якнайменше спілкування один з одним, наскільки це можливо. Зокрема, у вас не повинно бути шаблонів запитів/відповідей між потоками, де затримки складаються.

Припустимо, що ваша ОС зможе робити лише близько 1000 контекстних перемикачів між потоками/процесами в секунду. Це означає, що пару по 100 запитів/відповідей у ​​секунду. Якщо ви робите тест на Linux, і ви вважаєте, що можете зробити набагато більше, ігноруйте це.

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

1
додано

Я вважаю, що ваша проблема насправді є проблемою планування.

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

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

There are out there profiling tools that allow you to register where your threads are being scheduled, such as perf for Linux. Usually these tools are particular to the topology where you're executing your program. Unfortunately none other comes to my mind right now. There are also ways of telling the OS to schedule threads on the same (or adyacent) CPUs, so they'll benefit from fewer cache misses. For that you can check this SO question

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

1
додано

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

Як змінюється продуктивність, коли ви збільшуєте вашу програму з 1 потік до 32 (і можливо після цього)?

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

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

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

Ось декілька статей, які можуть допомогти викликати ідею або дві.

http://halobates.de/lk09-scalability.pdf

http://pdos.csail.mit.edu/papers/linux:osdi10. pdf

Additional source: Why one non-voluntary context switch per second?

1
додано
Нарешті, ви завжди можете подати заявку на оновлення ядра. :-)
додано Автор Homer6, джерело
@nomad Я оновлюю це посилання, щоб знайти посилання на інструмент ftrace, який дасть вам додаткову інформацію про контекстні перемикачі.
додано Автор Homer6, джерело
Крім того, ці відео-лекції мають багато хороших інструментів і методів, які можуть бути корисними у вашому випадку: ocw.mit.edu/courses/electrical-engineering-and-computer-scie‌ nce/& hellip;
додано Автор Homer6, джерело
Дякую за посилання. Я думаю, ви маєте рацію, що я можу, дійсно, доведеться завершити перекомпіляцію старого ядра для іншої машини.
додано Автор nomad, джерело

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

Як змінюється продуктивність, коли ви збільшуєте вашу програму з 1 потік до 32 (і можливо після цього)?

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

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

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

Ось декілька статей, які можуть допомогти викликати ідею або дві.

http://halobates.de/lk09-scalability.pdf

http://pdos.csail.mit.edu/papers/linux:osdi10. pdf

Additional source: Why one non-voluntary context switch per second?

1
додано
Нарешті, ви завжди можете подати заявку на оновлення ядра. :-)
додано Автор Homer6, джерело
@nomad Я оновлюю це посилання, щоб знайти посилання на інструмент ftrace, який дасть вам додаткову інформацію про контекстні перемикачі.
додано Автор Homer6, джерело
Крім того, ці відео-лекції мають багато хороших інструментів і методів, які можуть бути корисними у вашому випадку: ocw.mit.edu/courses/electrical-engineering-and-computer-scie‌ nce/& hellip;
додано Автор Homer6, джерело
Дякую за посилання. Я думаю, ви маєте рацію, що я можу, дійсно, доведеться завершити перекомпіляцію старого ядра для іншої машини.
додано Автор nomad, джерело

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

0
додано

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

0
додано

У багатопотоковій програмі, додайте нитку до певного номера процесора і перевірте, чи ви бачите покращення продуктивності.

0
додано

У багатопотоковій програмі, додайте нитку до певного номера процесора і перевірте, чи ви бачите покращення продуктивності.

0
додано
IT KPI C/С++ новым годом
IT KPI C/С++ новым годом
747 учасників

Чат обсуждения С/С++. - Вопросы "напишите за меня лабу" - это оффтоп. - Оффтоп, флуд, оскорбления и вбросы здесь не приняты. - За нарушение - предупреждение или mute на неделю. - За спам и рекламу - ban. Все чаты IT KPI: https://t.me/itkpi/1147