Здравствуйте, vdimas, Вы писали:
V>Допустим, у тебя не 4*4 упакованных числа, а 6*6.
V>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
К примеру, AVX-512 может обработать 8 упакованных double за одну операцию. И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.

V>Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
Это было бы интересно, если бы у нас был доступ для пощупать руками.


V>Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
V>Дальнейшие поколения Cray и Эльбрусов развивали этот подход.

V>Еще пример.
V>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
V>Здесь уже SIMD сливает.
Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.

V>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.

V>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?

V>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
В SIMD ветвления делаются не так
V>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Надо щупать руками.

V>Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
Ну, пусть будет так.

V>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Это везде так. Чудес-то не бывает.
V>Часто это влечёт за собой лишние телодвижения.

V>Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Чего?
V>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.

V>Всё так.
V>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Воот. А всего один пост назад интринсики SIMD были позорищем
V>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.

V>Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
V>Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно предварительной подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Где можно про этот буфер почитать? Каков его размер?

V>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.

V>Неужели у тебя претензии лично ко мне? ))
Нет, отчего же. Вы же к МЦСТ отношения не имеете.

V>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?

V>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
Ну, если у них конвеер коротки — то почему нет. Но у меня не хватает квалификации для выполнения профилирования в уме, да ещё и под неизвестную архитектуру. Была бы железка — было бы о чём говорить.

V>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
Не было у итаниумов никакого решающего преимущества на практике.

V>Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
Это смелые утверждения

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


V>И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
V>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
У них основной козырь — это отлаженный конвеер разработки.
Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Эльбрус, достигни он своих целей, мог бы стать тем самым лесником из анекдота.
Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia. Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
V>А пока что будущее ближайших единиц лет более чем прозрачно.
У вас в слове "призрачно" опечатка.