Тут ещё уязвимостей в штеудах подвезли...

Выпустили патчи к ядрам: 5.18.5, 5.15.48, 5.10.123, 5.4.199, 4.19.248, 4.14.284 и 4.9.319.

А есть где статистика сколько десятков патчей и мегабайтов кода в ядре добавили исключительно для того что-бы залатать аппаратные дыры штеуда? И ещё сколько тысяч тактов эти патчи жрут в секунду при константной частоте в 1Ггц?

Интересно узнать на сколько просело в этот раз, несите тест в студию.

Давайте уже прямо: архитектура CISC, как и архитектура RISC при использовании спекулятивного выполнения — нелатаемое говно в плане безопасности.

Единственный нормальный выход — переезд на VLIW. Что интересно, изначально так и планировалось с Itanium, но рынок выбрал жрать дерьмо. Как обычно.

как они влияют на производительность? Не знаешь, случаем?

Но гораздо интереснее, как теперь еще и это отрубить.

mitigations=off и на это тоже действует?

изначально так и планировалось с Itanium

Ну как-бы даже у интела с HP не хватило деньжищ, опыта и влияния его на плаву оставить. Уж во что там упёрлось, в невозможность родить столь умный компилятор или в особенности влива в принципе, не суть важно. Пихали-пихали, и опенсорс на серверах уже был в полный рост - не получилось, что-то там работает до сих пор в «спецприменениях» и всё.

Сейчас у нас долбаются с эльбрусом, допиливая стандартный софт на низком уровне руками - может всё-таки с вливом что-то не то для CPU общего назначения?

С микротиками на VLIW накушался лично. Где надо лопатить трафик тупо - всё прекрасно. Как только надо на одном ядре маршруты пересчитать - (вырезано цензурой). Причём настолько (вырезано цензурой), что новой версии ОС под VLIW не будет, а новые операторские железки латыши стали делать на довольно хилом арме.

VLIW выглядит интересно, кто б спорил, но что-то всё не задаётся за пределами DSP.

mitigations=off и на это тоже действует?

вроде бы как действует, mmio_stale_data https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kerne...

Спасибо за информацию. Радует. Там документ позавчера правлен, если что.

i5 после заплаток стал i3 или ещё нет?

пофиг на i5, главное что бы i7 стал не хуже i3 :)

вот задезайни эксперимент и проверь

главное что бы i7 стал не хуже i3

Какой-нибудь i7-2700K (и даже i7-4790K) стал явно хуже i3-12300, i3-10, хуже i3-10325 и даже хуже i3-10105.

https://www.cpubenchmark.net/compare/Intel-i7-2700K-vs-Intel-i3-12300-vs-Intel-i3-10325-vs-Intel-i3-10105-vs-Intel-i7-4790K/881vs4746vs4685vs4259vs2275

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

Я знаю. На смайлы обращайте внимание. :)

Что интересно, изначально так и планировалось с Itanium, но рынок выбрал жрать дерьмо.

Что, рынок таки перешел на Itanium?

Уж во что там упёрлось, в невозможность родить столь умный компилятор или в особенности влива в принципе, не суть важно.

В желание распространять софт в виде проприетарных блобов и неумение писать кроссплатформу.

о а сколько еще дырок известных которыми пользуются и не закрывают

С микротиками на VLIW

А что там за проц был с VLIW, если не секрет?

Что-то из Tilera TILE-Gx

4.4 и 3.16 всё?

А почему Интелы не исправят Meltdown аппаратно? Уже 4 года прошло

Глянул Википедию:

Technology node 40nm to 40nm
Microarchitecture VLIW RISC

Я правильно понимаю, что система команд там была своя собственная ни с чем несовместимая? Ну почти как Эльбрус тот же. :)

ага, не отстали на уровне дсп

Какой-нибудь i7-2700K (и даже i7-4790K) стал явно хуже i3-12300, i3-10, хуже i3-10325 и даже хуже i3-10105.

Кванотовомеханический предел в производительности достигли, теперь потребитель будет покупать новые процы с меньшим количеством дыр. Разумеется, со временем всё больше дыр «появляется».