Предсказатель переходов на Эльбрусе (v7)

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

Что там развивать непонятно, табличка со статистикой. Хотя я видел некоторые думали что +1000% производительности он даст, и что там все на нейронных сетях у интоля определяется, ну тут лол.

4. Работа предсказателя переходов сильно зависит от софта, в том числе от ОС.

Так к 10й версии глядишь и от VLIW откажутся. А кто их, кстати, изготавливает сейчас, есть слухи? Китайский SMIC?

и что там все на нейронных сетях у интоля определяется, ну тут лол.

Ну вроде как у Интоля действительно обученная нейросетка в предсказатель вставлена вместо таблички, и сделали они это уже лет 20 назад. Всего-то им надо было обучить нейросетку на 10-15 командах до перехода + состояния регистров, и она гораздо логичнее должна выискивать паттерны есть переход/нет перехода, чем просто таблица со статистикой.

Но как-то он вяленько добавляет производительности (около ~5%).

а сколько должно быть?

Он собирает статистику во время выполнения, что прекрасно видно по его работе.

Так к 10й версии глядишь и от VLIW откажутся. А кто их, кстати, изготавливает сейчас, есть слухи? Китайский SMIC?

Походу, никто. SMIC стремаются.

а сколько должно быть?

Тут уже написали: +1000% !

Он собирает статистику во время выполнения, что прекрасно видно по его работе.

По работе Интоля или по работе Эльбруса?

Интел, ну это не так уж и плохо, нагруженный код в одном и том же цикле обычно гоняется, и выбираются часто те же ветки.

Ну, вот в видео, Трушкин поясняет и за префетчеры и за out-of-order . Где-то 40-я минута, там таймкоды есть.

Компилятор скорее всего уже помечал чаще используемые ветки, и лишь в редких случаях удается поймать преимущество

Тут пол-ЛОРа усиралось доказывать что Эльбрус говно, т.к. статическое предсказание при компиляции сильно хуже шедулера как в Интеле.

некоторые думали что +1000% производительности он даст, и что там все на нейронных сетях у интоля определяется, ну тут лол

Воистину.

Тут пол-ЛОРа усиралось доказывать что Эльбрус говно, т.к. статическое предсказание при компиляции сильно хуже шедулера как в Интеле.

Ну, объективности ради, первые исследования предсказателя перехода на Эльбрусе давали торможение в 2%.

Опыт реализации предсказания переходов в микропроцессоре с архитектурой «Эльбрус»

Вопрос - почему?

Насколько мне известно в МЦСТ гоняют SPEC с PGO (выжимают максимум). Не стал бы делать далекоидущие выводы только по этим результатам от МЦСТ.

2. Этот предсказатель впихнули чтобы разогнать интерпретируемые/jit языки, а на нативном коде от него будет толку немного.

Да. Смотри результаты 253.perlbmk по своей ссылке. В «нативном» коде тоже будет прок в ситуациях когда компилятору сложно построить оптимальный CFG (особенно без PGO).

Было видео докладчика из МЦСТ, но утонуло в грубинах Telegram, найти не могу

Это? Ссылку нашел на сайте конференции «Встраиваемые системы реального времени» https://kpda.ru/conf-2024/.

Российская платформа Эльбрус, её возможности и экосистема решений
Алексей Мухин - АО МЦСТ
https://vk.com/video-31054583_456239041

Варианты 1 и 2.

Добавлю ещё, что PGO тоже считаю костылём к плохому коду, который со временем должны выкинуть.

Осталось добавить внеочередное исполнение, спекулятивность и спрятать vliw за фронтендом. Тогда можно будет брать.

Были бы там яйца у руководства, давно свернули бы все эти эксперименты с vliw за бюджетные деньги и запилили мейнстримную архитектуру.

Там x86 из коробки.

Там программный эмулятор с некоторой небольшой помощью со стороны железа.

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

Кроме того, в ней костыль на костыле и костылем погоняет. Intel и AMD за много лет удалось там все вылизать до предела, чего заведомо не получилось бы у нас.

Под мейнстримом я понимаю не конкретно x86, а набор подходов. Они общие и в x86 и в ARM и даже в risc-v. Главное, чтобы не vliw. Это говно сливает даже в gpu, что вынудило amd отказаться от него в своих видеокартах. Хотя казалось бы, там 90% всех операций это вектора и матрицы. Но нет. Слив.

Это говно сливает даже в gpu, что вынудило amd отказаться от него в своих видеокартах. Хотя казалось бы, там 90% всех операций это вектора и матрицы. Но нет. Слив.

От VLIW так отказались, что запилили обратно в наследника GCN какими-то убогими костылями. :)

RDNA3 Dual Issue VALU

Осталось добавить внеочередное исполнение, спекулятивность

Таки спекулятвность есть сто лет в обед:

https://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter...

спрятать vliw за фронтендом.
Были бы там яйца у руководства, давно свернули бы все эти эксперименты с vliw за бюджетные деньги

Взаимоисключающие параграфы.

Да. Смотри результаты 253.perlbmk по своей ссылке.

А чем ты объяснишь торможение с предсказателем на bzip2 и gzip по сравнению с обычным исполнением?

Это слёзы, а не спекулятивное исполнение. В x86 ничего руками писать не нужно. И возможности шире. Там процессор, например, даже пытается угадать какой будет индекс на следующей итерации цикла и начинает выполнять код с этим предугаданным значением.

Взаимоисключающие параграфы.

Нет. Наличие у процессора нескольких вычислительных блоков не делает его vliw. Это микроархитектура, спрятанная за фронтендом. Я же говорю про архитектуру, без микро-.

Учитывая отсутствие микрокода, это получается он %)

А чем ты объяснишь торможение с предсказателем на bzip2 и gzip по сравнению с обычным исполнением?

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

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

«Прогрев» хорошо заметно в интерпретаторах когда интерпретируется цикл. В начале будет много ошибок предсказания, но после некоторого времени ошибок (почти) не будет, т.к. интерпретируемый код не меняется, но при этом повторяется большое кол-во раз. Думаю отсюда такая разница в 253.perlbmk и 254.gap (интерпретатор), т.к. время на подготовку убивает всю производительность в таких случаях и PGO тут слабо поможет. А как известно, 90% исполняемого кода это циклы (не помню откуда это утверждение), так что предсказатель тут однозначно выигрывает.

В целом, из-за аппаратного префетча и предсказателя переходов на Эльбрусах наконец-то должен нормально заработать Python и другие интерпретируемые/JIT языки. Хотелось бы увидеть сравнение именно v6, а не с вкл/откл предсказателем на v7.

В x86 ничего руками не надо писать, потому что пишет компилятор, ага, и intel добавляет таблицы стоимости команд для планировщика gcc.

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

Цикл это ветка, чем это отличается от if?

Это слёзы, а не спекулятивное исполнение. В x86 ничего руками писать не нужно.

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

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

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

спрятать vliw за фронтендом

Он и так спрятан. Ты ж не в машкодах пишешь.

Фронтенд процессора, а не компилятора.

Ну а в Эльбрусе процессор пытается вычитывать из памяти следующие данные для будущей итерации цикла, если это массив (APB)

Это всё ручное. Если компилятор паттерн не распознал, то ничего не произойдёт. То что все эти костыли не работают стало понятно 20 лет назад.

Цикл это ветка, чем это отличается от if?

Наличием индекса, по которому идёт доступ в память.

for (int i = 0;...) ...arr[i]

Обращение к полю структуры тоже обращение к адресу со смещением.

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

Описал x86 процессоры. Делайте правильно, иначе замедление в 10 раз в лучшем случае.

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

Фронтенд процессора, а не компилятора.

Тебе шашечки, или ехать?

Это всё ручное. Если компилятор паттерн не распознал, то ничего не произойдёт

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

Да и смысла нет уже пердолиться с нуля с x86, учитывая линукс-ориентированность и задачи эльбруса. Не то, что бы поезд x86 ушёл, а скорее наоборот - пришёл и останавливается. Пока да, ничего лучше нет особо, но конец немного предсказуем. Прямщас конечно никакие армы и риск5 никуда не выстрелят и никого не подвинут с десктопа, это утопия, а вот лет через 5 мейби.

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

На bzip/gzip например видно что предсказатель вообще ошибался и показал результат хуже чем вообще без всего, жаль «чисто подготовленных» в тесте почему то нет а то «миксованый» способ непонятно как использует то и другое в паре.

Но благо хоть есть опция которая судя по всему позволяет регулировать то и другое

Вообще выглядит он как то так:

get_value()
c.pull_int()
ret_value()
/*
e2k_v6:
{ disp get_value %ctpr1 } // подготовка функции
{ ct %ctpr1 }             // вызов
{ disp push_int %ctpr1 }
{ ct %ctpr1 ? %pred0 }    // условный вызов
{ return %ctpr3 }         // подготовка возврата
{ ct %ctpr3 }             // возврат

e2k_v7:
{ icall get_value }        // предсказанный вызов функции
{ icall push_int ? $cmp0 } // предсказанный условный вызов
{ iret }                   // предсказанный возврат
*/

У железа есть статистика исполнения, а у компилятора нет. Это радикально меняет ситуацию. Как для Itanium не старались делать умные компиляторы, ничего из этого не вышло.

У железа есть статистика исполнения, а у компилятора нет

Где оно ее по твоему хранит? Нету у железа такой такой информации, во всех виртуальных машинах и jit компиляторах статистика исполнения собирается софтово с проверками и счетчиками и по достижении какого то порога запускается перекомпиляция.
Единственное чего в принципе нет на этапе компиляции это понмания куда будут указывать два указателя, имперически невозможно никак доказать что во время исполнения это не будет указывать на одно и то же, без честного restrict программиста никак, но далеко не каждый программист задумывается об этом.

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

У железа есть статистика исполнения, а у компилятора нет

Как раз у компилятора есть типовая статистика, полученная при профилировании. Железо гораздо тупее.

Где оно ее по твоему хранит?

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

ну наверное, просто у итаниума был предсказатель с самого начала, туда вообще все что можно было от пентиума оторвать все прикрутили вплоть до mmx.

Как раз у компилятора есть типовая статистика, полученная при профилировании.

Вы при компиляции каждой C/C++ программы передаёте компилятору результаты профилировщика? И даже если и так, это не поможет если характер входных данный поменялся во время работы.

если характер входных данный поменялся во время работы

Не поможет ничего. Рандомные данные невозможно предсказать.

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