Средства и методы разработки

Классические пофигу, важно что понимать под DSP сейчас. У меня сложилось впечатление, что не DSP усыхают, а что все прочие их очень быстро догоняют (кое-где практически уже догнали), и только потому специализированные DSP во многих случаев не выдерживают с ними конкуренции по соотношению производительность/цена. Сюда же следует добавить еще и то, что на топовом конце скорость обычных процессоров и микроконтроллеров заметно выросла, а потому в задачах реального времени они стали составлять сильную конкуренцию DSP-процессорам, поскольку множество задач этот типа стало возможно решать, не прибегая к DSP. Заглянула в Википедию по поводу определения, чем DSP-процессоры отличаются от обычных. Из существенных отличий по возможностям (аппаратные реализации рассматривать не хочу) там выделено 4 критерия:

1. Операция «умножение с накоплением» (англ. multiply-accumulate, MAC) (Y = Y + A ? B), где Y, A, B — элементы действительных массивов с автоматическим расчетом адресов элементов массивов и обычно реализована аппаратно и исполняется за один машинный цикл. 2. Аппаратная реализация многократного повторения заданного набора команд, то есть циклы с заранее назначенной длиной без использования счетчиков цикла и команд проверки обнуления счетчика цикла — признака выхода из цикла. 3. Возможность одновременной в одном машинном такте выборки команды и двух операндов для максимально быстрого выполнения команды MAC. Для этого ЦСП имеет несколько портов обращения к памяти (независимых областей памяти, каждая со своим комплектом шин адреса и данных). 4. Поддержка векторно-конвейерной обработки с помощью генераторов адресных последовательностей.

Что касается 1-го пункта, то операций «умножение с накоплением» обзавелись уже многие контроллеры, а особенно те, которые не связаны обещанием выполнять команды за один такт. Да и выполняется этот пункт без особого труда, если не требовать, чтобы он выполнялся так же быстро, как умножение. Вот процессоры даже для ПК (Intel и AMD) и то в последнее время такой командой обзавелись, и исполняются они за один машинный такт. Нарушено лишь требование работать сразу с двумя аргументами из памяти, но реальные тайминги таковы, что в действительности часто оказывается, что отдельная загрузка первого операнда не приводит к задержке исполнения цикла (об этом чуть позже). По 2-ому пункту. В практическом плане аппаратная реализация цикла обычно показывает те же результаты, что и программная. Т.е. чудес не бывает – счетчик оборотов цикла все равно где-то приходится содержать, а при завершении каждого оборота скачком изменять значение указателя выполняемых команд. Поэтому аппаратная реализация цикла мало чем отличается от аппаратной реализации команды LOOP (декремент счетчика, объединенный с условным переходом, если результат не нуль). 3-ий пункт. Двупортовая память до сих пор относится к эксклюзиву. По нынешним временам оперативной памяти требуется много, а потому она, чаще всего, внешняя. А в этом случае пришлось бы удваивать шины адреса и данных. Т.е. несмотря на то, что двупортовая память в природе существует, заставить процессор с ней работать не так-то просто. Поэтому все чаще эта проблема решается обычным кэшированием, а на двупортовости памяти настаивать перестали. Хотя, конечно же, было бы клёво, если бы у памяти было столько же портов с одновременным доступом, сколько ядер у процессора :). 4-ый пункт. Векторно-конвейерная обработка очень близка по идее к SIMD-инструкциям (SSE/AVX/AVX2). По меньшей мере, в последнее время все чаще векторизацию понимают не как быстрый прогон вектора через арифметическое устройство, а как пачку арифметических устройств, синхронно обрабатывающих соседние элементы вектора. А в результате имеет место продвижение вдоль вектора некоего окна, внутри которого операции с каждым элементом выполняются за один и тот же такт. Тем самым произошел коренной переход от супердлинных инструкций (которые в прошлом казались перспективными) к «супердлинному» арифметическому устройству, включая его рабочие регистры. При этом ситуация выглядит так, что арифметическое устройство изначально предназначено для работы с коротким вектором (по возможностям данного процессора), а работа с векторами произвольной длины разбивается на отрезки, равные длине короткого вектора. При этом производительность растет прямо пропорционально длине короткого вектора, который данный процессор считает аппаратно. Я не слишком хорошо представляю внутреннюю кухню работы процессора (за что иногда бываю бита :)), но скорость исполнения циклов с плавающей арифметикой умею измерять экспериментально. Более того – сильно заинтересована в оптимизации таких циклов, т.к. имею корысть в плане ускорения матричных операций в линейной алгебре. И вот здесь я только что обнаружила совершенно парадоксальное явление. А именно – я не вижу реального прироста скорости от единой операции «умножение с накоплением» по сравнению с ее реализацией двумя последовательными операциями умножения и сложения. Причем (и это самое странное!) вовсе не потому, что DSP-операция «умножение с накоплением» работает медленно, а потому, что пара последовательных операций «умножить» и «сложить» работает непредсказуемо быстро! При этом столь замечательный эффект «сращивания» немедленно пропадает, как только я разделю эти две операции, вставив между ними что-то еще (например, целочисленную операцию инкремента адреса). Отсюда возникает неожиданный взгляд на всю идеологию DSP, т.к. черезчур умный конвейер нивелирует разницу между единой DSP-операцией, которая делает много чего сразу и последовательностью отдельных операций, ее составляющих. Сильно подозреваю, что именно по этой причине из последних реализаций SIMD-инструкций (AVX/AVX2) исчезли математические все функции, кроме квадратного корня, хотя у старинного FPU87-сопроцессора все это было – не только тригонометрия, но и логарифмы. Такое положение вещей я могу объяснить только так – пропал выигрыш от совмещения последовательных вычислений в одной команде, если их вычисление «вразбивку» выполняется примерно с той же скоростью. Дальнейшая экстраполяция дает еще более парадоксальный вывод – совершенствование конвейеризации неудержимо приводит к тому, что стирается грань не только между обычными процессорами и DSP, но и процессорами разных архитектур! Т.е. все те недостатки системы команд x86, которые пролонгировали себя на x64, в нынешней ситуации пропадают, т.к. пропадают вообще все выигрыши и проигрыши, связанные с системой команд, т.к. в конечном итоге процессор перерабатывает некий абстрактный поток данных алгоритмом заданной сложности, тогда как все издержки кодирования этого алгоритма практически сведены к нулю действиями конвейера. Т.е. на производительность оказывает влияние лишь железо, с той или иной скоростью выполняющее свои аппаратные операции, тогда как кодировка перестает играть роль, всякий раз усилиями конвейера распадаясь на последовательность аппаратных операций.