https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html Линус Торвальдс предложил (https://lkml.org/lkml/2018/11/19/37) пересмотреть механизм активации патчей STIBP (Single Thread Indirect Branch Predictors), предлагающих дополнительную защиту от проявления уязвимостей класса Spectre v2. Данные патчи недавно были включены (https://lkml.org/lkml/2018/10/23/469) в находящуюся в разработке ветку 4.20 и бэкпортированы в стабильный выпуск 4.19.2. При применении STIBP в текущем виде пользователи отметили существенное снижение производительности выполнения некоторых приложений при применении технологии одновременной многопоточности (SMT или Hyper-Threading).<br><br><br>Так как падение производительности достигает 50%, по мнению Линуса, применение STIBP лишено смысла, так как проще и надёжнее вообще отключить SMT/Hyper-Threading, что обычно и делают люди, озабоченные безопасностью. Возникает вопрос, нужно ли включать STIBP по умолчанию, когда у тех, кому действительно важна безопасность, SMT/Hyper-Threading уже отключен. Для обычных пользователей потеря производительности в 50 https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#252 Thu, 22 Nov 2018 23:45:56 GMT &gt;то есть миссия успешно провалена. <br><br>Ну я бы так не сказал<br>Тео Де Раадт ведь пропиарился и денег собрал на ешё одну ненужную и дырявую библиотеку<br>А Вы что-то ещё хотели?<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#251 Thu, 22 Nov 2018 17:20:57 GMT В младшей 5505 геоды были )<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#250 Thu, 22 Nov 2018 15:19:11 GMT Он уже перешёл на AMD и Gentoo?<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#249 Thu, 22 Nov 2018 08:13:29 GMT да плевать вашей сиське на энергопотребление. ASR9900 в минимуме снабжена спаркой из двух блоков питания по два, что-ли, киловатта (а есть и по шесть). Где там вы процессор разглядите?<br><br>Циска "стала делать" управляющие процы x86 в 2005м году, только это было специфическое железо. Догадаетесь, нет? <br>Вряд ли, похоже не в теме вы, как и про питание. Это была ASA. А процессор в ней был соплерон (в самых старших - уже полноценный пентиум) - и сделано это было не ради эффективного энергопотребления, а потому что китаец, отвечавший за qnx (или что это там было в pix?) помер от старости, так и не сумев написать к ней драйвер usb-портов. Зато такой драйвер был в rhel, кастрированной и очищенной от лейбаков копией которой и был снабжен новый проект.<br><br>циске понравилось, новая технология начала продвигаться и в другие устройства. Но rh почему-то не хочет поддерживать мипсы. Похоже, помучавшись пяток лет с самостоятельной поддержкой, они все же решили что мейнстримная архитектура дается проще.<br><br>к тому же торговать https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#248 Thu, 22 Nov 2018 07:37:01 GMT Я предлагаю самому софту решать то за что сейчас отвечает ЦПУ. Поскольку софту виднее. Как минимум ему виднее какие участки кода и данные стоит спекулятивно выполнять и подгружать, а какие нет.<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#247 Thu, 22 Nov 2018 07:15:37 GMT Всё, сдаюсь. :)<br><br>Осталась самая малость до наступления светлого будущего &#8212; научиться правильно использовать кольца защиты.<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#246 Thu, 22 Nov 2018 06:59:07 GMT Вот гонево про "худшую". На практике самой производительной архитектурой оказалась как раз переусложнённая x86. ARM, MIPS и прочее в общих задачах прососало по производительности настолько, что в персональном/промышленном применении их никто всерьёз не рассматривает. ARM нашёл себе нишу в смартфонах и прочей эмбедовке, где Performance-Per-Watt важнее пиковой производительности, MIPS остался управлялкой в другого рода эмбедовке, вытеснив POWER, и конкурируя с ARM. Но самое-то весёлое, что x86 удалось оптимизировать и по энергопотреблению - и в итоге та же циска свои управляющие процы стала делать на x86. То есть, и ARM/MIPS вскоре в своих нишах придётся не сладко.<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#245 Thu, 22 Nov 2018 06:53:00 GMT В отличие от компилятора, CPU оперирует _законченным_ набором: код + входные данные, поэтому может делать определённые оптимизации, которые компилятору недоступны. Другое дело, что очень часто разрыв между данными и выполнением настолько мал, что, чем дожидаться окончания обработки этих данных, быстрее параллельно заранее обработать обе ветки перехода например, а потом один из результатов выкинуть.<br> https://mobile.opennet.dev/openforum/vsluhforumID3/115859.html#244 Thu, 22 Nov 2018 06:50:10 GMT VLIW - вообще не взлетел, и уже точно не взлетит. Проблема всё в том же, о чём я говорил выше. Компилятор генерит +/- универсальный код, но в зависимости от конкретных ветвлений (а конкретные ветвления зависят от входных данных) он внезапно оказывается либо оптимальным, либо нет.<br>