The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Серьёзное снижение производительности ядра 5.19, вызванное защитой от атаки Retbleed, opennews (??), 12-Сен-22, (0) [смотреть все]

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


15. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +7 +/–
Сообщение от erthink (ok), 12-Сен-22, 14:59 
Если в штеудах закрыть _все_ спекулятивные дыры, но они будут медленнее сопоставимых Эльбрусов (имеется в виду 16C на 16 нм).

Но тут всё-таки есть вопрос, нужно ли (есть ли смысл) закрывать все интеловские дыры в спекулятивном выполнении, если в микрокоде вообще не понятно что, а в ЦПУ интегрирован руткит с отдельным независимым процессорным ядром (aka AMT).

Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).

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

27. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Без аргументов (?), 12-Сен-22, 15:25 
В Эльбрусах тоже есть спекулятивное выполнение)) просто уязвимость невозможно найти в том, чего нет.
Ответить | Правка | Наверх | Cообщить модератору

59. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +5 +/–
Сообщение от Аноним (51), 12-Сен-22, 16:25 
Чёт не распарсил. Как бы, две части предложения противоречат друг другу.
Ответить | Правка | Наверх | Cообщить модератору

72. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 16:59 
Он пытался сострить, но не учёл как минимум http://elbrus.6te.net ;-)
Ответить | Правка | Наверх | Cообщить модератору

120. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от a_kusb (ok), 12-Сен-22, 19:19 
> Он пытался сострить, но не учёл как минимум http://elbrus.6te.net ;-)

В принципе эффект неуловимого Джо. Может и в ARM меньше дыры бросаются в глаза, что до эльбрусов то.

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

152. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 01:34 
Игра в видео не удачный пример. Это игра годов, когда были в ходу Pentium 3. Ещёбы эта игра не заработала как положено. Тест скорее всего видеокарты.

Ах да видео о корпусе для ПК.

Игры меня не интересуют.

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

62. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –2 +/–
Сообщение от Аноним (62), 12-Сен-22, 16:30 
> Если в штеудах закрыть _все_ спекулятивные дыры, но они будут медленнее сопоставимых Эльбрусов (имеется в виду 16C на 16 нм).

Ждём нормально оформленного теста.

> Но тут всё-таки есть вопрос, нужно ли (есть ли смысл) закрывать все интеловские дыры в спекулятивном выполнении

Правильно - для многих применений нету, и тут с интелами можно получать производительность на порядки выше эльбрусовской.

> если в микрокоде вообще не понятно что, а в ЦПУ интегрирован руткит с отдельным независимым процессорным ядром (aka AMT).

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

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

73. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +3 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 17:01 
> и тут с интелами можно получать производительность на порядки выше эльбрусовской.

Вас же не затруднит циферки-то привести?  Вот прям-таки в сотни, тыщи и прочие #миллионы разов отличающиеся?

> у эльбрусов, например, руткит сидит и в железе, и в микрокоде,
> а вдобавок ещё и в комиляторе.

В Вас сидит балабол.

Впрочем, можете попытаться опровергнуть.

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

67. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (67), 12-Сен-22, 16:47 
а что в 7й сделают эдакое? Когда она выйдет и где можно будет купить?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

91. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от n00by (ok), 12-Сен-22, 17:43 
> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).

Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов не очень работает. Но зависит от байткода и ВМ, конечно.

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

239. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от erthink (ok), 13-Сен-22, 13:28 
>> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
>> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).
> Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов
> не очень работает. Но зависит от байткода и ВМ, конечно.

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

Но основное замедление не из-за отсутствия предсказателя, а из-за отсутствия спекулятивного выполнения и низкой заполняемости ШК (широких команд).

Переименование регистров и спекулятивное выполнение позволяет out-of-order ЦПУ начать выполнять следующий и даже через-один элемент байт-кода. Тогда как на VLIW каждый элемент байт-кода в большинстве случаев требует выполнения нескольких крайне рыхлых ШК.

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

275. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 13-Сен-22, 17:14 
>>> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
>>> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).
>> Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов
>> не очень работает. Но зависит от байткода и ВМ, конечно.
> ВМ - более абстрактная вещь, но если говорить о байткоде, то предсказание
> переходов работает не плохо.
> Очень хорошо предсказываются все служебные переходы, leaf-циклы и более-менее ветвления
> в них.

Похоже, я что-то недопонимаю. Допустим, у абстрактного процессора есть 256 команд. Их исполняет switch в цикле. Какие-то опкоды можно сгруппировать, в итоге получаем 32 case. При компиляции такой «ВМ» окажется, что switch представляет из себя косвенный переход по таблице адресов в памяти. При таком количестве предсказание на основе истории переходов работает не очень, вот что пишет Интел:

B.8.3.2
Virtual Tables and Indirect Calls
17. Virtual Table Usage: BR_IND_CALL_EXEC / INST_RETIRED.ANY
A high value for the ratio Virtual Table Usage indicates that the code includes many indirect calls. The
destination address of an indirect call is hard to predict.

и вот что рекомендует, что бы упростить предсказание:

Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are
present, try to put the most likely target of an indirect branch immediately following the indirect
branch. Alternatively, if indirect branches are common but they cannot be predicted by branch
prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the
processor from decoding down the fall-through path.

Для тестов реализовал интерпретатор байт-кода OCaml на асме AMD64, при этом вместо косвенного перехода по таблице вычислял адрес обработчика умножением на степень двойки (на старых поколениях архитекруры это было бы быстрее, поскольку исключается чтение адреса из памяти).

Вот такие печальные результаты предсказателя из perf stat


    12 440 035 801      instructions:u            #    0,48  insn per cycle
     1 039 998 618      branch-misses:u           #   33,33% of all branches

Что бы улучшить ситуацию, пришлось добавить условный переход, который никогда не исполняется

 execute_instruction:
     mov    eax, [opcode]
     shl    rax, instruction_size_log2
+;    Переход никогда не происходит. Предотвращает предсказания следующего
+;    косвенного перехода, во многих случаях некорректные.
+    jc    .stop
     lea    rax, [rax + vm_base + vm_base_lbl - execute_instruction]
     next_opcode
     jmp    rax
-    ud2
+.stop:    ud2

Здесь промахов нет, но обратите внимание - всего одна инструкция за такт, что явно меньше возможного.

    11 600 026 289      instructions:u            #    1,21  insn per cycle
        80 002 443      branch-misses:u           #    3,51% of all branches

Последние результаты блики к оригинальному интерпретатору, написанному на Си. В той реализации файл с байткодом считывается в память и каждый опкод заменяется адресом обработчика, в последствии исполняется расширением GCC goto *ptr.

Если же опкодов мало и их обработчики объёмные, тогда предсказатель должен повести себя лучше, но много ли таких ВМ?

> Но основное замедление не из-за отсутствия предсказателя, а из-за отсутствия спекулятивного
> выполнения и низкой заполняемости ШК (широких команд).
> Переименование регистров и спекулятивное выполнение позволяет out-of-order ЦПУ начать
> выполнять следующий и даже через-один элемент байт-кода. Тогда как на VLIW
> каждый элемент байт-кода в большинстве случаев требует выполнения нескольких крайне рыхлых
> ШК.

По-моему, в примере выше процессор не знает, что ему можно исполнить.

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

321. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от erthink (ok), 13-Сен-22, 20:18 
>[оверквотинг удален]
> +; Переход никогда не происходит. Предотвращает предсказания следующего
> +; косвенного перехода, во многих случаях некорректные.
> + jc .stop
>   lea rax, [rax + vm_base + vm_base_lbl - execute_instruction]
>   next_opcode
>   jmp rax
> - ud2
> +.stop: ud2
>
> Здесь промахов нет, но обратите внимание - всего одна инструкция за такт,

Всё примерно верно, но только иначе.

Базовый паттерн goto jump_table[*bytecode_ip++], соответственно out-of-order процессор может "узнать" адрес перехода еще до реального выполнения инструкций перед goto.
Условных переходов тут нет (можно избавиться), поэтому предсказывать нечего.

Если же инструкция байткода соответствует условному переходу, то вот тогда может участвовать предсказатель.
И у всех современных ЦПУ он будет работать и верно предсказывать переходы в случае циклов в байткоде.

Сложно возникают только если в байткоде есть цикл, а внутри него оператор if, которые реализуются через один опкод, но в актуальном коде работают в разных плечах.
Тогда просто предсказатель начинает путаться, но штеудовский во многих случаях умеет подстраиваться (работает по принципу электронной гадалки).

Как-то так.

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

396. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 17-Сен-22, 08:14 
>[оверквотинг удален]
> Базовый паттерн goto jump_table[*bytecode_ip++], соответственно out-of-order процессор
> может "узнать" адрес перехода еще до реального выполнения инструкций перед goto.
> Условных переходов тут нет (можно избавиться), поэтому предсказывать нечего.
> Если же инструкция байткода соответствует условному переходу, то вот тогда может участвовать
> предсказатель.
> И у всех современных ЦПУ он будет работать и верно предсказывать переходы
> в случае циклов в байткоде.
> Сложно возникают только если в байткоде есть цикл, а внутри него оператор
> if, которые реализуются через один опкод, но в актуальном коде работают
> в разных плечах.

Да, те замеры проводились на байткоде, полученном вот из такого исходника:


let rec tailcall4 a b c d =
  if a < 0
  then b
  else tailcall4 (a-1) (b+1) (c+2) (d+3)
По-моему, цикл с выходом по условию - достаточно частая конструкция.

> Тогда просто предсказатель начинает путаться, но штеудовский во многих случаях умеет подстраиваться
> (работает по принципу электронной гадалки).

То есть Интел хорошо работает не во всех случаях. Соответственно, когда это критично, интерпретаторы и/или исполняемую программу оптимизируют с учётом особенностей имеющегося процессора. Под Эльбрус собирают уже готовое, а не под него спроектированное. Возможно, это не решающий фактор, но наверняка играет роль. Если так, то получается, что имеющийся «бесплатный» открытый код отчасти представляет собой эдакий чемодан без ручки, реальная цена за него - это негатив к Эльбрусу.

> Как-то так.

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

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

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




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

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