Обсуждение:Эльбрус/архитектура: различия между версиями
м (→Работа кеша: -\n) |
м (уточнение автора) |
||
(не показана 1 промежуточная версия этого же участника) | |||
Строка 95: | Строка 95: | ||
== Работа кеша == | == Работа кеша == | ||
ШК, они же размером не по 64 байта всегда?. | > ШК, они же размером не по 64 байта всегда?. | ||
Кстати, там работа идёт четвертинками: если прыгнуть на код которого не в кеше, то погрузится не вся линия, а начиная с той четвертинки линии кеша, которой принадлежит целевой адрес и так до конца линии (там может ещё и следующую линии целиком или даже две подгрузит, в зависимости от аргумента операции ipd в тех ШК, где подготавливался переход). | Кстати, там работа идёт четвертинками: если прыгнуть на код которого не в кеше, то погрузится не вся линия, а начиная с той четвертинки линии кеша, которой принадлежит целевой адрес и так до конца линии (там может ещё и следующую линии целиком или даже две подгрузит, в зависимости от аргумента операции ipd в тех ШК, где подготавливался переход). | ||
И если потом будет переход в ту же линию, но в более ранние четвертинки, то их начнет аппаратура догружать с L2/L3 и/или памяти.. | И если потом будет переход в ту же линию, но в более ранние четвертинки, то их начнет аппаратура догружать с L2/L3 и/или памяти.. | ||
-- | -- Alexander Troosh | ||
== Подкачка == | == Подкачка == | ||
Строка 106: | Строка 106: | ||
И еще, иногда лучше сделать отдельный предварительный цикл подкачки данных, чем замешивать операции подкачки в основной цикл, рискую сделать его более медленным. | И еще, иногда лучше сделать отдельный предварительный цикл подкачки данных, чем замешивать операции подкачки в основной цикл, рискую сделать его более медленным. | ||
-- | -- Alexander Troosh | ||
== Совместимость == | == Совместимость == |
Текущая версия от 07:43, 13 августа 2021
Выравнивание
На до E2Kv5 достаточно, чтоб выравнивание адресов было на 8. А для E2Kv5 и для E2Kv6 – 16. Да и у E2Kv7 изменений не планируется, регистры там останутся 128-битными. В общем, делайте выравнивание на 16 – не ошибётесь. Если в исходниках работают с 256 и 512 битными регистрами AVX, то выравнивание там должно быть 32 и 64 соответственно, - так и оставляйте это (вряд ли будет лучше, если уменьшить до безопасных 8 или 16 для эльбрусов). (вроде компилятору нужно еще постараться задать выравнивание более 16, что-то там в ir мало бит под это свойство отвели – переделывать накладно/лень, пока никто не занялся убежать в важности этого, точнее бага была, но бодаться было лень). А так невыровненные обращения e2k переживёт, это не спарк... Одно на кластер в широкой команде ещё нормально и почти даром, а дальше очень большие штрафы были у e2k до 4 версии включительно (до полусотни тактов). В пятой начали это улучшать, в 6й должно быть совсем хорошо. Проблема в то, что компилятор лепит обращения к памяти в широкой команде как получается, он не следит за возможными невыровненными обращениями и часто просто не имеет такой информации. (Как-то предлагалось поддержать атрибут __unaligned как у Microsoft, да как-то не прижилось). -- Alexander Troosh в e2k_chat
Предикаты
{ pass %pred0, @p0 pass %pred1, @p1 andp @p0, @p1, @p4 pass @p4, %pred0 }
Это всё 1 слог PLS. В ШК может быть до 3 таких слогов. Эквивалентно следующему:
p0 = load %pred0 p1 = load %pred1 p4 = p0 && p1 store p4 to %pred0
@pM (где M от 0 до 6) это локальный предикат для логических операций.
pass %predN, @pM — чтение предикатного регистра N в локальный предикат M. pass @pM, %predN — запись локального предиката M в предикатный регистр N.
Номера локальных предикатов жёстко прибиты к PLS.
PLS0
- Читает предикатные регистры в @p0 и @p1.
- Результат логической операции сохраняется в @p4.
- Пишет @p4 в предикатный регистр.
PLS1
- Читает предикатные регистры в @p2 и @p3.
- Результат логической операции сохраняется в @p5.
- Пишет @p5 в предикатный регистр.
PLS2
- Не может читать предикатные регистры.
- Результат логической операции сохраняется в @p6.
- Пишет @p6 в предикатный регистр.
Логические операции могут читать @p0, @p1, @p2 и @p3 без каких либо ограничений. Читать результат другой логической операции можно только при определённых условиях.
Например в таком случае.
{ ! PLS0 pass %pred0, @p0 pass %pred1, @p1 andp @p0, @p1, @p4 pass @p4, %pred4 ! PLS1 pass %pred2, @p2 pass %pred3, @p3 andp @p2, @p3, @p5 pass @p5, %pred5 ! PLS2 andp @p4, @p5, @p6 ! результаты пред. лог. операций pass @p6, %pred6 }
-- numas13 в e2k_chat
Работа кеша
> ШК, они же размером не по 64 байта всегда?. Кстати, там работа идёт четвертинками: если прыгнуть на код которого не в кеше, то погрузится не вся линия, а начиная с той четвертинки линии кеша, которой принадлежит целевой адрес и так до конца линии (там может ещё и следующую линии целиком или даже две подгрузит, в зависимости от аргумента операции ipd в тех ШК, где подготавливался переход). И если потом будет переход в ту же линию, но в более ранние четвертинки, то их начнет аппаратура догружать с L2/L3 и/или памяти.. -- Alexander Troosh
Подкачка
Самая большая проблема это отсутствие данных хоть в каком-то кеше, так как задержка обращения в памяти это уже сотни тактов... Компилятор видимо подкачивал данные в L2, для чего действительно достаточно одного байтового обращения на одну линии кеша. И еще, иногда лучше сделать отдельный предварительный цикл подкачки данных, чем замешивать операции подкачки в основной цикл, рискую сделать его более медленным. -- Alexander Troosh
Совместимость
Если собирать под определённый CPU, то в заголовке ELF это будет прописано и ядро откажется запускать такую программу на другом CPU. В e2k задержки операций специфичны для каждого CPU (хоть на практике это и редкость). В будущем могут выйти Эльбрусы на одной ISA (допустим e2kv7), но с разными задержками. ПО для одного CPU будет неэффективно исполнятся на CPU с другими задержками. -- Denis Drakhnia