Сообщение Re[20]: .Net на эльбрусах от 18.08.2022 21:53
Изменено 18.08.2022 21:57 vdimas
Re[20]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
V>>Забудь само слово "автовекторизация" когда речь про VLIW.
S>С чего бы вдруг?
Потому что, в отличие от инструкций SIMD, работающих над упакованными данными, у VLIW развязаны руки.
Допустим, у тебя не 4*4 упакованных числа, а 6*6.
В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
Основная операция в БПФ, корреляции, фильтрации, ИИ — это одинаковые вычисления вида x=a0*b0+a1*b1+...+aN*bN.
Для современной радиолокации на фазированных решетках выполняются эти же операции.
Для любых алгоритмов автоподстройки чего-то там, слежения за текущим курсом и его коррекции ракет космических или крылатых (эти алгоритмы на основе корреляции/фильтрации) — аналогично.
Собсно, поэтому я уверен, что Эльбрус никуда не денется.
Он нам нужен хотя бы для военки и космоса.
Даже если взять облака и HPC (высокопроизводительные вычисления) — именно на этих вычислениях операции Эльбрус рвёт любые x64 как тузик грелку.
Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
V>>http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
S>Ну, это же не общегражданская микросхема, а попытка сделать специализированную железку для конкретных надобностей.
Да, но задача эта отродясь была противоречивой.
Традиционные DSP-процы имели простую архитектуру: два индексных регистра, умножитель и сумматор.
За один такт выполнялось:
— умножение двух чисел по индексным регистрам
— прибавление результата умножения к сумматору
— приращение индексных регистров.
(см формулу выше)
Ну и плюс команды ветвления по флагам (обычно по флагу скипается следующая команда, которая безусловный jump).
Развитие DSP шло по пути VLIW — наборов умножитель+сумматор могло быть более одного, в одной команде параллельно можно было производить более одной такой ветки вычислений.
Одно было плохо — "бизнес логика" на таких процах выполнялась паршиво.
Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
Еще пример.
В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
Здесь уже SIMD сливает.
Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операций, т.к. делается через сравнение+ветвление и т.д.
В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Как обычно, наиболее общее решение плохо работает для конкретного случая.
V>>Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
V>>http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
S>Эмм, какое отношение ПЛК имеют к бизнес-вычислениям? Или, скажем, к Эльбрусам и VLIW?
Эта тема более общая — отечественные камни как таковые.
Ввиду наличия некоторого инсайда и регулярно удовлетворяемого любопытства, я просто делюсь инфой.
V>>Это как вызов подпрограммы над определёнными структурами данных.
S>Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Аргументом этой команды является указатель на число в памяти и два аргумента в регистрах.
Я бы не назвал простой указатель на число указателем на "определённую структуру данных".
Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
S>Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
Дело не в трёхаргументности.
Дело в требованиях к лейауту данных в памяти.
Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Часто это влечёт за собой лишние телодвижения.
Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Вы нынешнем 16с содерижтся 16 таких монструозных ядер, в разрабатываемом 32с — 32.
S>Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям.
Всё так.
Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Плюс развивается либа по высокоэффективным вычислениям, конечно:
Есть еще специфическая фишка Эльбрусов — это буфер подкачки данных.
В чём там суть?
На классических камнях есть кеши инструкций и данных, на Эльбрусе тоже есть.
Однако, мультимедиа-операции плохо ложатся на кеш данных, т.к. данные эти требуются лишь однократно.
На этих операция вычисление над большими массивами данных лишь делает кеш инвалидным, вытесняя необходимые данные из некоей логики, к которым (данным) требуется периодическое повторное обращение.
Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Вот ребята поугорали, случайно столкнувшись с этим:
http://personeltest.ru/category-10114-e2k.html
V>>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
S>Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
Неужели у тебя претензии лично ко мне? ))
Конечно, под Эльбрус есть математические библиотеки, сведены в EML:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter7.html
S>У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
V>>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
S>И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
EPIC не означает отмены OoO, спекулятивности и предсказания ветвлений.
Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
V>>И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
S>О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник.
Наоборот, один из удачников.
S>А Интел — сплошной фейк. Вот то ли дело МЦСТ!
Смена последних поколений архитектуры — фейк.
Архитектура та же.
V>>Тупик происходит уже 10-й год.
S>
Нам до того тупика — ещё сорок вёрст с поворотами.
Это смотря по какой причине тупик.
Если по причине объективного достижения некоей точки насыщения современных технологий — то отнюдь.
Например, 32с разводят под 6нм техпроцесс.
Бо насыщение-с...
Большая разница на оси X (время) начинает слабо влиять на ось Y (результат).
В итоге через единицы лет это отставание станет непринципиальным.
И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
А пока что будущее ближайших единиц лет более чем прозрачно.
S>Здравствуйте, vdimas, Вы писали:
V>>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
V>>Забудь само слово "автовекторизация" когда речь про VLIW.
S>С чего бы вдруг?
Потому что, в отличие от инструкций SIMD, работающих над упакованными данными, у VLIW развязаны руки.
Допустим, у тебя не 4*4 упакованных числа, а 6*6.
В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
Основная операция в БПФ, корреляции, фильтрации, ИИ — это одинаковые вычисления вида x=a0*b0+a1*b1+...+aN*bN.
Для современной радиолокации на фазированных решетках выполняются эти же операции.
Для любых алгоритмов автоподстройки чего-то там, слежения за текущим курсом и его коррекции ракет космических или крылатых (эти алгоритмы на основе корреляции/фильтрации) — аналогично.
Собсно, поэтому я уверен, что Эльбрус никуда не денется.
Он нам нужен хотя бы для военки и космоса.
Даже если взять облака и HPC (высокопроизводительные вычисления) — именно на этих вычислениях операции Эльбрус рвёт любые x64 как тузик грелку.
Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
V>>http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
S>Ну, это же не общегражданская микросхема, а попытка сделать специализированную железку для конкретных надобностей.
Да, но задача эта отродясь была противоречивой.
Традиционные DSP-процы имели простую архитектуру: два индексных регистра, умножитель и сумматор.
За один такт выполнялось:
— умножение двух чисел по индексным регистрам
— прибавление результата умножения к сумматору
— приращение индексных регистров.
(см формулу выше)
Ну и плюс команды ветвления по флагам (обычно по флагу скипается следующая команда, которая безусловный jump).
Развитие DSP шло по пути VLIW — наборов умножитель+сумматор могло быть более одного, в одной команде параллельно можно было производить более одной такой ветки вычислений.
Одно было плохо — "бизнес логика" на таких процах выполнялась паршиво.
Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
Еще пример.
В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
Здесь уже SIMD сливает.
Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операций, т.к. делается через сравнение+ветвление и т.д.
В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Как обычно, наиболее общее решение плохо работает для конкретного случая.
V>>Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
V>>http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
S>Эмм, какое отношение ПЛК имеют к бизнес-вычислениям? Или, скажем, к Эльбрусам и VLIW?
Эта тема более общая — отечественные камни как таковые.
Ввиду наличия некоторого инсайда и регулярно удовлетворяемого любопытства, я просто делюсь инфой.
V>>Это как вызов подпрограммы над определёнными структурами данных.
S>Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Аргументом этой команды является указатель на число в памяти и два аргумента в регистрах.
Я бы не назвал простой указатель на число указателем на "определённую структуру данных".
Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
S>Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
Дело не в трёхаргументности.
Дело в требованиях к лейауту данных в памяти.
Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Часто это влечёт за собой лишние телодвижения.
Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Вы нынешнем 16с содерижтся 16 таких монструозных ядер, в разрабатываемом 32с — 32.
S>Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям.
Всё так.
Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Плюс развивается либа по высокоэффективным вычислениям, конечно:
Есть еще специфическая фишка Эльбрусов — это буфер подкачки данных.
В чём там суть?
На классических камнях есть кеши инструкций и данных, на Эльбрусе тоже есть.
Однако, мультимедиа-операции плохо ложатся на кеш данных, т.к. данные эти требуются лишь однократно.
На этих операция вычисление над большими массивами данных лишь делает кеш инвалидным, вытесняя необходимые данные из некоей логики, к которым (данным) требуется периодическое повторное обращение.
Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Вот ребята поугорали, случайно столкнувшись с этим:
http://personeltest.ru/category-10114-e2k.html
Если говорить о случайной нагрузке небольшими блоками, то:
с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.
...
А вот в последовательной нагрузке большими блоками картина прямо противоположная:
оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.
V>>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
S>Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
Неужели у тебя претензии лично ко мне? ))
Конечно, под Эльбрус есть математические библиотеки, сведены в EML:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter7.html
"7.4.2. Умножение матриц" Время выполнения программы умножения матриц Интел | Эльбрус | Эльбрус + eml ------------------------------------ 316.82 | 1206.92 | 14.69
S>У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
V>>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
S>И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
EPIC не означает отмены OoO, спекулятивности и предсказания ветвлений.
Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
V>>И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
S>О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник.
Наоборот, один из удачников.
S>А Интел — сплошной фейк. Вот то ли дело МЦСТ!
Смена последних поколений архитектуры — фейк.
Архитектура та же.
V>>Тупик происходит уже 10-й год.
S>
Нам до того тупика — ещё сорок вёрст с поворотами.Это смотря по какой причине тупик.
Если по причине объективного достижения некоей точки насыщения современных технологий — то отнюдь.
Например, 32с разводят под 6нм техпроцесс.
Бо насыщение-с...
Большая разница на оси X (время) начинает слабо влиять на ось Y (результат).
В итоге через единицы лет это отставание станет непринципиальным.
И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
А пока что будущее ближайших единиц лет более чем прозрачно.
Re[20]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
V>>Забудь само слово "автовекторизация" когда речь про VLIW.
S>С чего бы вдруг?
Потому что, в отличие от инструкций SIMD, работающих над упакованными данными, у VLIW развязаны руки.
Допустим, у тебя не 4*4 упакованных числа, а 6*6.
В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
Основная операция в БПФ, корреляции, фильтрации, ИИ — это одинаковые вычисления вида x=a0*b0+a1*b1+...+aN*bN.
Для современной радиолокации на фазированных решетках выполняются эти же операции.
Для любых алгоритмов автоподстройки чего-то там, слежения за текущим курсом и его коррекции ракет космических или крылатых (эти алгоритмы на основе корреляции/фильтрации) — аналогично.
Собсно, поэтому я уверен, что Эльбрус никуда не денется.
Он нам нужен хотя бы для военки и космоса.
Даже если взять облака и HPC (высокопроизводительные вычисления) — именно на этих вычислениях операции Эльбрус рвёт любые x64 как тузик грелку.
Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
V>>http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
S>Ну, это же не общегражданская микросхема, а попытка сделать специализированную железку для конкретных надобностей.
Да, но задача эта отродясь была противоречивой.
Традиционные DSP-процы имели простую архитектуру: два индексных регистра, умножитель и сумматор.
За один такт выполнялось:
— умножение двух чисел по индексным регистрам
— прибавление результата умножения к сумматору
— приращение индексных регистров.
(см формулу выше)
Ну и плюс команды ветвления по флагам (обычно по флагу скипается следующая команда, которая безусловный jump).
Развитие DSP шло по пути VLIW — наборов умножитель+сумматор могло быть более одного, в одной команде параллельно можно было производить более одной такой ветки вычислений.
Одно было плохо — "бизнес логика" на таких процах выполнялась паршиво.
Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
Еще пример.
В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
Здесь уже SIMD сливает.
Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Как обычно, наиболее общее решение плохо работает для конкретного случая.
V>>Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
V>>http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
S>Эмм, какое отношение ПЛК имеют к бизнес-вычислениям? Или, скажем, к Эльбрусам и VLIW?
Эта тема более общая — отечественные камни как таковые.
Ввиду наличия некоторого инсайда и регулярно удовлетворяемого любопытства, я просто делюсь инфой.
V>>Это как вызов подпрограммы над определёнными структурами данных.
S>Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Аргументом этой команды является указатель на число в памяти и два аргумента в регистрах.
Я бы не назвал простой указатель на число указателем на "определённую структуру данных".
Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
S>Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
Дело не в трёхаргументности.
Дело в требованиях к лейауту данных в памяти.
Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Часто это влечёт за собой лишние телодвижения.
Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Вы нынешнем 16с содерижтся 16 таких монструозных ядер, в разрабатываемом 32с — 32.
S>Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям.
Всё так.
Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Плюс развивается либа по высокоэффективным вычислениям, конечно:
Есть еще специфическая фишка Эльбрусов — это буфер подкачки данных.
В чём там суть?
На классических камнях есть кеши инструкций и данных, на Эльбрусе тоже есть.
Однако, мультимедиа-операции плохо ложатся на кеш данных, т.к. данные эти требуются лишь однократно.
На этих операция вычисление над большими массивами данных лишь делает кеш инвалидным, вытесняя необходимые данные из некоей логики, к которым (данным) требуется периодическое повторное обращение.
Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Вот ребята поугорали, случайно столкнувшись с этим:
http://personeltest.ru/category-10114-e2k.html
V>>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
S>Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
Неужели у тебя претензии лично ко мне? ))
Конечно, под Эльбрус есть математические библиотеки, сведены в EML:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter7.html
S>У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
V>>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
S>И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
EPIC не означает отмены OoO, спекулятивности и предсказания ветвлений.
Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
V>>И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
S>О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник.
Наоборот, один из удачников.
S>А Интел — сплошной фейк. Вот то ли дело МЦСТ!
Смена последних поколений архитектуры — фейк.
Архитектура та же.
V>>Тупик происходит уже 10-й год.
S> Нам до того тупика — ещё сорок вёрст с поворотами.
Это смотря по какой причине тупик.
Если по причине объективного достижения некоей точки насыщения современных технологий — то отнюдь.
Например, 32с разводят под 6нм техпроцесс.
Бо насыщение-с...
Большая разница на оси X (время) начинает слабо влиять на ось Y (результат).
В итоге через единицы лет это отставание станет непринципиальным.
И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
А пока что будущее ближайших единиц лет более чем прозрачно.
S>Здравствуйте, vdimas, Вы писали:
V>>Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
V>>Забудь само слово "автовекторизация" когда речь про VLIW.
S>С чего бы вдруг?
Потому что, в отличие от инструкций SIMD, работающих над упакованными данными, у VLIW развязаны руки.
Допустим, у тебя не 4*4 упакованных числа, а 6*6.
В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
Основная операция в БПФ, корреляции, фильтрации, ИИ — это одинаковые вычисления вида x=a0*b0+a1*b1+...+aN*bN.
Для современной радиолокации на фазированных решетках выполняются эти же операции.
Для любых алгоритмов автоподстройки чего-то там, слежения за текущим курсом и его коррекции ракет космических или крылатых (эти алгоритмы на основе корреляции/фильтрации) — аналогично.
Собсно, поэтому я уверен, что Эльбрус никуда не денется.
Он нам нужен хотя бы для военки и космоса.
Даже если взять облака и HPC (высокопроизводительные вычисления) — именно на этих вычислениях операции Эльбрус рвёт любые x64 как тузик грелку.
Я давал в прошлых сообщениях ссылки, где на тестах HPC уступающий по тактовой Эльбрус разделался с Интел-архитектурой, обогнав примерно в 3 раза, и это был проц, который на сегодня уже морально устарел. Т.е. даже на том проце под облаками потребуется в 3 раза меньше ресурсов на те же вычисления. В новых процах ожидается кратность до 10-ти. Понятно, что Интеллы за ближайшие 3 года тоже чуть подрастут, но я точно знаю, что подрастут несильно, потому что я вижу, что там происходит — ничего. Зеро.
V>>http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
S>Ну, это же не общегражданская микросхема, а попытка сделать специализированную железку для конкретных надобностей.
Да, но задача эта отродясь была противоречивой.
Традиционные DSP-процы имели простую архитектуру: два индексных регистра, умножитель и сумматор.
За один такт выполнялось:
— умножение двух чисел по индексным регистрам
— прибавление результата умножения к сумматору
— приращение индексных регистров.
(см формулу выше)
Ну и плюс команды ветвления по флагам (обычно по флагу скипается следующая команда, которая безусловный jump).
Развитие DSP шло по пути VLIW — наборов умножитель+сумматор могло быть более одного, в одной команде параллельно можно было производить более одной такой ветки вычислений.
Одно было плохо — "бизнес логика" на таких процах выполнялась паршиво.
Наши Эльбрусы и их Cray взялись за задачу совместить ужа с ежом — сохранить эффективность на целевом классе вычислений и поиметь хоть какую-то эффективность на "бизнес логике", т.е. где много ветвлений, плюс развитая булевская логика (например, в Эльбрусах есть условная запись предикатов — это объединение примерно двух булевских операций и ненавистного для процессоров ветвления в одну аппаратную команду). Появился конвейер, многомерная спекуляция с отбрасыванием неудачных веток, предвыборка данных и т.д.
Дальнейшие поколения Cray и Эльбрусов развивали этот подход.
Еще пример.
В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
Здесь уже SIMD сливает.
Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
Как обычно, наиболее общее решение плохо работает для конкретного случая.
V>>Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
V>>http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
S>Эмм, какое отношение ПЛК имеют к бизнес-вычислениям? Или, скажем, к Эльбрусам и VLIW?
Эта тема более общая — отечественные камни как таковые.
Ввиду наличия некоторого инсайда и регулярно удовлетворяемого любопытства, я просто делюсь инфой.
V>>Это как вызов подпрограммы над определёнными структурами данных.
S>Ну, так-то и CMPXCHG — это вызов подпрограммы над определёнными структурами данных.
Аргументом этой команды является указатель на число в памяти и два аргумента в регистрах.
Я бы не назвал простой указатель на число указателем на "определённую структуру данных".
Зато если по одному указателю должно быть ровно 4 числа и по другому указателю ровно 4 числа — это уже примерно оно.
S>Вся "высокоуровневость" SIMD по сравнению со скаляром — это трёхаргументные команды вроде той, что я привёл.
Дело не в трёхаргументности.
Дело в требованиях к лейауту данных в памяти.
Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
Часто это влечёт за собой лишние телодвижения.
Например, по сети приходят фрагментированные пакеты, данные могут быть невыровнены, SIMD непосредственно над данными в памяти уже не катит, требуется предварительное их копирование с выравниванием.
Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
Вы нынешнем 16с содерижтся 16 таких монструозных ядер, в разрабатываемом 32с — 32.
S>Но опять-таки: вот ровно эта тема весьма слабо разработана в академической тусовке, по причине отсутствия поля применения. То есть в тех местах, где классический компилятор детектирует совершенно конкретные паттерны для автовекторизации, а если не смог — то развёртывает цикл и полагается на CPU, эльбрусовский должен не просто развернуть цикл, но и суметь раскидать результат развёртки по VLIW-инструкциям.
Всё так.
Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
Плюс развивается либа по высокоэффективным вычислениям, конечно:
Есть еще специфическая фишка Эльбрусов — это буфер подкачки данных.
В чём там суть?
На классических камнях есть кеши инструкций и данных, на Эльбрусе тоже есть.
Однако, мультимедиа-операции плохо ложатся на кеш данных, т.к. данные эти требуются лишь однократно.
На этих операция вычисление над большими массивами данных лишь делает кеш инвалидным, вытесняя необходимые данные из некоей логики, к которым (данным) требуется периодическое повторное обращение.
Для решения этой проблемы в процессор добавили специальный буфер подкачки данных, который работает достаточно прозрачно.
Идея такова, что компилятор самостоятельно или программист через инстистики раскидывает инструкции-подсказки относительно подкачки требуемых данных, а затем при обращении к данным по подкачанным адресам, обращение к таким данным происходит уже без задержки. И без инвалидации полезных данных в кеше.
Вот ребята поугорали, случайно столкнувшись с этим:
http://personeltest.ru/category-10114-e2k.html
Если говорить о случайной нагрузке небольшими блоками, то:
с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.
...
А вот в последовательной нагрузке большими блоками картина прямо противоположная:
оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.
V>>Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
S>Не "можно", а "нужно". Это не так просто сделать, как трепаться на форуме.
Неужели у тебя претензии лично ко мне? ))
Конечно, под Эльбрус есть математические библиотеки, сведены в EML:
http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter7.html
"7.4.2. Умножение матриц" Время выполнения программы умножения матриц Интел | Эльбрус | Эльбрус + eml ------------------------------------ 316.82 | 1206.92 | 14.69
S>У компилятора всё ещё хуже: данных для предсказания ветвлений у него просто нет.
Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
V>>В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
S>И перестали потому, что не смогли в компилятор, способный принимать решения лучше железки.
Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
EPIC не означает отмены OoO, спекулятивности и предсказания ветвлений.
Он просто делает эти же техники кратно эффективнее в пересчёте на целевые вычисления.
V>>И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
S>О, пошла знаменитая аналитика от Вдимас. Да, я помню, что Билл Гейтс — неудачник.
Наоборот, один из удачников.
S>А Интел — сплошной фейк. Вот то ли дело МЦСТ!
Смена последних поколений архитектуры — фейк.
Архитектура та же.
V>>Тупик происходит уже 10-й год.
S>
Нам до того тупика — ещё сорок вёрст с поворотами.Это смотря по какой причине тупик.
Если по причине объективного достижения некоей точки насыщения современных технологий — то отнюдь.
Например, 32с разводят под 6нм техпроцесс.
Бо насыщение-с...
Большая разница на оси X (время) начинает слабо влиять на ось Y (результат).
В итоге через единицы лет это отставание станет непринципиальным.
И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
А пока что будущее ближайших единиц лет более чем прозрачно.