Спасибо. Да, 5 тактов из рисунка 6. Но в новом документе видно что есть два варианта: приблизительно 5 и 10 тактов. 5 если через кэш L2. Если без него, то хуже получается. Рисунки 2 и 3 дают 3 такта из памяти L2. Получается 16/3=5.3 байта на такт. Из Ваших цифр ранее я считал так 4+7=11 на 64 байта. Итого 64/11 = 5.8 Практически одинаково.
Ваш тест в большей степени как раз тест на пропускную способность памяти. Шаг адреса равен 16. Если я не ошибаюсь, то получается скорость 5 тактов на чтение из любой память (префетч для SL2 + DDR). Итого 16/5 = 3.2 байта на такт.
Похоже что 16 байт за такт можно получить только когда 32К байт все сидят в кэше L1D. Если чуть больше данных, то далее все должно определяться задержкой подкачки линии из Prefetchera в L1D и тем, как шустро Prefetche будет подкачивать следующий пакет.
Подкачка работает только при обращении к внешней памяти (в XMC). 256 бит для L1D нарисовано потому, что 2х64 по чтению и 2х64 по записи. Ранее Вы написали задержку загрузки линии кэша.
Банки L1D это всего лишь расслоение по 8-ми словам. Ядро каждый такт будет читать 4 из них. IDMA будет писать 2 из них. Пересечение и конфликт неминуем. Правда, если тормозить будет процессор, а не IDMA, то на общее времени исполнения этого пинг-понга конфликты не должны повлиять.
При добавлении 2-го юнита в коде добавятся еще 4 инструкции и все это влезет в один пакет. Адрес в B12 = A12+8 и инкремент будет на 16 байт. Вроде так? 11 тактов на 64 байта это 5.8 байта на такт из памяти L2. Частный случай. У DSP обычно все красиво когда данные внутри какой-то удобной памяти. "Маленький" обьем для Эльбруса у Вас 7 млн байт :) .
Это не очень хороший прием. Трафик у IDMA в 2 раза ниже чем у ядра. Да еще к той же памяти, с которой работает ядро. Т.е. еще и с ядром будет конфликт доступа. Здесь (для сравнения) все лучше делать аналогично Эльбрусу: кэш L1 максимальный 32К, кэш L2 максимальный 512 К. Вместо кэша L3 внутреннюю 4М память.
Да. С этим девайсом было бы интереснее посоревноваться :) Надеюсь, что для случая FFT у Вас будут не только цифры Эльбруса, но и цифры TI. Хотя бы для С66.
Спасибо большое за такой развернутый ответ. Можно сделать вывод , что на С66 теоретически можно 16 байт за такт накапливать? При выравненных адресах загрузки.
Отличная статья. Хорошо , что Вы привели примеры кода для С66. Очень познавательно. Еще бы хорошо, если бы Вы далее добавляли и значения производительности на рассматриваемых алгоритмах и для С66. У него и частота схожая. Спасибо..
С учетом того, что наш ПЛИС мы запустили на частоте 10 МГц, и наши попугаи становятся равны ~0.36.
Похоже я немного не понял результаты. Здесь действительно "попугаи", которые я принял за см/мгц. Если бы процессор запустили на 100 МГц, то попугаев было бы 0.038. Значение же коремарка на мегагерц от частоты не зависит. Интересные курсы повышения квалификации :)
Теперь к насущным вопросам: кто-то в здравом уме будет запускать AMD GPU на ПЛИС?
Странный вопрос :) В Вашем случае ПЛИС вторична, а подключали Вы GPU к СнК , мощь которой (процессор с его адресным пространством, DDR память, PCI-E интерфейс) вполне соответствуют подключаемому устройству.
Посмотрите здесь https://textarchive.ru/c-2726176.html
Получается, что АРВ всегда начинает с L2. Но еще нужно знать стратегию по записи у L1. Возможно она сквозная.
Спасибо. Да, 5 тактов из рисунка 6. Но в новом документе видно что есть два варианта: приблизительно 5 и 10 тактов. 5 если через кэш L2. Если без него, то хуже получается. Рисунки 2 и 3 дают 3 такта из памяти L2. Получается 16/3=5.3 байта на такт. Из Ваших цифр ранее я считал так 4+7=11 на 64 байта. Итого 64/11 = 5.8 Практически одинаково.
Просто у меня доступ к полной статье запрещен :) А статья полезная.
НАшел интересную ссылку https://en.eeworld.com.cn/news/qrs/eic272697.html
Ваш тест в большей степени как раз тест на пропускную способность памяти. Шаг адреса равен 16. Если я не ошибаюсь, то получается скорость 5 тактов на чтение из любой память (префетч для SL2 + DDR). Итого 16/5 = 3.2 байта на такт.
Похоже что 16 байт за такт можно получить только когда 32К байт все сидят в кэше L1D. Если чуть больше данных, то далее все должно определяться задержкой подкачки линии из Prefetchera в L1D и тем, как шустро Prefetche будет подкачивать следующий пакет.
Подкачка работает только при обращении к внешней памяти (в XMC). 256 бит для L1D нарисовано потому, что 2х64 по чтению и 2х64 по записи. Ранее Вы написали задержку загрузки линии кэша.
Банки L1D это всего лишь расслоение по 8-ми словам. Ядро каждый такт будет читать 4 из них. IDMA будет писать 2 из них. Пересечение и конфликт неминуем. Правда, если тормозить будет процессор, а не IDMA, то на общее времени исполнения этого пинг-понга конфликты не должны повлиять.
При добавлении 2-го юнита в коде добавятся еще 4 инструкции и все это влезет в один пакет. Адрес в B12 = A12+8 и инкремент будет на 16 байт. Вроде так? 11 тактов на 64 байта это 5.8 байта на такт из памяти L2. Частный случай. У DSP обычно все красиво когда данные внутри какой-то удобной памяти. "Маленький" обьем для Эльбруса у Вас 7 млн байт :) .
Это не очень хороший прием. Трафик у IDMA в 2 раза ниже чем у ядра. Да еще к той же памяти, с которой работает ядро. Т.е. еще и с ядром будет конфликт доступа. Здесь (для сравнения) все лучше делать аналогично Эльбрусу: кэш L1 максимальный 32К, кэш L2 максимальный 512 К. Вместо кэша L3 внутреннюю 4М память.
Из Вашего замечания непонятно за кого бояться - что Эльбрус проиграет С66 или наоборот. Можете прояснить у кого на FFT нет шансов победить? :)
Да. С этим девайсом было бы интереснее посоревноваться :) Надеюсь, что для случая FFT у Вас будут не только цифры Эльбруса, но и цифры TI. Хотя бы для С66.
Да. Интерфейс к памяти узковат. Здесь еще очень интересен случай когда размеры массива превышают обьем кэша L1D..
Спасибо большое за такой развернутый ответ. Можно сделать вывод , что на С66 теоретически можно 16 байт за такт накапливать? При выравненных адресах загрузки.
Отличная статья. Хорошо , что Вы привели примеры кода для С66. Очень познавательно. Еще бы хорошо, если бы Вы далее добавляли и значения производительности на рассматриваемых алгоритмах и для С66. У него и частота схожая. Спасибо..
Похоже, "попугаи" можно перевести в км/мгц . Это будет 1/3.62 = 0.27 :)
Похоже я немного не понял результаты. Здесь действительно "попугаи", которые я принял за см/мгц. Если бы процессор запустили на 100 МГц, то попугаев было бы 0.038. Значение же коремарка на мегагерц от частоты не зависит. Интересные курсы повышения квалификации :)
Я уже лет 25 не повышал квалификацию, поэтому может без умножения коремарк сейчас быстрее чем с умножением.
Я впечатлен результатами. Это лучше чем в самом свежем МК от Baikal (https://www.baikalelectronics.ru/products/baikal-u/). И при этом у Вас нет даже умножения.
Может Вы в курсе характеристик SCR9 ? Помогает ли ему в соревновании с BI-672 векторное расширение ? :)
Странный вопрос :) В Вашем случае ПЛИС вторична, а подключали Вы GPU к СнК , мощь которой (процессор с его адресным пространством, DDR память, PCI-E интерфейс) вполне соответствуют подключаемому устройству.