Сообщение Re[22]: .Net на эльбрусах от 22.08.2022 15:07
Изменено 22.08.2022 15:14 vdimas
Re[22]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Допустим, у тебя не 4*4 упакованных числа, а 6*6.
V>>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
S>А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
Потому что нет смысла.
На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
S>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
Это и есть 4*4.
Т.е. ситуация такова — по мере расширения возможностей суперскаляра в деле распараллеливания вычислений и добавления вычислительных блоков, становится возможным утилизировать новые вычислительные мощности в том числе через явные SIMD команды большей размерности.
S>И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
S>Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
V>>Еще пример.
V>>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
V>>Здесь уже SIMD сливает.
S>Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме. Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
V>>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
S>И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
Нельзя одним тактом выполнить квадратичную интерполяцию.
V>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
S>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
Минимум 6 за такт.
Но могу и ошибаться, тогда 18-24.
V>>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
S>В SIMD ветвления делаются не так
В Эльбрусе ветвления бывают разные еще с той самой первой изначальной архитектуры на дискретных элементах.
Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
В современных GPU используется такой же подход.
V>>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
S>Надо щупать руками.
Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
Разница во многие разы всегда.
V>>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
S>Это везде так. Чудес-то не бывает.
Угу, бывает формулировка ТЗ и его исполнение инженерами в железе.
V>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
S>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
Та не...
Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
V>>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
S>Воот. А всего один пост назад интринсики SIMD были позорищем
Реализация через инстистики — зло, т.к. компилятор не заменит автоматом вручную указанные инструкции в следующих стандартах SIMD.
Речь шла о подсказках компилятору, которые работают даже для традиционных архитектур.
Подсказки навроде таких:
https://docs.microsoft.com/en-us/cpp/preprocessor/loop?view=msvc-170
Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
V>>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
S>Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Либы дают быстрый старт, разумеется.
Но не всегда библиотечное решение наилучшее для конкретного сценария, тут всё по классике.
S>Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
S>Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
В деле вычислений давно устоялся стандарт BLAS.
Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Где можно про этот буфер почитать? Каков его размер?
Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных".
Например:
https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
V>>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
S>Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
Ну мы же не знаем, как драйвер диска и файловой подсистемы написан.
Вероятнее всего, активно использует технологию предварительной подкачки данных.
Потому что чудес же не бывает, а выглядит как чудо.
V>>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
S>Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Библиотека EML дала прирост в 100 раз.
Обе цифры показывают как наличие фактора капризности, так и наличие путей решения этих капризов. ))
V>>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
S>Ну, если у них конвеер коротки — то почему нет.
Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO, просто заход к проблеме с другой стороны.
V>>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
S>Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
Что значит "только выкатила"?
Архитектуре ARM 30 лет уже.
Планшеты, ноуты и т.д. на ARM-е заполонили давно.
Даже MS выпустила свои Windows-планшеты на ARM-ах фиг его знает когда.
Т.е. экосистема там давно натоптана, тем более у Apple.
S>В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
S>Не было у итаниумов никакого решающего преимущества на практике.
В первых версиях Итаницмы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
Но они были дороже топовых Ксеонов, в этом была ошибка.
Из-за большего спроса на AMD64-архитектуру Интел была вынуждена тратить ресурсы на эту линейку процов, что Итаниумы стали постепенно отставать.
На них тупо забили, так это выглядело.
Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
V>>И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
V>>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
S>У них основной козырь — это отлаженный конвеер разработки.
Который буксует уже 10-й год?
Два супердорогих провальных проекта — P4 и Itanium.
Текущую ветку Core разработала израильская небольшая команда на основе ядра 3-го пня.
И вот вся большая Интел была вынуждена переключиться на небольшой проект израильской команды, которые разрабатывали энергически менее прожорливые процы на основе старого ядра...
И теперь это их мейнстримовая линейка.
Ребят, это приплызд, на самом-то деле.
S>Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Да тоже не ахти.
У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Просто чуть позже, чем Интел.
S>Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia.
Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Нужна привычная модель вычислений, но чтобы результат при этом получался "сам по себе". ))
Но так-то да, GPU давно и уверенно шагают к тому моменту, когда перестанут нуждаться в центральном процессоре.
Выглядит так, что они с Эльбрусом забираются на вершину одной и той же горы, просто разными тропами.
Но на вершине встретятся обязательно.
S>Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
Нужно, просто страшно поддерживать.
Например мы не поддерживаем.
Ситуация простая — из-за попадания десктопной и серверной ниши в область насыщения, сегодняшнее железо живёт слишком долго.
Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
Любые обращения к облакам всё более зашифрованы.
Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
V>>А пока что будущее ближайших единиц лет более чем прозрачно.
S>У вас в слове "призрачно" опечатка.
Готов поставить?
Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
Скучно... ))
S>Здравствуйте, vdimas, Вы писали:
V>>Допустим, у тебя не 4*4 упакованных числа, а 6*6.
V>>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
S>А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
Потому что нет смысла.
На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
S>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
Это и есть 4*4.
Т.е. ситуация такова — по мере расширения возможностей суперскаляра в деле распараллеливания вычислений и добавления вычислительных блоков, становится возможным утилизировать новые вычислительные мощности в том числе через явные SIMD команды большей размерности.
S>И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
S>Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
V>>Еще пример.
V>>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
V>>Здесь уже SIMD сливает.
S>Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме. Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
V>>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
S>И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
Нельзя одним тактом выполнить квадратичную интерполяцию.
V>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
S>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
Минимум 6 за такт.
Но могу и ошибаться, тогда 18-24.
V>>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
S>В SIMD ветвления делаются не так
В Эльбрусе ветвления бывают разные еще с той самой первой изначальной архитектуры на дискретных элементах.
Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
В современных GPU используется такой же подход.
V>>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
S>Надо щупать руками.
Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
Разница во многие разы всегда.
V>>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
S>Это везде так. Чудес-то не бывает.
Угу, бывает формулировка ТЗ и его исполнение инженерами в железе.
V>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
S>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
Та не...
Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
V>>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
S>Воот. А всего один пост назад интринсики SIMD были позорищем
Реализация через инстистики — зло, т.к. компилятор не заменит автоматом вручную указанные инструкции в следующих стандартах SIMD.
Речь шла о подсказках компилятору, которые работают даже для традиционных архитектур.
Подсказки навроде таких:
https://docs.microsoft.com/en-us/cpp/preprocessor/loop?view=msvc-170
Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
V>>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
S>Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Либы дают быстрый старт, разумеется.
Но не всегда библиотечное решение наилучшее для конкретного сценария, тут всё по классике.
S>Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
S>Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
В деле вычислений давно устоялся стандарт BLAS.
Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Где можно про этот буфер почитать? Каков его размер?
Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных".
Например:
https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
V>>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
S>Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
Ну мы же не знаем, как драйвер диска и файловой подсистемы написан.
Вероятнее всего, активно использует технологию предварительной подкачки данных.
Потому что чудес же не бывает, а выглядит как чудо.
V>>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
S>Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Библиотека EML дала прирост в 100 раз.
Обе цифры показывают как наличие фактора капризности, так и наличие путей решения этих капризов. ))
V>>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
S>Ну, если у них конвеер коротки — то почему нет.
Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO, просто заход к проблеме с другой стороны.
V>>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
S>Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
Что значит "только выкатила"?
Архитектуре ARM 30 лет уже.
Планшеты, ноуты и т.д. на ARM-е заполонили давно.
Даже MS выпустила свои Windows-планшеты на ARM-ах фиг его знает когда.
Т.е. экосистема там давно натоптана, тем более у Apple.
S>В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
S>Не было у итаниумов никакого решающего преимущества на практике.
В первых версиях Итаницмы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
Но они были дороже топовых Ксеонов, в этом была ошибка.
Из-за большего спроса на AMD64-архитектуру Интел была вынуждена тратить ресурсы на эту линейку процов, что Итаниумы стали постепенно отставать.
На них тупо забили, так это выглядело.
Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
V>>И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
V>>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
S>У них основной козырь — это отлаженный конвеер разработки.
Который буксует уже 10-й год?
Два супердорогих провальных проекта — P4 и Itanium.
Текущую ветку Core разработала израильская небольшая команда на основе ядра 3-го пня.
И вот вся большая Интел была вынуждена переключиться на небольшой проект израильской команды, которые разрабатывали энергически менее прожорливые процы на основе старого ядра...
И теперь это их мейнстримовая линейка.
Ребят, это приплызд, на самом-то деле.
S>Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Да тоже не ахти.
У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Просто чуть позже, чем Интел.
S>Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia.
Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Нужна привычная модель вычислений, но чтобы результат при этом получался "сам по себе". ))
Но так-то да, GPU давно и уверенно шагают к тому моменту, когда перестанут нуждаться в центральном процессоре.
Выглядит так, что они с Эльбрусом забираются на вершину одной и той же горы, просто разными тропами.
Но на вершине встретятся обязательно.
S>Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
Нужно, просто страшно поддерживать.
Например мы не поддерживаем.
Ситуация простая — из-за попадания десктопной и серверной ниши в область насыщения, сегодняшнее железо живёт слишком долго.
Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
Любые обращения к облакам всё более зашифрованы.
Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
V>>А пока что будущее ближайших единиц лет более чем прозрачно.
S>У вас в слове "призрачно" опечатка.
Готов поставить?
Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
Скучно... ))
Re[22]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Допустим, у тебя не 4*4 упакованных числа, а 6*6.
V>>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
S>А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
Потому что нет смысла.
На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
S>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
Это и есть 4*4.
Т.е. ситуация такова — по мере расширения возможностей суперскаляра в деле распараллеливания вычислений и добавления вычислительных блоков, становится возможным утилизировать новые вычислительные мощности в том числе через явные SIMD команды большей размерности.
S>И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
S>Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
V>>Еще пример.
V>>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
V>>Здесь уже SIMD сливает.
S>Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме. Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
V>>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
S>И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
Нельзя одним тактом выполнить квадратичную интерполяцию.
V>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
S>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
Минимум 6 за такт.
Но могу и ошибаться, тогда 18-24.
V>>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
S>В SIMD ветвления делаются не так
В Эльбрусе ветвления бывают разные еще с той самой первой изначальной архитектуры на дискретных элементах.
Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
В современных GPU используется такой же подход.
V>>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
S>Надо щупать руками.
Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
Разница во многие разы всегда.
V>>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
S>Это везде так. Чудес-то не бывает.
Угу, бывает формулировка ТЗ и его исполнение инженерами в железе.
V>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
S>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
Та не...
Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
V>>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
S>Воот. А всего один пост назад интринсики SIMD были позорищем
Реализация через инстистики — зло, т.к. компилятор не заменит автоматом вручную указанные инструкции в следующих стандартах SIMD.
Речь шла о подсказках компилятору, которые работают даже для традиционных архитектур.
Подсказки навроде таких:
https://docs.microsoft.com/en-us/cpp/preprocessor/loop?view=msvc-170
Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
V>>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
S>Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Либы дают быстрый старт, разумеется.
Но не всегда библиотечное решение наилучшее для конкретного сценария, тут всё по классике.
S>Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
S>Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
В деле вычислений давно устоялся стандарт BLAS.
Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Где можно про этот буфер почитать? Каков его размер?
Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных".
Например:
https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
V>>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
S>Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
Ну мы же не знаем, как драйвер диска и файловой подсистемы написан.
Вероятнее всего, активно использует технологию предварительной подкачки данных.
Потому что чудес же не бывает, а выглядит как чудо.
V>>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
S>Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Библиотека EML дала прирост в 100 раз.
Обе цифры показывают как наличие фактора капризности, так и наличие путей решения этих капризов. ))
V>>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
S>Ну, если у них конвеер коротки — то почему нет.
Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO + предсказание ветвлений, просто заход к проблеме с другой стороны.
V>>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
S>Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
Что значит "только выкатила"?
Архитектуре ARM 30 лет уже.
Планшеты, ноуты и т.д. на ARM-е заполонили давно.
Даже MS выпустила свои Windows-планшеты на ARM-ах фиг его знает когда.
Т.е. экосистема там давно натоптана, тем более у Apple.
S>В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
S>Не было у итаниумов никакого решающего преимущества на практике.
В первых версиях Итаницмы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
Но они были дороже топовых Ксеонов, в этом была ошибка.
Из-за большего спроса на AMD64-архитектуру Интел была вынуждена тратить ресурсы на эту линейку процов, что Итаниумы стали постепенно отставать.
На них тупо забили, так это выглядело.
Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
V>>И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
V>>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
S>У них основной козырь — это отлаженный конвеер разработки.
Который буксует уже 10-й год?
Два супердорогих провальных проекта — P4 и Itanium.
Текущую ветку Core разработала израильская небольшая команда на основе ядра 3-го пня.
И вот вся большая Интел была вынуждена переключиться на небольшой проект израильской команды, которые разрабатывали энергически менее прожорливые процы на основе старого ядра...
И теперь это их мейнстримовая линейка.
Ребят, это приплызд, на самом-то деле.
S>Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Да тоже не ахти.
У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Просто чуть позже, чем Интел.
S>Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia.
Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Нужна привычная модель вычислений, но чтобы результат при этом получался "сам по себе". ))
Но так-то да, GPU давно и уверенно шагают к тому моменту, когда перестанут нуждаться в центральном процессоре.
Выглядит так, что они с Эльбрусом забираются на вершину одной и той же горы, просто разными тропами.
Но на вершине встретятся обязательно.
S>Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
Нужно, просто страшно поддерживать.
Например мы не поддерживаем.
Ситуация простая — из-за попадания десктопной и серверной ниши в область насыщения, сегодняшнее железо живёт слишком долго.
Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
Любые обращения к облакам всё более зашифрованы.
Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
V>>А пока что будущее ближайших единиц лет более чем прозрачно.
S>У вас в слове "призрачно" опечатка.
Готов поставить?
Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
Скучно... ))
S>Здравствуйте, vdimas, Вы писали:
V>>Допустим, у тебя не 4*4 упакованных числа, а 6*6.
V>>В этом случае VLIW может в одной инструкции выполнить 4*4 над упакованными данными и еще 2*2 над неупакованными.
S>А мы сразу предполагаем, что в VLIW вычислительных блоков больше, чем в SIMD? Почему?
Потому что нет смысла.
На остальных вычислениях суперскаляр не нагрузит эффективно простаивающие вычислительные блоки.
S>К примеру, AVX-512 может обработать 8 упакованных double за одну операцию.
Это и есть 4*4.
Т.е. ситуация такова — по мере расширения возможностей суперскаляра в деле распараллеливания вычислений и добавления вычислительных блоков, становится возможным утилизировать новые вычислительные мощности в том числе через явные SIMD команды большей размерности.
S>И никто не запрещает в суперскаляре параллелить две идущих подряд инструкции, которые складывают между собой соседние вектора из 4х даблов — они же не пересекаются по данным.
S>Опять же, с неупакованностью есть команды scatter/gather для явной подгрузки, я так понимаю — это аналог эльбрусовского LOAD.
Но нет команд одновременного сложения/умножения нескольких пар чисел из регистров, это даётся на откуп скалярному OoO и там как повезёт.
V>>Еще пример.
V>>В операциях разложения тригонометрии или корней в ряд добавляются степенные ф-ии, т.е. требуется более одного накопительного регистра (где еще будет накапливаться степень числа).
V>>Здесь уже SIMD сливает.
S>Пока непонятно, в чём именно проблема. Есть несколько способов работать с полиномами в SIMD.
Проблема в том, что многие алгоритмы вычисления многочленов плохо ложатся на FMA3, который в мейнстриме. Когда-то AMD добавила FMA4, но не зашло. Синусы-косинусы и проч квадратные современные процы считают через табличную интерполяцию. Но это ограниченный набор ф-ий. Иногда нужны произвольные многочлены.
V>>Если делать эти же вычисления на квадратичной аппроксимации по предвычисленной таблице, то характер таких вычислений тоже плохо ложится на SIMD, но всё еще хорошо на VLIW.
S>И опять непонятно, в чём именно проблема аппроксимацией по таблице в SIMD.
Нельзя одним тактом выполнить квадратичную интерполяцию.
V>>Еще в таких вычислениях популярна операция ограничения уровня сигнала, в Эльбрусах есть инструкци fmax/fmin, а это тоже ужасная для традиционных архитектур операция, т.к. делается через сравнение+ветвление и т.д.
S>Ничего ужасного. Инструкций будет не одна, а три, а вот быстродействие я бы померил. Сколько тактов делается эльбрусовский fmax/fmin?
Минимум 6 за такт.
Но могу и ошибаться, тогда 18-24.
V>>В общем, "числомолотилка" — это не только и не столько про кол-во умножений/делений за такт, но и про то, насколько хорошо требуемые вычисления ложатся на архитектуру вычислительного ядра. Толку от кучи умножений за такт на тех же x86-х, если 90% инструкций цикла будут заниматься тусованием данных туда-сюда по регистрам и содержать лишние ветвления?
S>В SIMD ветвления делаются не так
В Эльбрусе ветвления бывают разные еще с той самой первой изначальной архитектуры на дискретных элементах.
Например, есть условный пропуск инструкции по ранее сохранённому предикату, что делает эффективной реализацию тринарного оператора ?:.
В современных GPU используется такой же подход.
V>>Понятно, что внутреннее переименование регистров, устранение т.н. "ложных зависимостей м/у регистрами", спекулятивность/предсказание часть этой мышиной возни убирают, но как показывают HPC тесты — только часть.
S>Надо щупать руками.
Я опираюсь на доступные в интернете тесты, про высоконагруженные вычисления везде одно и то же — Эльбрус оччень неплох, в сравнении с Интел.
Разница во многие разы всегда.
V>>Т.е., чтобы SIMD хорошо работал, данные в памяти надо расположить определённым образом.
S>Это везде так. Чудес-то не бывает.
Угу, бывает формулировка ТЗ и его исполнение инженерами в железе.
V>>С некоторой вероятностью даже не тупое копирование, а раскидывание данных из сетевого пакета в отдельные буфера.
V>>Зато VLIW может совместить в одной команде предварительную подгрузку невыровненных данных для последующей операции и вычисления над загруженными на предыдущей операции данными с эффективностью SIMD. Разве что с кратной эффективностью, бо это как несколько векторных инструкций SIMD за такт. ))
S>Не очень понятно, как это так получится, и что помешает суперскаляру исполнять несколько SIMD за такт при тех же вводных.
Максимальная по ширине FMA или dot product инструкция — это и есть максимум того, что может выполнить суперскаляр за такт.
S>Проблема с невыровненными данными типа разбора сетевых пакетов, HTTP хидеров или XML/JSON разметки — в том, что мы не знаем, насколько от текущего поинтера надо прыгать (= адрес, откуда грузить), пока не обработаем текущие данные). Пока мне непонятно, как эльбрус собирается это обойти. А если эльбрус это обходит, то точно также это обходит Интел при помощи развёртки цикла и использования регистрового банка для забивания конвеера.
Та не...
Мне резало глаза от твоей "векторизации" применительно к Эльбрусу из-за сужения понятий.
Спецификация SIMD представлена как вычисления над последовательностями чисел, а эффективность происходит из-за де-факто параллельных вычислений.
VLIW — это тоже способ организации параллельных вычислений, просто чуть другой, местами более универсальный.
V>>Но этому компилятору можно много чего подсказывать в прагмах и через интристики.
S>Воот. А всего один пост назад интринсики SIMD были позорищем
Реализация через инстистики — зло, т.к. компилятор не заменит автоматом вручную указанные инструкции в следующих стандартах SIMD.
Речь шла о подсказках компилятору, которые работают даже для традиционных архитектур.
Подсказки навроде таких:
https://docs.microsoft.com/en-us/cpp/preprocessor/loop?view=msvc-170
Для Эльбруса есть еще специфические — про предварительную подкачку данных и про подготовку к эффективному ветвлению/переходу.
V>>Плюс развивается либа по высокоэффективным вычислениям, конечно: EML.
S>Да, это как раз и есть более-менее проверенный путь работы для всяких экзотических архитектур — разработка DSL. В виде, к примеру, библиотек.
Либы дают быстрый старт, разумеется.
Но не всегда библиотечное решение наилучшее для конкретного сценария, тут всё по классике.
S>Технология работы, с одной стороны, проще — сиди себе да выписывай интринсики, меняй раскладку данных, и т.п. "Глубина" работы меньше, чем для AOT и JIT компиляторов.
S>Зато "ширина" гораздо больше — то есть нам опять нужны сотни команд и десятки тысяч вовлечённых людей, чтобы оперативно покрыть весь спектр применений.
В деле вычислений давно устоялся стандарт BLAS.
Последние лет ~15 аспирантура активно использует тот же Питон с обертками над нейтивными либами по этому стандарту для игрищ с большими вычислениями.
Для Эльбруса это всё доступно изначально как часть стандартной поставки их Линухов (ОС Эльбрус).
S>Где можно про этот буфер почитать? Каков его размер?
Размер в процессоре Эльбрус 4с был 4 КБ на ядро, сейчас не в курсе.
Технология эта не является уникальной для Эльбруса, гуглить по "асинхронная подкачка данных".
Например:
https://vk.com/@kawaiipc-ustroistvo-obrascheniya-k-massivam
V>>Вот ребята поугорали, случайно столкнувшись, скорее всего, именно с этим:
S>Хм. Ребята измеряли работу с диском, а не с памятью. Поэтому сильно сомневаюсь, что там буфера уровня L0/L1 дадут какой-то хороший коэффициент. Надо профилировать.
Ну мы же не знаем, как драйвер диска и файловой подсистемы написан.
Вероятнее всего, активно использует технологию предварительной подкачки данных.
Потому что чудес же не бывает, а выглядит как чудо.
V>>Всего-то в 20 раз быстрее матрица перемножилась. Какой пустяк...
S>Относительно практически невекторизованной версии-то? А если скормить эту матрицу настоящей взрослой библиотеке с оптимизацией под AVX2?
Я рядом говорил — примерно в 10 раз ускорение от наихудшей наивной реализации.
У Эльбруса там у автора получилось ускорить в 200 раз от наивной реализации.
Библиотека EML дала прирост в 100 раз.
Обе цифры показывают как наличие фактора капризности, так и наличие путей решения этих капризов. ))
V>>Поэтому у Эльбруса со спекулятивным исполнением всё неплохо.
S>Ну, если у них конвеер коротки — то почему нет.
Дело еще в другом — у них не потрачено так много транзиторов на суперскалярные вычисления над потоком исполнения.
Поэтому они позволили себе нехилую многомерную спекулятивность, т.е. когда потенциальные ветвления порождают опять потенциальные ветвления, т.е. размерность потенциальных состояний растёт. Т.е., это примерно то же, для чего служит OoO + предсказание ветвлений, просто заход к проблеме с другой стороны.
V>>Не поэтому, а потому что рыночек порешал со своей инерцией и нежеланием платить больше ради светлого будущего. ))
S>Никакой инерции. Смотрите — вот Apple только что выкатила компьютеры на M1, и рыночек решительно закупает их большими тиражами.
Что значит "только выкатила"?
Архитектуре ARM 30 лет уже.
Планшеты, ноуты и т.д. на ARM-е заполонили давно.
Даже MS выпустила свои Windows-планшеты на ARM-ах фиг его знает когда.
Т.е. экосистема там давно натоптана, тем более у Apple.
S>В том-то и дело, что никакого светлого будущего не наступило — не получилось написать компилятор, который бы смог эффективно загрузить итаниум прикладной нагрузкой.
S>Не было у итаниумов никакого решающего преимущества на практике.
В первых версиях Итаницмы не отставали в целочисленных вычислениях и резко опережали в вещественных числомолотилках.
Но они были дороже топовых Ксеонов, в этом была ошибка.
Из-за большего спроса на AMD64-архитектуру Интел была вынуждена тратить ресурсы на эту линейку процов, что Итаниумы стали постепенно отставать.
На них тупо забили, так это выглядело.
Им надо было отдавать их, наоборот, дешевле, "подсаживая" отрасль на эту архитектуру.
V>>И это неотвратимо, если насыщение технологий объективно, а не исскуственно.
V>>Если же у Интел есть какой-нить припасённый козырь в кармане, который она достанет как только ей наступят на пятки — тогда и будем смотреть.
S>У них основной козырь — это отлаженный конвеер разработки.
Который буксует уже 10-й год?
Два супердорогих провальных проекта — P4 и Itanium.
Текущую ветку Core разработала израильская небольшая команда на основе ядра 3-го пня.
И вот вся большая Интел была вынуждена переключиться на небольшой проект израильской команды, которые разрабатывали энергически менее прожорливые процы на основе старого ядра...
И теперь это их мейнстримовая линейка.
Ребят, это приплызд, на самом-то деле.
S>Главная угроза для них — доминирующее положение на рынке. Сейчас эту угрозу эффективно устраняет AMD
Да тоже не ахти.
У них тоже был рывок (низкий старт), теперь тоже в насыщение попали.
Просто чуть позже, чем Интел.
S>Но для этого нужно пахать и пахать. Да, гигафлопсы на такт у него убедительные для перемножения матриц. Но сейчас нейронки мало обучают на гражданских CPU — всё больше делегируют в видеокарты. То есть в HPC придётся соревноваться не с ксеонами, а с NVidia.
Там угрёбищная модель вычислений, много приседаний и отвлечения внимания не на то.
Нужна привычная модель вычислений, но чтобы результат при этом получался "сам по себе". ))
Но так-то да, GPU давно и уверенно шагают к тому моменту, когда перестанут нуждаться в центральном процессоре.
Выглядит так, что они с Эльбрусом забираются на вершину одной и той же горы, просто разными тропами.
Но на вершине встретятся обязательно.
S>Неспроста AVX512 так плохо идёт: нахрен никому не нужно.
Нужно, просто страшно поддерживать.
Например мы не поддерживаем.
Ситуация простая — из-за попадания десктопной и серверной ниши в область насыщения, сегодняшнее железо живёт слишком долго.
Если в 90-е гды можно было не рассматривать во многих нишах процы, допустим, 4-хлетней давности, то сегодня приходится брать во внимание процы даже 10-тилетней давности, увы.
S>А вот быстрое выполнение гражданского софта — те самые микросервисы в облаке — это то, за что народ готов платить деньги.
Любые обращения к облакам всё более зашифрованы.
Вот как раз Эльбрус по нашим ГОСТ-ам шифрует в разы быстрее x86-х.
V>>А пока что будущее ближайших единиц лет более чем прозрачно.
S>У вас в слове "призрачно" опечатка.
Готов поставить?
Или есть что-то, чего я не знаю? Т.е. У Интел есть какой-то скрытый козырь в рукаве?
Если нет, если развитие процессоров будет идти так же, как шло последние 10 лет — то там всё ясно уже.
За очередные лет 10 получишь еще 30-40% прибавки эффективности на ядро на частоту, ну и частота вырастет процентов на 20-25.
Скучно... ))