darlock, было бы оч интересно услышать - как связана задержка такая конская с применением шарков
ну и было бы интересно услышать таки наконец вменяемый анализ - чем современные дсп сливают 56к серии мотороловской.
Рекомендую закончить этот позорный спор
И вообще что за хамство спрыгивать с темы
я спрыгиваю с темы?
я вроде вполне вежливо спросил, без троллинга итп.
окей, продолжим.
darlock, если бы не твой негативный настрой, я бы с радостью обсудил твоё видение программирования дсп.
Я даж не пойму что с тобой такое - мы разве где-то пересекались?
В общем я выскажу как я думаю. Если у тебя будет только желание обосрать и самоутвердиться мол вокруг одни лохи, то не вижу причин продолжать. Мне лично доказывать давно уже никому ничего не хочется. Но если ты спец с реальным опытом, и тебе не в облом им таки чутка поделиться а не разбрасывать гОвна, то было бы отлично.
С точки зрения практики (моей ессно), проц "сам" не паралелит ничего (ну это вроде как очевидно). Т.е код написать можно задействовав команды в паралель ручками при написании алгоритма, это вроде тоже известно.
Итого - паралеллизм доступный в архитектуре можно эффективно использовать только в пределах одного алгоритма на одном процессоре.
Тобишь свертку посчитать блоками, суммируя по несколько произведений за раз и подобное, ну понятно.
"автоматически" код двух разных исполняемых модулей не распаралелится же, по этому получается что если говорить о двух алгоритмах выполняемых "одновременно" на одном процессоре - это всё равно будет разделение по времени. Сначала обработали отсчеты одним алгоритмом, потом вторым.
Ну вот например. Есть карта с дсп. Грузим мы туда два эква. Пусть это будет тупо два FIR. На один нужно N маков на отсчет, и на второй столько же.
Если процессор может выполнить Х маков в секунду, то (упрощщая) без разницы будешь ты вполнять эти два FIRа одновременно или друг за другом. В любом случае ты или уложишься в отведённое время выделенное на выполнение или нет.
Т.е возможности архитектуры позволяют выполнить _одну_ задачу за меньшее количетсов тактов.
А выолнять несолько алгоритмов реально параллельно можно только на нескольких процессорах.
И связи с нативом тут вообще никакой. Проблемы натива это недетерменированность времени выполнения, других не вижу.
если я вдруг на столько отстал от темы, и моторола умеет паралельно выполнять код из двух независимых бинарных модулей (программисты которых друг о другде никогда даже не знали может быть) - то я бы с радостью посомтрел на примеры. Одновременная выборка операндов + инкремент указателй + МАК например, это из другой оперы. И даже два мака одновременно плюс вышеперечисленное.
На счет флоата, совершенно похрен. Кто заставляет использовать именно плавучку непонятно. Ну разве тчо бесит само наличие невостребованного функционала.
Ну т.е я не понимаю какая разница что проц может в довесок к тому что лично тебе надо. Ну и плюс, в разных местах разные вещщи к месту. Решать дифуры - опупеешь отлавливать выход за допустимые значения при заюзе фиксированной точки. Например в моделлировании которе сейчас так модно, но не по табличкам предвычесленным а нормально чтоб, в рилтайме.
Т.е я чисто как человек так сказать прикоснувшися к среде программистов понимаю, что это особый как бы шик, уложиться в меньшее имея бОльшее. Но с точки зрения практики никого не огорчит использование например 1.31 вместо 1.23, если ресурсов на данной конкретной платформе это откушает одинаково (не считая памяти ессно)
На счет ААХ - вопрос не в процах, а в рынке и его потребностях. Т.е если быть конкретнее - выгоднее делать плаги по 50 баксов и продавать их вагонами тем кто "в туалете вокал пишет". Вернее не выгоднее, а на столько же выгодно, но под натив (очевидно) писать прощще. А нормлаьный дсп программист стоит сейчас оч недешего.
ЗЫ я предпочел отладку с техасом 6748 =)
ЗЗЫ народ тут мног очего обсуждает что многим непонятно. Если не сраться - а обсуждать - то какая в том пробелма?