Телеграмм чат группы compilerdev страница 1273

Но это было 3 года назад.

10:18пожаловаться #1

MO

Но в широкой команде всё-равно же стоит код этого nop-а, который занимает свой слот.

Про компилятор не знаю. Но когда смотрел на выставке примеры, nop-ов было много. И в исходниках очень много ручной оптимизации через intrinsic-и.

Несколько бит, которые бы все равно съело выравнивание

10:19пожаловаться #2

МБ

Несколько бит, которые бы все равно съело выравнивание

Можно ли раскрыть идею? Несколько - это сколько? Несколько на каждый nop или несколько на все nop-ы в слове? Типа, в инструкции есть префикс, который говорит, где nop-ы, а где нет?

10:21пожаловаться #3

MO

Можно ли раскрыть идею? Несколько - это сколько? Несколько на каждый nop или несколько на все nop-ы в слове? Типа, в инструкции есть префикс, который говорит, где nop-ы, а где нет?

Да, примерно так. Широкая команда состоит из слов по 4 байта. Первое слово - заголовок (префикс) ШК. Там, кроме всего прочего, 3 бита отведено на нопы

10:22пожаловаться #4

МБ

Да, примерно так. Широкая команда состоит из слов по 4 байта. Первое слово - заголовок (префикс) ШК. Там, кроме всего прочего, 3 бита отведено на нопы

Здорово. Спасибо за пояснения. Поди в этих префиксах и префетчи какие-нибудь закодированы?

10:25пожаловаться #5

MO

Здорово. Спасибо за пояснения. Поди в этих префиксах и префетчи какие-нибудь закодированы?

Я сейчас уже точно не вспомню, но там основную часть занимает "карта" ШК (какие типы слогов присутсвуют), индикаторы специальных режимов исполнения и, возможно, что-то еще.
Префетчи там кодируются в специальных слогах и через специальные регистры

10:27пожаловаться #6

TS

Здорово. Спасибо за пояснения. Поди в этих префиксах и префетчи какие-нибудь закодированы?

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

То есть чтобы эффективно пропустить неиспользуемые байты инструкции - надо их прокачать через подсистему памяти.

10:32пожаловаться #7

МБ

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

То есть чтобы эффективно пропустить неиспользуемые байты инструкции - надо их прокачать через подсистему памяти.

Ну, если есть префикс, который описывает пропуски, то это, вроде как, немного смягчает ситуацию по объёму кода.

10:35пожаловаться #8

МБ

Но вообще, да. Люди часто забывают, что число инструкций - это важно. Фигачат на Крестах кучи инлайнов и получают трэшинг кэшей, а потом удивляются, почему APL быстрее работает :)

10:36пожаловаться #9

TS

не смягчает - вы все равно кратно проигрываете эффективности работы с памятью x86. За счет более плотных инструкций у второго

10:36пожаловаться #10

МБ

не смягчает - вы все равно кратно проигрываете эффективности работы с памятью x86. За счет более плотных инструкций у второго

x86 выигрывает совсем не за счёт плотности инструкций, imho, а за счёт охренно длинных in-flight буферов, предсказателей, wb-очередей и т.д. и т.п. Если бы плотность имела значение, писали бы мы всё для стековых процессоров.

10:37пожаловаться #11

MO

не смягчает - вы все равно кратно проигрываете эффективности работы с памятью x86. За счет более плотных инструкций у второго

Тут вопрос наверное в том, насколько это в реальной жизни проблема. Если префетч инструкций успевает за исполнением, то по большому счету не важно

10:38пожаловаться #12

TS

IIRC, в свое время, в Бабаяновском процессоре VIP (это который был в Интеле, но как развитие многих идей VLIW, и Elbrus) подсчитали плотность очень широких инструкций на линию кеша (скажем 32байт): и у VIP было 2,5, а у x86 - 15. 🤷‍♂️

10:38пожаловаться #13

МБ

Но, конечно, у x86 код плотнее. Но вот POWER-ы тоже очень быстрые, а там пожиже.

10:38пожаловаться #14

MO

И, в случае суперскаляра, интересно, сколько места занимают уже скомпилированные в микрокод инструкции и как там с кешем дела

10:39пожаловаться #15

МБ

И, в случае суперскаляра, интересно, сколько места занимают уже скомпилированные в микрокод инструкции и как там с кешем дела

У суперскаляров это внутренние кэши и очереди. То есть, ещё один уровень, выше L1.

10:40пожаловаться #16

MO

У суперскаляров это внутренние кэши и очереди. То есть, ещё один уровень, выше L1.

Я понимаю

10:41пожаловаться #17

TS

Тут вопрос наверное в том, насколько это в реальной жизни проблема. Если префетч инструкций успевает за исполнением, то по большому счету не важно

не важно, было бы, если проигрыш по эффективности работы с памятью был бы не больше 2-раз. А так с горем пополам напихали в бандл 4 инордер инструкции (и это в идеальном случае, идеального компилятора), а за это время x86 вычитал в 8 раз больше апустил на исполнение инструкций, с тактом больше 2х. И опп...

10:41пожаловаться #18

TS

(а на практике окажется, что под Linux-ом с Итаником, использовался gcc у которого было по 1-ой инструкции на бандл. И производительность по сравнению с тем же самым кодом на x86/Windows была просто неприличная. Потому и утонул)

10:43пожаловаться #19

MO

не важно, было бы, если проигрыш по эффективности работы с памятью был бы не больше 2-раз. А так с горем пополам напихали в бандл 4 инордер инструкции (и это в идеальном случае, идеального компилятора), а за это время x86 вычитал в 8 раз больше апустил на исполнение инструкций, с тактом больше 2х. И опп...

Возможно это и есть причина низкой тактовой частоты вливов, что декодер не успевает за памятью, поэтому вынуждены искуственно ее ограничивать? 🤔