Чому процеси пріоритетування пріоритетів не покращують швидкість?


18

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

Чому це? Чи відбувається більше, чи потрібно більше зробити?


6
Це як у реальному житті. Якщо ви маєте більш високий пріоритет для посадки в літаку, ніж інший пасажир, це не означає, що політ займе менше часу для вас!
Мехрдад

Відповіді:


28

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

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


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

4

Пріоритет - час процесора. Чи всі ядра 100% використовуються постійно? Якщо ні, то пріоритет не матиме ефекту. Досить часто процесор не є вузьким місцем, а це пам'ять, диск або ресурси GPU.


3

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

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

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

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

Перед Windows Vista пріоритет потоку не впливав на швидкість завершення операцій вводу / виводу. Оскільки Windows Vista, I / Os також може мати пріоритет, який за замовчуванням походить від пріоритету потоку.

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


0

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

Інші можливі проблеми:

  • Програма може бути неефективною / погано написаною
  • Це може бути уповільнено через "повільний" доступ до диска або повільну мережу

0

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

На противагу тому, що категорично зазначено у першому реченні прийнятої на даний момент відповіді ( /superuser//a/752587/322588 ), пріоритетні зміни є найбільш ефективними, коли процесор є вузьким місцем, як це пояснено у відповіді Майка Дімміка ( /superuser//a/752864/322588 ). Крім того, твердження у другому абзаці прийнятої відповіді, "якщо ваш процес вичерпує весь часовий відрізок, він розподіляється на фактичні обчислення, тоді планування не буде нічого там змінювати" є абсолютно помилковим, якщо процес зазвичай вже не має найвищого пріоритету з усіх запущені нитки, коли він чекає запуску. Це тому, що за будь-яких інших обставин підвищення пріоритету, швидше за все, отримає більше часових скорочень за інтервал настінного годинника.

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

Відмова: Я не знаю містера Дімміка, хоча можу сказати, що він знає, про що пише.


Можливо, ви неправильно зрозуміли; питання стосувалося швидших процесів . Процеси, пов'язані з процесором, вичерпають весь блок планування (квантовий), а потім перейдуть до черги готових процесів наприкінці. В настільній операційній системі, як Windows, це означає, що процес має шанси на 1 / квантовий Гц запускатися щосекунди. Зміна пріоритету (як правило) не змінює довжину його часових шрифтів. Завжди буде потрібно однакова кількість квантів планування. Головне , саме так Windows вимірює час виконання: кількість запланованих квантів.
Андон М. Коулман

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

Пріоритетність процесу, пов'язаного з очікуванням вводу / виводу, принципово відрізняється, і він може мати вимірний вплив на повідомлення про час роботи в Windows. Знову ж таки, Windows вимірює час виконання як кількість квантів, які закінчилися (навіть якщо процес витрачає 1 мс з 10 мс кванту, який фактично працює, а потім добровільно чекає, що залишиться 9 мс на введення / виведення, ядро ​​Windows вважає, що варто 10 мс часу виконання режиму користувача). Виплата може допомогти додаткам, пов'язаним вводу / виводу, отримати менше квантів для завершення. Інші ядра (наприклад, Linux) можуть правильно вимірювати часткові кванти під час виконання процесу, але Windows не може.
Андон М. Коулман

@ AndonM.Coleman Від Vista та пізніших версій, так, це може і робити.
Джеймі Ханрахан

@JamieHanrahan: Ну, ви завжди можете зателефонувати timeBeginPeriod (...), що вже робить інтерактивне. Гра зазвичай встановлює це значення 1, коли вона починається, і це застосовує інтервал планування 1 мс по всій дошці до всього, що працює в системі. Це не ізольовано лише від того процесу, який це зробив. Це є причиною того, що важко сприймати Windows серйозно для багатозадачності.
Андон М. Коулман
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.