Windows 11 отримає режим Low Latency Profile для прискорення застосунків

[gast_]

Швидкість створення процесу

Треба не папугами міряти, а реальними задачами. Правильно он вище пишуть.

[Scoffer]

SergiusTheBest
Не кажучи вже про те що клонувати контекст в дочірній процес це не секьюрно ні разу. ОС VMS, з котрої потім благополочно злямзили архітектуру вінди, цілком усвідомлено відмовилась від форку якраз через безпекові ризики. А це, між іншим, сама надійна ОС в історії, котру так і не вдалось зламати кулхацкерам ні разу.

[SergiusTheBest]

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

На жаль, подібних бенчмарків зовсім мало. Знайшов дані по старту командланової утіліти на golang: Linux в 5-10 раз швидше запускає процес.

[kabostebeztak]

Оптимізовувати ОС і робити нативний код ніхто не хоче, я так бачу...

Відправлено через 1 хвилину 6 секунд:

писець хутровий звір дожились що відкриття меню Пуск і запуск пустого браузера стали настілкьи тяжкими завданнями заради яких портібно "розганяти" проц Щоб калькулятор відкрити теж проц потрібно буде розігнати

юзери лінукс і макос (я обидва) в шоці

[Scoffer]

командланової утіліти на golang: Linux в 5-10 раз швидше запускає процес

Один процес, так. Але це не має значення оскільки в вінді процес запускається разово, а далі потоки. Це потоково-орієнтовна ОС. Не процесо-орієнтовна. Якщо golang не вміє в потоки і генерить цілий процес на вінді, а таке іноді трапляється з портованими з лінуксу утилітами, то це називається ручки з дупці

[SergiusTheBest]

Один процес, так. Але це не має значення оскільки в вінді процес запускається разово, а далі потоки. Це потоково-орієнтовна ОС. Не процесо-орієнтовна. Якщо golang не вміє в потоки і генерить цілий процес на вінді, а таке іноді трапляється з портованими з лінуксу утилітами, то це називається ручки з дупці

З консолі запускаєш утіліту - тут без нового процесу не обійтися. Знайшов ще дані по часу старту PostrgeSQL та MySQL: також в 5-10 раз швидше на користь Linux. Ніяким Low Latency Profile це не виправити.

[Scoffer]

Ніяким Low Latency Profile це не виправити.

Це не потрібно виправляти. Що ти врипився в той запуск процесу. Він відбувається один раз на вінді. Це на ніксах його треба генерити постійно. Інша модель багатопоточності.
До того ж постгре з мускулом це якраз приклади погано портованих прог. Якщо взяти мс сіквел сервер, то він зараз топ1 по продуктивності на ядро/сокет серед реляційних бд взагалі, випереджаючи навіть оракл. Оракл з його ціною досі не скопитився тільки тому що RAC, але це вже зовсім інша історія, котра не стосується поточного обговорення. Вінда чомусь не завадила забезпечити топову продуктивність цієї беззаперечно багатопоточної проги.

[SergiusTheBest]

Це не потрібно виправляти. Що ти врипився в той запуск процесу. Він відбувається один раз на вінді.

Про це ж і є новина: "Згідно з першими тестами, нова функція прискорює запуск Microsoft Edge та Outlook приблизно на 40%".

[Scoffer]

Про це ж і є новина

Ні, новина зовсім не про це, а про те що аутлук і едж переповнені гівнокодом. Ті сто мілісекунд що витратяться за запуск процесу в ОС ніяк не вплине на те що аутлук запускається по 10 секунд. А іноді по 30.

[Dancer]

Одного мене бісить, права кн. мишки на робочому столі і менюшка вилазить з затримкою в 1 сек. в віндовс 11?

[Alexsandr]

Одного мене бісить, права кн. мишки на робочому столі і менюшка вилазить з затримкою в 1 сек. в віндовс 11?

ну не секунда, але так, затримки у 11 куди не ткни.

[zaqik]

права кн. мишки на робочому столі і менюшка вилазить з затримкою

Блин, напомнило: не 11, не на столе, но по свёрнутому окну на панели задач - вылазит порой секунд по 10. Со времён 1607 так, и на разном железе

[Scoffer]

Fork у Linux/macOS через CoW працює вкрай ефективно

Швидкість створення процесу

З'явилось у мене трішки часу і натхнення почитати а шо ж там в отих ваших макосах. Так от в них все ні разу не так само як в лінуксі. ОсХ все ще створює процеси через fork() бо з корабля нікуди не дінешся, але використовувати fork() без exec() прямим текстом не рекомендується. Можливість залишена лише для збереження сертифікації як щирого юнікса, але реальні спроби з великою ймовірністю викличуть купу помилок. Тобто по суті в ОсХ створення процесу мало чим відрізняється від створення онного за допомогою posix_spawn(), котрий є нічим іншим як коцнутим клоном механізму вмс/вінди.
Йдемо далі, ОсХ на відміну від лінукса розпізнає різницю між процесами і потоками і в рамках одного процесу клепає потоки за допомогою pthreads. Саме pthreads, а не fork є головним механізмом паралельного виконання в макосі.
А ще вони поверх pthreads навернули QoS з назвою libdispatch і програмулини мають працювати саме з ним, а не з pthreads, і тим паче не з fork, але то вже більш високорівневі абстракції. Хоча й цікаві.

спойлер

[SergiusTheBest]

З'явилось у мене трішки часу і натхнення почитати а шо ж там в отих ваших макосах. Так от в них все ні разу не так само як в лінуксі. ОсХ все ще створює процеси через fork() бо з корабля нікуди не дінешся, але використовувати fork() без exec() прямим текстом не рекомендується. Можливість залишена лише для збереження сертифікації як щирого юнікса, але реальні спроби з великою ймовірністю викличуть купу помилок. Тобто по суті в ОсХ створення процесу мало чим відрізняється від створення онного за допомогою posix_spawn(), котрий є нічим іншим як коцнутим клоном механізму вмс/вінди.
Йдемо далі, ОсХ на відміну від лінукса розпізнає різницю між процесами і потоками і в рамках одного процесу клепає потоки за допомогою pthreads. Саме pthreads, а не fork є головним механізмом паралельного виконання в макосі.

По швидкості створення процесів macOS знаходиться посередині: не так повільно, як Windows, не так швидко, як Linux. Те саме і по роботі з файлами.

[Scoffer]

По швидкості створення процесів macOS знаходиться посередині: не так повільно, як Windows, не так швидко, як Linux. Те саме і по роботі з файлами.

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

[SergiusTheBest]

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

Можливо, я не правильно щось зрозумів. Але виконуються потоки, а не процеси. І так на всіх ОС.

[Scoffer]

Можливо, я не правильно щось зрозумів. Але виконуються потоки, а не процеси. І так на всіх ОС.

В лінуксі потік=процес. Мапінг 1 до 1. При спробі зробити потік все одно буде сформований цілий процес. В не лінуксі потік≠процес, в тому числі в інших юніксах воно не дорівнює.
Відповідно планувальник лінукса знати не знає ні про які потоки всередині процесів і не оперує такими сутностями.

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