Конечно, это простейший вариант, позволяющий только в пределе протестировать числовую ось. Тем не менее, даже он гораздо лучше широко распространенного подхода с тестированием на конечном предопределенном наборе точек.
Про математические методы доказательства -- лично для меня тоже гораздо интереснее, данная статья скорее для общего понимания у широкой аудитории.
Не совсем. В Wolfram Mathematica функция PadeApproximant[Cos[x], {x, 0, {5, 6}}] строит аппроксимацию в точке, а не на отрезке. Какой именно внутри алгоритм, никто из близких к разработчикам Wolfram знакомых подсказать не смог, поэтому решили проверить по Maple: результат оказывается таким же, как у функции pade(...) в Maple, и заметно отличается от chebpade(...) из того же Maple.
А вот если в Wolfram использовать MiniMaxApproximation[Cos[x], {x, {0, 1}, 5, 6}], то Вы получите аппроксимацию именно на отрезке, с минимизацией максимального расхождения между функцией и аппроксимантом в наборе точек. Сам этот набор точек похож на узлы чебышевской сетки, но только похож.
Согласна, тяжело найти баланс между текстом "для общей эрудиции" и чем-то посерьезнее. Если хочется почитать коротко именно о минимаксах, можно глянуть статью. Если же хочется "проникнуться" до конца, то тут, конечно же, рекомендую классику -- Jean-Michel Muller "Elementary Functions".
Спасибо за интересную информацию! Не знала про использование в космических миссиях. Это решение на базе SiFive x280 c кастомным интегрированным матричным расширением RISC-V, в конце предыдущего текста был его обзор.
Они уже добавили поэлементные для int32 и int64, но пока это все на qemu, нельзя оценить, что будет выгоднее. О слиянии расширений в настоящее время ничего на глаза не попадалось.
По моделям с квантизацией: дополнила заключение обзора сводной таблицей по существующим матричным расширениям -- поддержка int8 у всех заявлена.
Про активационные функции (softmax, sigmoid) -- используется векторизация, про max-pooling (сжатие) -- планируется в следующих версиях независимого матричного расширения T-Head (в статье говорится, что со временем его планируют развить до полноценного AI Matrix++ Extension, поддерживающего широкий спектр AI-специфичных матричных операция).
Да, конечно, поддержка расширения не обязана быть во всех абсолютно процессорах. Но тот же инференс является актуальной нагрузкой не только для серверных процессоров: умная клавиатура, голосовые помощники, фотокамера с AI-эффектами, расшифровка голосовых заметок и т.д.
Могу привести пример достаточно бюджетной платы Banana Pi BPI-F3 с 8-ядерным процессором SpacemiT K1 RISC-V (ближе к концу предыдущего текста говорилось о ней): все 8 ядер с векторным расширением RISC-V RVV 1.0, половина ядер с кастомным матричным раcширением RISC-V SpacemiT IME.
Отличный вопрос, если какие-то математические детали неясны -- не стесняйтесь спрашивать!
В начале статьи кратко были описаны идеи многоуровневого блокирования из статьи Goto&Geijn: большие матрицы в несколько этапов разбиваются на маленькие блоки. И вы аккумулируете результаты умножения этих блоков. Ведь что такое элемент матрицы-произведения? Это сумма произведений элементов строки первого сомножителя на соответствующие элементы столбца второго сомножители. А раз это сумма, то вы можете просуммировать не все сразу, а частями -- идя по подстрокам и подстолбцам.
Есть чуть более хитрый подход, когда вместо скалярного произведения используется внешнее -- тогда аккумулируются не отдельные элементы, а целые блоки. Подробнее о нем я расскажу в следующем тексте. А в последнем тексте будет детально рассмотрен пример реализации такого алгоритма.
Возможно в тексте немного затерялось -- я инженер-математик по образованию, призванию и роду деятельности), т.е. применительно к этим расширениям я -- пользователь, а не разработчик. Ускорители я никогда не проектировала и не проектирую, но, как математика-прикладника, меня, конечно же, интересует, что есть в этой области, чего ждать.
Думаю, разработчики железа проводили исследования, о которых вы упоминали, ведь те же Apple M1--4 не только для инференса и коррекции фото используются, но статьи о серьезных просадках производительности на других приложениях мне не попадались, пока я исследовала данную тему.
Даже для высокой скорости не всегда нужен отдельный вычислитель: в свежем июньском Top500 далеко не все машины гетерогенные, тот же Fujitsu Fugaku (ядра A64FX) до сих пор находится в топ-5. В инфографике можно посмотреть сравнение c ускорителями, правда 2021 г., но интересно.
Разработка таких расширений включает в себя не только аппаратную часть, но и большую работу со стеком ПО: помимо оптимизаций математических библиотек, это в том числе и организация поддержки расширения в ядре Linux (детекция наличия/отсутствия расширения, указание режима его работы, флаги используемых регистров для оптимизации переключения контекста и т.д.). Например, краткое описание в документации для Arm SME (понятно, что это не все "внутренности", а только минимальная видимая часть).
Активная работа расширения происходит только во время решения вычислительных задач, для которых эти матричные операции -- серьезные хотспоты (до 90% времени работы приложений, о которых говорилось в тексте, может уходить на матричное умножение, например). Получаемое в итоге ускорение компенсирует возросшие накладные расходы -- на практике по сравнению с векторизацией минимум в 2 раза ускорение получается.
Что оптимальнее -- расширение cpu или отдельный блок -- здесь нет однозначного ответа: есть примеры удачных решений как первой категории, так и второй. Тот же упомянутый в статье гомогенный Fujitsu Fugaku.
Раз вы были непосредственным участником, может быть, вы могли бы поделиться инсайдами? Было бы интересно узнать:
В чём именно заключалась "тухлость подхода" на практике?
Проблемы были в стандартных расширениях ISA, в каких-то конкретных кастомных или же в чем-то еще?
В публичных анонсах ET-SoC-1 было что-то интересное -- 1088 ядер, 158 Infer/sec/Watt на ResNet-50 (int8). Реальность сильно расходилась с анонсами?
посмотрите, например, на разработки tenstorrent (это навскидку, список можно долго продолжать)
Конечно, это простейший вариант, позволяющий только в пределе протестировать числовую ось. Тем не менее, даже он гораздо лучше широко распространенного подхода с тестированием на конечном предопределенном наборе точек.
Про математические методы доказательства -- лично для меня тоже гораздо интереснее, данная статья скорее для общего понимания у широкой аудитории.
Не совсем. В Wolfram Mathematica функция
PadeApproximant[Cos[x], {x, 0, {5, 6}}]строит аппроксимацию в точке, а не на отрезке. Какой именно внутри алгоритм, никто из близких к разработчикам Wolfram знакомых подсказать не смог, поэтому решили проверить по Maple: результат оказывается таким же, как у функцииpade(...)в Maple, и заметно отличается отchebpade(...)из того же Maple.А вот если в Wolfram использовать
MiniMaxApproximation[Cos[x], {x, {0, 1}, 5, 6}], то Вы получите аппроксимацию именно на отрезке, с минимизацией максимального расхождения между функцией и аппроксимантом в наборе точек. Сам этот набор точек похож на узлы чебышевской сетки, но только похож.Согласна, тяжело найти баланс между текстом "для общей эрудиции" и чем-то посерьезнее. Если хочется почитать коротко именно о минимаксах, можно глянуть статью. Если же хочется "проникнуться" до конца, то тут, конечно же, рекомендую классику -- Jean-Michel Muller "Elementary Functions".
В тексте речь идет не о векторном расширении, а о матричном. С910, о котором вы пишете, матричное расширение не содержит.
Спасибо за интересную информацию! Не знала про использование в космических миссиях. Это решение на базе SiFive x280 c кастомным интегрированным матричным расширением RISC-V, в конце предыдущего текста был его обзор.
да, поэтому вряд ли будет слияние векторного и матричного расширения в одно
Они уже добавили поэлементные для int32 и int64, но пока это все на qemu, нельзя оценить, что будет выгоднее. О слиянии расширений в настоящее время ничего на глаза не попадалось.
По моделям с квантизацией: дополнила заключение обзора сводной таблицей по существующим матричным расширениям -- поддержка int8 у всех заявлена.
Про активационные функции (softmax, sigmoid) -- используется векторизация, про max-pooling (сжатие) -- планируется в следующих версиях независимого матричного расширения T-Head (в статье говорится, что со временем его планируют развить до полноценного AI Matrix++ Extension, поддерживающего широкий спектр AI-специфичных матричных операция).
Да, конечно, поддержка расширения не обязана быть во всех абсолютно процессорах. Но тот же инференс является актуальной нагрузкой не только для серверных процессоров: умная клавиатура, голосовые помощники, фотокамера с AI-эффектами, расшифровка голосовых заметок и т.д.
Могу привести пример достаточно бюджетной платы Banana Pi BPI-F3 с 8-ядерным процессором SpacemiT K1 RISC-V (ближе к концу предыдущего текста говорилось о ней): все 8 ядер с векторным расширением RISC-V RVV 1.0, половина ядер с кастомным матричным раcширением RISC-V SpacemiT IME.
Большое спасибо! Я активно искала информацию по теме еще зимой, поэтому не видела ее. Очень интересная!
а, Apple AMX из Apple M1--M3 -- возможно, имелось в виду исследование Дугалла Джонсона, который его как раз и обнаружил, https://gist.github.com/dougallj/7cba721da1a94da725ee37c1e9cd1f21
В M4 не Apple AMX, а Arm SME https://developer.arm.com/documentation/ddi0602/latest/SME-Instructions
Отличный вопрос, если какие-то математические детали неясны -- не стесняйтесь спрашивать!
В начале статьи кратко были описаны идеи многоуровневого блокирования из статьи Goto&Geijn: большие матрицы в несколько этапов разбиваются на маленькие блоки. И вы аккумулируете результаты умножения этих блоков. Ведь что такое элемент матрицы-произведения? Это сумма произведений элементов строки первого сомножителя на соответствующие элементы столбца второго сомножители. А раз это сумма, то вы можете просуммировать не все сразу, а частями -- идя по подстрокам и подстолбцам.
Есть чуть более хитрый подход, когда вместо скалярного произведения используется внешнее -- тогда аккумулируются не отдельные элементы, а целые блоки. Подробнее о нем я расскажу в следующем тексте. А в последнем тексте будет детально рассмотрен пример реализации такого алгоритма.
Возможно в тексте немного затерялось -- я инженер-математик по образованию, призванию и роду деятельности), т.е. применительно к этим расширениям я -- пользователь, а не разработчик. Ускорители я никогда не проектировала и не проектирую, но, как математика-прикладника, меня, конечно же, интересует, что есть в этой области, чего ждать.
Думаю, разработчики железа проводили исследования, о которых вы упоминали, ведь те же Apple M1--4 не только для инференса и коррекции фото используются, но статьи о серьезных просадках производительности на других приложениях мне не попадались, пока я исследовала данную тему.
просто цитата из комментария выше
Если вы сможете провести такие замеры, будет очень интересно посмотреть. Например, Apple M4 c Arm SME или Apple M1--3 c Apple AMX.
Даже для высокой скорости не всегда нужен отдельный вычислитель: в свежем июньском Top500 далеко не все машины гетерогенные, тот же Fujitsu Fugaku (ядра A64FX) до сих пор находится в топ-5. В инфографике можно посмотреть сравнение c ускорителями, правда 2021 г., но интересно.
Разработка таких расширений включает в себя не только аппаратную часть, но и большую работу со стеком ПО: помимо оптимизаций математических библиотек, это в том числе и организация поддержки расширения в ядре Linux (детекция наличия/отсутствия расширения, указание режима его работы, флаги используемых регистров для оптимизации переключения контекста и т.д.). Например, краткое описание в документации для Arm SME (понятно, что это не все "внутренности", а только минимальная видимая часть).
Активная работа расширения происходит только во время решения вычислительных задач, для которых эти матричные операции -- серьезные хотспоты (до 90% времени работы приложений, о которых говорилось в тексте, может уходить на матричное умножение, например). Получаемое в итоге ускорение компенсирует возросшие накладные расходы -- на практике по сравнению с векторизацией минимум в 2 раза ускорение получается.
Что оптимальнее -- расширение cpu или отдельный блок -- здесь нет однозначного ответа: есть примеры удачных решений как первой категории, так и второй. Тот же упомянутый в статье гомогенный Fujitsu Fugaku.
Спасибо, продолжение статьи уже в работе