Windows 11 випередила Linux у тестах продуктивності ШІ на ноутбуці з Intel Core Ultra 9 та GeForce RTX 5090

[Scoffer]

Ви потестуйте так, щоб наш продукт краще був. Інакше ми не дозволяємо публікувати результати

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

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

Вам навели факти, де Linux швидший і у створенні процесів, і у створенні потоків, робирайтеся з фактами

Особливо з врахуванням того що в лінуксі НЕМАЄ РІЗНИЦІ між процесом і потоком. RTFM
https://chessman7.substack.com/p/linux- ... d-creation
Лінукс не вміє в справжні процеси. Процеси в лінуксі це просто аліас потоку щоб загальнопосіксні проги хоч якось запустились. А зробити щось накшталт QoS для групи потоків, не перебираючи кожен окремо взятий, в отих ваших лінуксах це фік вам, не вміють вони.

Бо автор (як і будь-який досвідчений програміст) чудово розуміє різницю між fork() так CreateProcess()

Автор написав що не розуміє. Давай не вигадувати за автора.

через відсутність COW

Взагалі не при справах.

Відправлено через 15 хвилин 39 секунд:
І, повторюсь, така поведінка не характерна для юніксів як таких. Та ж макос знає різницю між потоком і процесом. Тому вона може відправити якусь прогу в сплячий режим з мінімальними ресурсами з геть всіма її потоками, хоч 100500 їх буде. А ядро лінукса без сторонньої допомоги на таке не здатне. Тому в відроїді довелось цим напрягати рантайм зі своїм власним планувальником, а не запускати нативний код.

[dext]

Особливо з врахуванням того що в лінуксі НЕМАЄ РІЗНИЦІ між процесом і потоком. RTFM

Різниця (кратна) є і вона доведена, фактично, в бенчмарках. З іншого боку: що доводить ваші твердження? Ніщо

Автор написав що не розуміє.

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

Взагалі не при справах.

Взагалі при справах, якщо це стосується економії як CPU, так і RAM, особливо RAM, -- ви взагалі розумієте, що значить COW?

[Scoffer]

що доводить ваші твердження

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

Він і не повинен розуміти нутрощі

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

Взагалі при справах, якщо це стосується економії як CPU, так і RAM, особливо RAM, -- ви взагалі розумієте, що значить COW?

А ти розумієш?) Ти розумієш що спавну взагалі не потрібна пам'ять батьківсього процесу ні на наносекунду, тому копіювати нічого і ні за чим, на відміну від форку, де у тебе немає варіантів і тому довелось приліпити такий костиль як COW щоб не було болісно повільно як в ранніх юніксах?) А якщо процесам знадобиться шарена пам'ять, то шарь собі на здоров'я скільки влізе. І саме те що потрібно, а не спочатку скопіювати все, а потім в паніці закривати 100500 дискрипторів батьківського процесу.

Відправлено через 9 хвилин 45 секунд:
Мені завжди подобались ці тести: клони пустого процесу штампуються швидко. Швидко, ага. А тепер зробіть форк-екзек з якоїсь жирної проги з відкритими тищами дискрипторів, хромику там якогось чи типу того, і побачимо що трапиться

[dext]

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

Це все пусті балачки на рівні "я так вважаю". Наведіть бенчмарки, які доводять, що потоки в Linux є важчими за Windows, бо всі наявні факти останні 20+ років говорять виключно про зворотнє

Повинен

Дурина. Розробник user-space повинен знати специфікацію user-space API, він не повинен знати реалізацію, це базовий принцип інкапсуляції і розробки взагалі. Якщо вона (реалізація) повільніша або не відповідає специфікації - це проблема розробників ОС (Windows у даному випадку)

Ти розумієш що спавну

Немає ані у Windows, ані у Linux такої сутності

[Scoffer]

Це все пусті балачки

Літери перечитай всі що я вище написав. Багато раз. Мінімум 10.

Дурина.

А потім калькулятор жере по гігабайту і вкладає на лопатки стоядерний проц Розробник ПОВИНЕН знати архітектурні особливості якщо його хоч трішки цікавить ефективність роботи. Або використовувати рантайми, котрі приховують ці особливості. Наприклад JVM приховує, тому розробник на жабі може не знати нічого про ОС. У розробника на плюсах немає такого привілею.

Немає ані у Windows, ані у Linux такої сутності

Добре що ні вінда, ні лінукс не знають що у них немає такої сутності
https://grokipedia.com/page/Spawn_(computing)

[Mozdev]

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

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

[dext]

Літери перечитай всі що я вище написав. Багато раз. Мінімум 10.

Я навів факти/бенчмарки, ви - нічого

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

Яким чином це доводить "легкість" потоків у Windows? Не треба демагогії, тим більше що ці проблеми характерні саме для Windows

Розробник ПОВИНЕН знати архітектурні особливості якщо його хоч трішки цікавить ефективність роботи. Або використовувати рантайми, котрі приховують ці особливості. Наприклад JVM приховує, тому розробник на жабі може не знати нічого про ОС. У розробника на плюсах немає такого привілею.

Щодо калькулятору: не треба писати на JS, пишіть на Native API, що знову ж таки - жодним чином не доводить "легкість" потоків у Windows, бо від розробника user-space це не залежить, бо що потоки, що процеси є повільнішими у Windows, що є доведеним фактом

Добре що ні вінда, ні лінукс не знають що у них немає такої сутності
https://grokipedia.com/page/Spawn_(computing)

По-перше, це посилання на нейрослоп, що відрізняє інженерів від інженегрів
По-друге, нейрослоп від фашиста
По-третє, що каже цей "fuct-checked" нейрослоп про кетаміному залежність цього фашиста?

[Scoffer]

Я навів факти/бенчмарки, ви - нічого

Ти навів бредові бенчмарки, і я пояснив чому саме вони бредові: створення клону пустого процесу це максимально далеке від реальності завдання. Нікому не треба сто тисяч пустих процесів. Наведи приклад з реальності, де створюються і конфігуруються потоки з багатьма параметрами і багатьма відкритими файлами.
А, точно, не роблять таких прикладів, а то незручно якось виходить.

бо від розробника user-space це не залежить

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

це посилання на нейрослоп

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

[konb999]

Предлагаю обсудить Windows 11 випередила Linux у тестах продуктивності ШІ на ноутбуці з Intel Core Ultra 9 та GeForce RTX 5090

Кто целевая аудитория этой новости...

Ты! Раз отписался!

[SergiusTheBest]

Лінукс не вміє в справжні процеси. Процеси в лінуксі це просто аліас потоку щоб загальнопосіксні проги хоч якось запустились.

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

[1234waltz]

Лінукс не вміє в справжні процеси. Процеси в лінуксі це просто аліас потоку щоб загальнопосіксні проги хоч якось запустились.

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

У Linux немає для цього окремого концепту, от не існує його.
Те що у Лінуксі є Lightweight Processes, не означає що він є таким технічно. Бо планувальник не розрізняє потоки та процеси, це просто флаг для роботи з пам'ятю (ізоляція чи спільна) і усе.
Якщо в системі створюється 2 всевдо-процеси та в одному буде одни псевдо-потік, а в іншому вісім псевдо-потоків, то для планувальника це 10 тасок, на які процесорний час розбивається в рівній пропорції.
У Шиндоушс в той самий час можно створити два процеси, між якими планувальник розіб'є порівну час процесорний, а в самих процесах будуть справжні потоки ділити ці 50%. В результаті 2 справдніх потоки в одному справжньому процесі у Шиндоус зіжруть 50% процесорного часу, як і планувалось. А 8 потоків в іншому процесі будут нарізати між собою залишок з других 50% процесорного часу.
Це концептуально різні речі. Тому так, Лінуксовий планувальник не вміє в у справжні процеси та потоки, архітектурно не вміє. В Лінукс є тільки таски та флаги як костиль.

Відправлено через 10 хвилин 3 секунди:
І саме тому в сучасному мобільному, десктопному та серверному лінуксі cgroups костиляють до systemd у якості костиля, бо інакше пару умовних контейнерів все раком ставили. В Андройді його ще актівіті менеджери додаткові докостиляли (і все одно воно гірше ніж у Яблока, бо коли костиль підпирають костилем, воно не буде працювати гарно, як правильно розроблена система).

[dext]

Ти навів бредові бенчмарки, і я пояснив чому саме вони бредові: створення клону пустого процесу це максимально далеке від реальності завдання. Нікому не треба сто тисяч пустих процесів. Наведи приклад з реальності, де створюються і конфігуруються потоки з багатьма параметрами і багатьма відкритими файлами.
А, точно, не роблять таких прикладів, а то незручно якось виходить.

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

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

Покажіть такого розробника (окрім себе), який не розуміє різниці між exec/fork та pthread в лінуксі

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

Це жаргон, а не технічний термін/специфікація. Загальноприйнятними є терміни "створення процессу" та "створення потоку", і відповідні сутності (процес, поток).

Посилатися за мертві/екзотичні ОС не треба - вони та то й мертві/екзотичні

[Scoffer]

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

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

dext
Мені набридло пояснювати одне і те саме. Не хочеш читати літери - твої проблеми.

[1234waltz]

спойлер

Лінуксойди так упоролись з псевдо-термінологію лінукс-мірка, що навіть не в курсі, що у freeBSD, macOS (як і у NT) також справжні потоки та процеси, а не сліпий планувальник з тасками, до якого наробили костилі з флагами та купою абстракцій верхнього рівня, які доводиться прибивати гвоздями до системного менеджера ініціалізації Systemd, який взагалі робили щоб позбутись баш портянок

[Scoffer]

1234waltz
До речі в OS/2 була надсутність над процесами - сессія. Ще один контейнер. Тому в OS/2 хоч скільки процесів не породи і як раком сервер не постав, можна було залогінитись в окрему сессію і все виправити. Бо ІВМ робило, ІВМ шось таки шарить в ОС.

Відправлено через 2 хвилини 6 секунд:
I QoS для юзверя нарізати можна було зручно.

[dext]

Мені набридло пояснювати одне і те саме. Не хочеш читати літери - твої проблеми.

Вас не просять пояснювати, вас просять надати фактичні цифри продуктивності, які доводять те, що ви говорите - з чого я і почав розмову, надавши цифри, в першу чергу.

Також покажіть розробника під Linux, який не розуміє різниці між fork та pthead.

Якщо ви є фанатом маска - можете попитати в його ШІ про різницю в швидкості між процесами та потоками в Linux, чи зробити це за вас? Відповідь вам не сподобається

[NVo1]

Заголовок:

Windows 11 випередила Linux у тестах продуктивності ШІ на ноутбуці з Intel Core Ultra 9 та GeForce RTX 5090

Текст новини:

Однак за підсумками всіх тестів перше місце за продуктивністю все одно посіла система CachyOS.

Кому вірити?
Чи автор не знає, що "CachyOS" - це і є лінукс?)

автору слід було зазначити те шо в кешіОС є русняві коріння, раз вже йде таке виділення окреме

[Scoffer]

фактичні цифри продуктивності

Те що до тебе не доходить що ти порівнюєш те що не треба порівнювати - не мої проблеми. Розробник на вінді не генерить 100500 процесів тому що це ідіотизм. Розробник на вінді генерить 1-2-3 потоки згідно з приорітетами, котрі питають ОС скільки їм доступно вцпу і породжують в такій кількості потоки, в котрих в свою чергу фіберами розрулюють стільки тасків, скільки треба. На виході вийде сіквел сервер, котрий працює супер швидко, як натурний приклад.
А твій лінупс так не вміє. Не вміє і все тут.
Ти намагаєшся приплести швидкість розгону до сотні для фури. Так от яка б вона не була, а фура все одно перевезе більше ніж спорткар в багажнику.

[1234waltz]

1234waltz
До речі в OS/2 була надсутність над процесами - сессія. Ще один контейнер. Тому в OS/2 хоч скільки процесів не породи і як раком сервер не постав, можна було залогінитись в окрему сессію і все виправити. Бо ІВМ робило, ІВМ шось таки шарить в ОС.

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

[Scoffer]

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

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