The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Компания AMD подтвердила потенциальную подверженность CPU AMD Zen 3 атаке Spectre-STL, opennews (??), 03-Апр-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


39. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от pda (ok), 03-Апр-21, 13:09 
По моему единственный выход тут - вводить теневые линии кэша, по аналогии с теневыми регистрами. Чтобы спекулятивно исполняемый код мог быть связан со спекулятивными линиями кэша.
Ответить | Правка | Наверх | Cообщить модератору

62. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от Урри (ok), 03-Апр-21, 16:27 
Ты готов за это платить?
Ответить | Правка | Наверх | Cообщить модератору

71. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +2 +/
Сообщение от Аноним (-), 03-Апр-21, 17:11 
А ничего что кэш занимает изрядно площади на кристалле? Вам как, ополовинить кэш за ваши бабки или чип подороже сделать за дополнительную цену? :)
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

89. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +1 +/
Сообщение от pda (ok), 03-Апр-21, 21:38 
> А ничего что кэш занимает изрядно площади на кристалле? Вам как, ополовинить
> кэш за ваши бабки или чип подороже сделать за дополнительную цену?
> :)

Даже L1? Там килобайты же...

Ответить | Правка | Наверх | Cообщить модератору

108. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +1 +/
Сообщение от Аноним (-), 04-Апр-21, 11:30 
> Даже L1? Там килобайты же...

Килобайты - но таки сверхскоростного SRAM с обвесом, способного работать на полной частоте проца. Это критичный и жручий кусок. И это, осевшее в L2 или где там, тоже по таймингам весьма измеирмо отличается от DRAM. У DRAM как такового латенси зверская по меркам проца. Настоящие про скоростных алгоритмов делают удобно всей этой механике, если кто не понял, а не просто "пишут программу".

Кэши по возможности максимизируют покуда это не нагибает какие-то другие параметры типа площади и потребления. Shadowing делаеть это непрактичным, половина бюджета просто идет псу под хвост. Вы получаете заметно более хреновый чип при прочих равных. И если это ок, может, проще было накопипастить кучку in-order ядер, просто не имеющих такой проблемы как категории? Это чего доброго оптимальнее окажется чем половину кешей жирноядра подарить под костыль.

Ответить | Правка | Наверх | Cообщить модератору

125. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от user (??), 04-Апр-21, 13:35 
Хитронахлобученое ядро приходится терпеть, когда оно единственное. Технологии созрели для нескольких десятков ядер чуть проще. Но не совсем примитивных, для этого есть отдельные видяхи и прочие DSP.
Ответить | Правка | Наверх | Cообщить модератору

150. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от Аноним (-), 05-Апр-21, 00:53 
> Хитронахлобученое ядро приходится терпеть, когда оно единственное.

Это вообще где такое сейчас практикуется? Современные 1-ядерные системы ща в основном всякая эмбедовака и проч и там хитрое ядро как раз нафиг никому не надо.

> Технологии созрели для нескольких десятков ядер чуть проще. Но не совсем примитивных, для
> этого есть отдельные видяхи и прочие DSP.

Их прогать - весьма отдельная канитель.

Ответить | Правка | Наверх | Cообщить модератору

176. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от Аноньимъ (ok), 05-Апр-21, 12:14 
К сожалению Настоящие Программисты на сишечке органично неспособно программировать многоядерные архитектуры.
Ответить | Правка | Наверх | Cообщить модератору

126. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от pda (ok), 04-Апр-21, 13:52 
Тогда хотя бы добавлять битовые поля для индикации с какими спекулятивными потоками связана линия. Если при сбрасывании спекулятивного потока команд откажется, что линия не связана ни с чем - очищать её.
Тут по идее значимого замедления не будет, спекулятивные вычисления и так жрут кэш, если ветка, что в итоге будет отброшена уводит выполнение в другую область памяти.
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

127. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от pda (ok), 04-Апр-21, 14:00 
Ну или комбинировать. Я не спец по проектированию процессоров, но тот факт, что размер L1 радикально не увеличился со времён первопней, говорит о том, что бутылочное горлышко там не в площади и энергопотреблении, а в управлении сами кэшем. Чем больше у вас линий в кэше, тем больше операций уходит на проверку что запрос в память попадает в кэшированные данные.
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

177. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от Аноним (177), 05-Апр-21, 12:19 
>вводить теневые линии кэша, по аналогии с теневыми регистрами. Чтобы спекулятивно исполняемый код мог быть связан со спекулятивными линиями кэша.

А как быть, если спекуляция оказалась в попад? Как, в таком случае, быстро перенести результат спекуляции в основной кеш?

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

186. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от pda (ok), 05-Апр-21, 22:07 
> А как быть, если спекуляция оказалась в попад? Как, в таком случае,
> быстро перенести результат спекуляции в основной кеш?

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

Ответить | Правка | Наверх | Cообщить модератору

185. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от Аноним (183), 05-Апр-21, 20:34 
Нахер линии, когда можно обойтись несколькими битами в теге?
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

187. "Компания AMD подтвердила потенциальную подверженность CPU AM..."  +/
Сообщение от pda (ok), 05-Апр-21, 22:13 
> Нахер линии, когда можно обойтись несколькими битами в теге?

Затем что спекуляция уменьшает эффективный размер кэша. Допустим на некотором jxx код расходится. Одна ветка читает из одной области памяти, другая из другой. Процессор спекулятивно выполняет обе, загружая данные для каждой из них в свою линию кэша. Затем он отбрасывает ненужную ветку и теперь чтобы избежать всяких спектров должен сбросить и спекулятивную линию. Когда она загрузилась там были какие-то данные, которые могут пригодится позже. Теперь их нет. И того, что было загружено - нет. Получается размер кэша как бы стал меньше.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру