Компания Intel представила дискретную графику

Ну и зачем ты тогда ныл про уязвимости?

Мельдоний просто в копилочку; Мы хейтили штеуды за годы до его обнародования. Ах да, и за оверпрайс ещё.

через дыру в браузере взламывали

Так а JS тут при чём? Он не предоставляет средств для этого, уязвимость в нативном коде.

Если твоя любая ос не поддерживает efi/smt, то такая ос не нужна

Не-а, это EFI ваши не нужны. У Нас его до сих пор ни в одной ЭВМ нет ;)

есть виртуалки

Эмуляция железа не всегда приемлема. Как минимум из-за того, что сначала оно перехватывается хостовой ОС.

на каких, с примерами?

Вам с какого места начинать?

root@localhost:~# dpkg -l|wc -l
5895

Это ещё не считая того многообразия, что мимо ПМ стоит.

Такое давно не производят

И что? Старое-то работает. С тракторами ещё хуже, американцы некрофилируют тракторы родом из 80-х ещё, потому что более новые — сплошное вендорлокнутое неремонтируемое говно, «спасибо» копроэкономике.

полтора хипсторка-сойбоя

Хипсторки как раз не занимаются таким.

хейтили

Хейт не тянет на аргумент. Оверпрайса практически не было, было отсутствие конкуренции со стороны амд.

У Нас

Твой старый хлам тоже не нужен.

Эмуляция железа не всегда приемлема

Примеры будут?

Вам с какого места начинать?

Начинай с любого.

Старое-то работает.

И что? Ты же гонишь на новое-то.

было отсутствие конкуренции со стороны амд

А зачем конкурировать с прожорливым ненужно?

Твой старый хлам тоже не нужен.

А что вместо него?

Примеры будут?

Да прошивка всяких железяк хотя бы.

Начинай с любого.

Срезы дают неполную картину; пробовали пару раз давать срезы — оппоненты начинали по кирпичикам их разбирать и съезжать с темы. А полный анализ того, что и зачем Мы за 7 лет запускали на этой машине — слишком трудоёмок ради срача на ЛОРе. Так что лучше воздержимся.

Ты же гонишь на новое-то

Ну так потому и гоним, что оно хуже старого. Тут как бы не получилось как с американскими тракторами, ибо звоночки того, что PC как платформа катится в говно, всё отчётливее.

дискретную графику

Когда представят непрерывную, безразрывную графику?

прожорливым

Амд как раз и было прожорливым(относительно производительности) ненужно в период между k8 и ryzen.

Так что лучше воздержимся

Выходит, реальных примеров у тебя нет. Ты выдаёшь за аргумент свои фантазии уровня «что-то там, может быть, наверное».

хуже старого

Не знаю-не знаю, производительность отвратительная у старого хлама. Я бы только за доплату таким пользовался.

относительно производительности

Так мельдоний-то наглядно продемонстрировал, что производительность у штеудов поддельная и дутая. А впрочем, у амуде немногим лучше, то ли дело Z80 ;)

Выходит, реальных примеров у тебя нет

Примеров чего. грузящих CPU на полную катушку программ? Тут уж с примерами попроще: ffmpeg, любой компилятор, жирнобраузеры (Vivaldi, LuaKit, Thunderbird, Chromium, Firefox).

производительность отвратительная у старого хлама

Ну да, а надо как на лопатах? — куча ядер, куча рамы (уже нищедесктопы обогнали!), а девать всё это некуда, потому что анально огорожено и запускать толком нечего, кроме потрешлюхских игрулек и кастрированных недобраузеров, в которых даже девтулзов нету. Пека туда же катится.

поддельная

Митигации снижают только производительность системных вызовов. +Выше ты там рассказывал, что «безопасность не нужна».

ffmpeg, любой компилятор, жирнобраузеры

Не просаживаются в производительности от митигаций. Ну ладно, в определённом бенчмарке браузер может на 5% просел. Для сравнения, фуфыкс сам по себе там же медленнее на 250%+.

как на лопатах

Не верю, что рабочие станции и сервера куда-то денутся.

Надеюсь, там используются стандартные протоколы а не intel-only проприетарщина как в случае с AX201

Митигации снижают только производительность системных вызовов

Упаковка/распаковка zram не на уровне ядра производится, что ли? Или, например, засылка пакетов в сетевые интерфейсы?

Не верю, что рабочие станции и сервера куда-то денутся.

Деться-то, конечно, не денутся, только превратятся в планшеты на ножках, планшеты с клавиатурой и планшеты в стойке — толку? Смысл PC-то в архитектуре, её и в мобильниках неплохо иметь (и даже было пару таких вундервафель), вместо того огороженного треша, что там творится.

Упаковка/распаковка zram

Тут абсолютно подавляющую часть времени занимает собственно упаковка/распаковка, а не жалкое переключение контекста.

засылка пакетов в сетевые интерфейсы

Ну вот это конечно замедлилось. Но это опять же заметят только на сервере занимающемся перекидыванием байтов 100500 клиентам и не выполняющем особо много вычислений.

превратятся … вместо того огороженного треша

За счёт чего?

Тут абсолютно подавляющую часть времени занимает собственно упаковка/распаковка, а не жалкое переключение контекста

Так переключений контекста-то дохрена будет.

root@localhost:~# ps aux|wc -l
273

Но это опять же заметят только на сервере занимающемся перекидыванием байтов 100500 клиентам

Ну-ну, скорости сетевых интерфейсов уже к частоте ядра подбираются ;) Они-то быстрее прогрессируют.

За счёт чего?

Винда наглядно демонстрирует, за счёт чего. Ибо куда катится винда — туда катится и ПК. Сначала лёгкие ненавязчивые DEP и UAC, потом к системным файлам не пущает даже справами админа, потом SecureBoot (пока не везде, но это вопрос времени) — вы находитесь здесь.

Что дальше? — а ничего хорошего, стоит ожидать, например, принудительной авторизации по роже или отпечатку пальца (это ещё спермёрка умела, но сугубо опционально) с залочкой всего железа при фэйле; ещё больше проприетарных самодостаточных железяк, общающихся друг с другом по анально огороженным протоколам; ещё менее модульное и посему вместе дохнущее железо: в ноутах современных уже поубирали мосты и гальванические развязки, теперь запросто можно через USB сжечь процессор нахрен.

ps aux

98% из этих процессов/потоков спят, на них никто не переключается. Активно жрущих проц потоков создают == количеству аппаратных потоков.

скорости сетевых интерфейсов

Как уже говорил, на десктопе оверхед не будет заметен всё равно, какая бы там скорость не была. Тут нужна активная работа 100500 подключений и 100500 процессов.

спят

И снова 4.2.

root@localhost:~# for i in `seq 1 5`; do ps -eo pcpu,rss,cmd|grep -v '^ 0\.0'|wc -l; sleep 1; done
46
46
46
46
47

оверхед не будет заметен всё равно, какая бы там скорость не была

Почему? А если на каждый байтик отдельный сисколл?

Ну и где 4.2? Ты нагрепал 5 штук, а 2% от твоих 273 это как раз 5.46, те анонимус точен как боженька. Кроме того, ты обосрался - смотреть нужно ps -eo state.

Почему? А если на каждый байтик отдельный сисколл?

Такое считалось диким говнокодом ещё до уязвимостей. Такое допустимо только где производительность не важна. Иначе упихивают как можно больше в один вызов/избегают вызова используя vdso и прочее.

нагрепал 5 штук

Тупанул. Короче смотри ps -eo state.

А если точнее, ps -Teo state

Ты нагрепал 5 штук

WUT?? Однострочник прочесть не можете? 5 — это число замеров. Можно и один, в принципе:

root@localhost:~# ps -eo pcpu,rss,cmd|grep -v '^ 0\.0'|wc -l
48

смотреть нужно ps -eo state

Он же показывает состояние на момент замера, а не за секунду.

Такое считалось диким говнокодом ещё до уязвимостей

Пускай себе считается, но задачи разные бывают. Например, нужна минимальная задержка и буферизация байтиков в любом виде недопустима. Правда, в таких случаях обычно не линукс используют, а подключают FPGA напрямую в сетевой кабель ;)

И?

root@localhost:~# ps -eo state|sort|uniq -c
     52 I
      3 R
    198 S
      5 T
     14 Z
root@localhost:~# ps -Teo state|sort|uniq -c
     52 I
      4 R
    871 S
      5 T
     14 Z

3 R

4 R

Исполняются только эти.

Он же показывает состояние на момент замера, а не за секунду.

Именно. Он показывает, сколько исполняется одновременно. Не исполняющиеся одновременно потоки друг другу не мешают.

но задачи разные бывают

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

сколько исполняется одновременно

В конкретный промежуток времени. После чего процессор займут другие, по таймеру или прочему событию.

И обычно ещё куча процессов в состоянии D висит, тут перегрузки просто нет ;)

Ты просто придумываешь

Ну так и знали, что до этого дойдёт ;)

После

Именно. Т.е. никто друг другу не мешает.

в состоянии D

Эти тоже спящие.

до этого дойдёт

До этого у тебя дошло давно уже ж.

Т.е. никто друг другу не мешает

Схрена? Одновременно они по сути вытесняющей многозадачности мешать друг другу не могут, ибо во время одного кванта времени исполняется не более одного процесса на ядро. Мешают потому, что кванты слишком перемешиваются, происходит слишком много переключений контекста, слишком мало процессорного времени выдаётся процессу за крупный промежуток времени. Посему мерять сиюминутное состояние бессмысленно, надо мерять за этот самый крупный промежуток: пусть не секунду, но хотя бы пару десятков миллисекунд.

Эти тоже спящие.

Схрена, если они зависли на сисколлах? Ядро вполне может чего-то для них молотить.

До этого у тебя дошло давно уже ж.

Ну поэтому Мы и не любим встревать в срачи. Сбор пруфов занимает слишком много времени. Давеча срач про мастурбацию на Швабре развели, так несколько дней в научных статьях ковырялись, доказывающих, что мастурбация эквивалентна наркотикам. Какой Нам профит с этого, делать, что ли, нехрен?

Пару раз даже с ЛОРа самостоятельно выпиливались из-за того, что он отнимает слишком много времени, но с прокачанной учёткой не стоит этого делать, слишком уж она ценна возможностью читать удалённые треды.

мешать друг другу не могут

Мешают потому

Путаешься в показаниях.

Посему мерять сиюминутное

«Посему» тут где? Ты тут одно из другого не вывел.

Только процессы, находящиеся одновременно в состоянии R могут исполняться одновременно, следовательно бороться за ресурсы процессора, следовательно помешать друг другу. Ты тупой?

Схрена, если они зависли

По определению:

D uninterruptible sleep

может чего-то для них молотить

«Молочение» отображается состоянием R.

В игровых тестах Iris Xe MAX конкурирует с NVIDIA GeForce MX350, а в кодировании видео Intel обещает, что будет в два раза превосходить RTX 2080 SUPER NVENC от NVIDIA.

via емнип, несколько лет боролась боролась и за дрова и за саму проихводительность. и зачахла. а тут какой то индус... и сразу хочет забороть не самую слабую карточку
а вру. виа это процы...

а вру. виа это процы...

Графика (в каком-то смысле) тоже - некоторе время владели S3 Graphics и производили дискретные карточки, потом встраивали S3 Chrome в свои чипсеты. Якобы до сих пор делают чипсеты под свои процессоры с ядром Chrome.

Путаешься в показаниях

Нет. Вы не отличаете d/dt, где t→0 и где t>>0?

Только процессы, находящиеся одновременно в состоянии R могут исполняться одновременно

Тогда почему их больше, чем ядер? ;)

uninterruptible sleep

Ещё раз повторяем: спит при этом код процесса, ожидая завершения сисколла, а ядро при этом как раз усердно может чего-то молотить, чтобы сисколл завершить и поскорее процесс отпустить выполняться дальше.

«Молочение» отображается состоянием R

Не отображается, потому что этим занимаются процессы ядра типа планировщика I/O или вышеупомянутого компрессора zram, которые обслуживают сразу кучу юзерспейсных процессов. 12309 и тхрешинг так и возникают ;)

Тогда почему их больше, чем ядер?

Потому, что это немного разные вещи. R это «хотящие» выполняться одновременно процессы.

Ещё раз

Ещё раз, в документации ясно написано:

D uninterruptible sleep

Если что-то исполняется, оно отображается как:

R running or runnable

Не отображается

Ты опять обосрался:

$ time cat /dev/urandom >/dev/null 
^C

real	0m2.200s
user	0m0.000s
sys	0m2.199s # Убеждаемся, что код работает в ядре

$ ps -Teo state,pcpu,comm |grep ^R
R  113 cat #Опачки, как же так, никаких D
R  0.0 ps

Тогда почему их больше, чем ядер?

Потому что вытесняющая многозадачность. Именно эти процессы делят процессорное время между собой. Это же число в усреднённом варианте отображается в load average, если не знал. Т.е. если у тебя в LA число больше количества ядер, значит, твоей системе ядер не хватает и происходит конкуренция за них между процессами.

Не отображается … zram

Опять фейл:

ls -l /dev/zram0
brw-rw---- 1 root disk 253, 0 ... /dev/zram0

$ ps -Teo state,pcpu,comm |grep ^R
R  0.0 ps

$ cat /dev/nvme0n1 >/dev/zram0 &

$ ps -Teo state,pcpu,comm |grep ^R
R  5.7 kworker/u24:2+flush-253:0
R  0.0 ps

Альё, а где полноразмерная карта? Я то думал, а они то говорили.

R это «хотящие» выполняться одновременно процессы

Ещё раз: это при t→0, а не t>>0.

cat /dev/urandom

И откуда там D взяться? Ждать же нечего, urandom всегда доступен.

Это же число в усреднённом варианте отображается в load average

Тогда почему LA растёт и при увеличении количества процессов в состоянии D?

Т.е. если у тебя в LA число больше количества ядер, значит, твоей системе ядер не хватает и происходит конкуренция за них между процессами.

Нет, LA растёт так же и при перегрузке I/O при малой нагрузке на процессор. Посему он сам по себе малорепрезентативен, надо отдельно смотреть метрики скорости чтения/записи с носителей, распределения процессорного времени, частоты ядер.

это

Что «это»? Ты не знаешь, что слово «одновременно» значит, или что?

И откуда там D взяться

У меня к тебе как раз такой вопрос.

почему LA растёт и при увеличении количества процессов в состоянии D?

Так отображают потому, что если диск занят, софт использующий диск начнёт тормозить. Процессор тут не причём.

Вы вообще не то меряете. cat не делает один сисколл на весь файл и не ждёт его, он передаёт мелкими буферами. Ни cat, ни шелл не виснут из-за этого. Попробуйте dd с большим bs, например ;) (хотя тоже может не взлететь, сисколл имеет право вернуть меньше запрошенного).

Ты где в cat сисколы нашёл?

Ты не знаешь, что слово «одновременно» значит, или что?

А при чём здесь одновременность, когда речь шла о переключении контекстов? Набор ждущих его процессов постоянно меняется.

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

Процессор тут не причём

Зато ядро при чём. Чем выше нагрузка на I/O, тем больше работы планировщику: молотить большую очередь, следить за минимизацией фрагментации при записи, и т.д. А отсюда и паразитная нагрузка на процессор.

А через какую магию он с файловыми дескрипторами работает?

Любопытно, а теперь проверьте по strace, сколько там реально возвращается.

strace

read(0, "...", 104857600) = 104857600
write(1, "...", 104857600) = 104857600

при чём здесь одновременность

Ну так ты заявлял, что у тебя между 273 потоками переключаться будет. А на деле их активных 4 и переключаться практически не нужно.

А отсюда и паразитная нагрузка на процессор

Ну и? Выше в примерах её видно. Что сказать-то хотел?

А на деле их активных 4 и переключаться практически не нужно

В течение длительного промежутка времени — нужно будет. Просто процессы не толпятся, а просыпаются по очереди. Переключения контекста от этого никуда не деваются.

Выше в примерах её видно. Что сказать-то хотел?

Вы выше утверждали, что на реальных задачах патчи от мельдония существенной просадки производительности не дают, ибо не влияют на юзерспейс. И в ходе обсуждения обнаружилось, что таки дают, ибо не юзерспейсом единым ;)

не толпятся

Именно. В cpu-bound задачах оверхеда никто так и не намерял.

в ходе обсуждения обнаружилось, что таки дают

Покажи где, с процентами, на сколько замедлилось от патчей.

Дык бенчмарки на KPTI мы и не запускали, только переключения контекстов меряли ;) Точнее, именно сами переключения так и не измерили, а лишь устроили срач по поводу того, какой из косвенных способов лучше.

Крутая сейчас дискретная графика(в целом). Можно даже во вполне вменяемые игры играть. Еще 10 лет назад на дискретной графике 2д тормозило

А потом жри чего дают и беги пока трамваи ходят.

Жидов и без евреев полно.

Wayland как Бразилия - его ждёт большое будущее. И всегда будет ждать.

А почему вы спрашиваете? Ищете соратников-антисемитов?