Процессорно-архитектурное
Dec. 4th, 2013 04:09 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
spamsinkЭта штука будет посильнее Трансметы Дитцела!
tl;dr: длины индивидуальных инструкций не обязательно кратны байту; каждый обобщенный линейный участок (один вход, несколько выходов) состоит из заголовка, сообщающего размер участка, и двух кусков: набора инструкций с аргументами потенциально переменной длины — операции с константами, разнообразные обращения к памяти — и набора инструкций фиксированной длины ("регистровых" - в кавычках, потому что регистров в традиционном понимании нет, а есть конвейер результатов). Один из кусков записывается задом наперед, а переход происходит на границу между кусками. Это существенно облегчает декодирование, уменьшает длину конвейера инструкций и избавляет от необходимости переименовывать регистры, и т.п. Предсказание переходов тоже упрощается, поскольку нужно хранить предсказание не каждого условного перехода, а лишь какой именно из переходов в линейном участке сработает. Также планируется сохранять историю предсказаний переходов между запусками программ.
tl;dr: длины индивидуальных инструкций не обязательно кратны байту; каждый обобщенный линейный участок (один вход, несколько выходов) состоит из заголовка, сообщающего размер участка, и двух кусков: набора инструкций с аргументами потенциально переменной длины — операции с константами, разнообразные обращения к памяти — и набора инструкций фиксированной длины ("регистровых" - в кавычках, потому что регистров в традиционном понимании нет, а есть конвейер результатов). Один из кусков записывается задом наперед, а переход происходит на границу между кусками. Это существенно облегчает декодирование, уменьшает длину конвейера инструкций и избавляет от необходимости переименовывать регистры, и т.п. Предсказание переходов тоже упрощается, поскольку нужно хранить предсказание не каждого условного перехода, а лишь какой именно из переходов в линейном участке сработает. Также планируется сохранять историю предсказаний переходов между запусками программ.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-12-05 12:16 am (UTC)Из
боксастелса он вышел, был Мельник силён!no subject
Date: 2013-12-05 12:22 am (UTC)А Из(вне)коробки пока еще не совсем из стелса вылез: вон, домашняя страничка какая позорная.
no subject
Date: 2013-12-05 12:26 am (UTC)Подождём ещё немного с вердиктом.
no subject
Date: 2013-12-05 12:31 am (UTC)no subject
Date: 2013-12-05 12:35 am (UTC)no subject
Date: 2013-12-05 12:35 am (UTC)no subject
Date: 2013-12-05 12:36 am (UTC)no subject
Date: 2013-12-05 12:39 am (UTC)no subject
Date: 2013-12-05 12:43 am (UTC)no subject
Date: 2013-12-05 12:50 am (UTC)no subject
Date: 2013-12-05 01:01 am (UTC)Да ты и сам ниже говоришь.
no subject
Date: 2013-12-05 01:11 am (UTC)no subject
Date: 2013-12-05 01:14 am (UTC)no subject
Date: 2013-12-05 01:28 am (UTC)no subject
Date: 2013-12-05 02:40 am (UTC)no subject
Date: 2013-12-05 03:18 am (UTC)Как бы очевидно, что "несработавшие" переходы и в обычном процессоре никогда не предскажутся, и хранить будет нечего. Другое дело, что инструкции, ведущие к переходам, расположенным после предсказанно "работающего", делается возможно вообще не декодировать.
Кстати, до зипования этих линейных кусков, которое мы недавно пережевывали, они еще не дошли?
no subject
Date: 2013-12-05 03:21 am (UTC)no subject
Date: 2013-12-05 03:35 am (UTC)no subject
Date: 2013-12-05 03:44 am (UTC)no subject
Date: 2013-12-05 03:55 am (UTC)2 Акции мои мне вернут?
no subject
Date: 2013-12-05 03:55 am (UTC)В идеале, конечно, нужно хранить собственно инструкции в одной кучке, а аргументы - в другой, но из слайдов мне так не показалось.
В традиционной архитектуре предсказание нужно вычислять (поэтому иметь место в таблице предсказаний) для каждого выполняемого условного перехода, а здесь - для каждого линейного участка, т.е. реже. Таким образом, вытеснение предсказания из таблицы сравнимого размера тоже будет происходить реже.
Зипование очень дорого при разборке, и соотношение цены и выигрыша быстро падает. Для практических применений достаточно отойти от байтовой границы: у них длина команды 17 бит.
no subject
Date: 2013-12-05 03:57 am (UTC)no subject
Date: 2013-12-05 04:05 am (UTC)И непонятно, в чем экономия на спекулятивном декодировании. Так или иначе, декодировать или надо или не надо. Деление на две кучки только ухудшает локальность кэша инструкций, а заодно и затрудняет определение того, до какой точки надо декодировать (этих точек делается две, и найти точку для каждой стороны можно только просмотрев переключательные биты у всех предыдущих инструкций с обоих сторон).
Еще мне непонятно, чего они так страдают по декодированию. Если сложное декодирование увеличивает скорость исполнения, то оно заведомо выгоднее. То есть, если скажем докодировщик инструкций жрет электричества как второе простое исполнительное ядро, но в результате скорость одного ядра поднимается в скажем 1.75 раз, то это заведомо выгоднее, чем иметь два простых ядра без таких декодировщиков.
no subject
Date: 2013-12-05 04:11 am (UTC)2. Нет.
no subject
Date: 2013-12-05 04:15 am (UTC)Допустим, у нас есть линейный участок, из которого 8 выходов. В традиционной модели нам нужно поддерживать 8 независимых предсказателей, и некоторые комбинации предсказаний не будут иметь смысла (например, если предсказания исполненных переходов больше 1), т.е. модель явно избыточна. Если же предсказывать ожидаемый выход, то в ответе будет всего 3 бита, и они всегда будут иметь смысл.
Пересказывать 5 раз по 50-70 слайдов я сейчас не могу.
no subject
Date: 2013-12-05 04:16 am (UTC)no subject
Date: 2013-12-05 04:23 am (UTC)no subject
Date: 2013-12-05 04:26 am (UTC)no subject
Date: 2013-12-05 04:26 am (UTC)