могу предложить для предположений некоторые результаты DSP, о котором я упоминал в комментариях к прошлой статье автора. Библиотечная функция готовит коэффициенты для 1К,4К,16К БПФ за 21000,84000,336000 тактов. Абсолютно линейная зависимость. Алгоритм вычислений простой , может быть векторизован , легко разделен на ядра. Библиотечная функция тратит 5000,23500,120000 тактов на БПФ соответственно. С ростом размера БПФ уже можно думать о вычислении массива коэффициентов, а не табличной заготовке. Для Е2С3 вычисление коэффициентов будет намного быстрее ( в сравнении с DSP) и вес их, в сравнении со временем БПФ, будет поменьше.
ИИ советует :) для 64К использовать не более 3-х массивов т.к. 4-й канал может понадобиться для иных нужд. Также советует 3 массива констант обьединить в структуру чтобы гарантировать их последовательное расположение.
Вроде как все нормально с количеством массивов. Я посмотрел Ваш исходник. Входной массив после реверса идет в выходной, а далее два массива чередуются. По логике 3 массива констант должны быть расположены друг за другом и образовывать один большой. Я бы создал один большой и поделил его на 3 :) Пока не видно причины почему бы и БПФ 64К не делать так же быстро как и 16К. Размер кэша как бы позволяет. Хорошо бы если бы Вы далее продолжили оптимизацию не малых размеров БПФ, а больших. Все-таки процессор у Вас серьезный и задачи он должен решать соответствующие :)
Спасибо за уточнение. Немного проштудировал Е2С3. Оказывается там только 2 М кэша L2 для одного ядра. При 64К мы имеем возможность хранить в нем 4 массива. И при этом им будет мешать еще и код программы.
У Вас очень хороший результат для 16К, но просто обвал для 64К. ИИ убеждает меня , что этого не избежать. Можете ли Вы подтвердить, что разбиение БПФ 64 К на четыре части по 16К + заключительная общая стадия, не даст улучшения скорости для 8СВ?
Предположим, что есть защелка. Читаем младшую часть(старшая в защелку), получаем прерывание, уходим на обработчик в котором тоже читается этот счетчик и портит защелку. Возвращаемся и читаем уже непонятно что. Разве не так?
Все время забываю про ИИ. Он пишет, что 4К бпф 66-й делает за 26000-29000 тактов при самом лучшем расположении данных. Но меня больше сразила цифра тактов для 16К - 328000. Или 131000 если использовать реализацию на все ядра. Но , конечно, веры в эти цифры нет :)
Когда-то я работал с DSP К1967ВН44. Для ориентира , у него БПФ с такими же числами для 4К- 23420 тактов, 16К - 117930, 64К-635000. Судя по всему у Вас еще не самый лучший результат получился.
Помню, в 97-м прошлого века в КБ при заводе сделали НИР и получили рабочий чип. Затем я увидел ТЗ на ОКР с окончанием в 2013. Я думал, что шутка. Но в 2013 чип реально появился. А Вы говорите 7.5 месяцев. Это если за Вас кто-то все уже сделал :)
Вы , как и я, еще не привыкли к ИИ :) Если задать ему Ваш вопрос по поводу популярности в прошлые годы, то одной из фраз будет такая:" По данным на 2018 год, около 80% проектных групп в мире использовали Verilog или SystemVerilog. "
Вот над этим хорошо бы акцентировать внимание. Когда-то я делал ASIC для автомобильного ключа на 8-разрядном МК: ядро+SRAM+ flash+простой последовательный интерфейс. Нажимаем кнопку - подается питание, МК читает из флэша число, шифрует его , отправляет, записывает во флэш новое число и отключается. Какое ядро из этих двух лучше подойдет для такого применения? Требования - чтобы батарейка работала как можно дольше и чип был как можно дешевле.
Этот тест был бы информативнее, но на мой взгляд, в статье нужно было немножко больше рассказать об особенностях исполнения команд в PicoRV32. Суть в том, что у него нет никакого конвейера и если вы выставите наилучшие условия для быстрой работы, то даже NOP команда будет исполняться за 3 такта. Если память работает не идеально, т.е. запрос на чтение команды в текущем такте, а сама команда в следующем такте, то уже как минимум 4 такта на любую команду. Поэтому нужно ожидать , что по тактам Picorv32 будет в 4 раза проигрывать SCR1 на одинаковом коде. Если используется С расширение, то иногда команда уже выбрана и тогда для неё 3 такта. Итого ухудшение по тактам будет меньше 4-х. Сравнивать эти ядра как-то даже не интересно если есть мысли о каком-то быстродействии.
я посмотрел времянку SCR1 на этом тесте. Скажу так - тест выбран очень неудачно. Сами представьте: всего 453 такта на итерацию в которой только одна операция умножения. Поэтому и выводы такие, что лучше выбирать минимальную конфигурацию SCR1 (без умножения) т.к. она не уступает максимальной (с аппаратным однотактным умножителем). Все верно, но только для этого теста. Попробуйте другой тест.
могу предложить для предположений некоторые результаты DSP, о котором я упоминал в комментариях к прошлой статье автора. Библиотечная функция готовит коэффициенты для 1К,4К,16К БПФ за 21000,84000,336000 тактов. Абсолютно линейная зависимость. Алгоритм вычислений простой , может быть векторизован , легко разделен на ядра. Библиотечная функция тратит 5000,23500,120000 тактов на БПФ соответственно. С ростом размера БПФ уже можно думать о вычислении массива коэффициентов, а не табличной заготовке. Для Е2С3 вычисление коэффициентов будет намного быстрее ( в сравнении с DSP) и вес их, в сравнении со временем БПФ, будет поменьше.
ИИ советует :) для 64К использовать не более 3-х массивов т.к. 4-й канал может понадобиться для иных нужд. Также советует 3 массива констант обьединить в структуру чтобы гарантировать их последовательное расположение.
Вроде как все нормально с количеством массивов. Я посмотрел Ваш исходник. Входной массив после реверса идет в выходной, а далее два массива чередуются. По логике 3 массива констант должны быть расположены друг за другом и образовывать один большой. Я бы создал один большой и поделил его на 3 :) Пока не видно причины почему бы и БПФ 64К не делать так же быстро как и 16К. Размер кэша как бы позволяет. Хорошо бы если бы Вы далее продолжили оптимизацию не малых размеров БПФ, а больших. Все-таки процессор у Вас серьезный и задачи он должен решать соответствующие :)
Спасибо за уточнение. Немного проштудировал Е2С3. Оказывается там только 2 М кэша L2 для одного ядра. При 64К мы имеем возможность хранить в нем 4 массива. И при этом им будет мешать еще и код программы.
У Вас очень хороший результат для 16К, но просто обвал для 64К. ИИ убеждает меня , что этого не избежать. Можете ли Вы подтвердить, что разбиение БПФ 64 К на четыре части по 16К + заключительная общая стадия, не даст улучшения скорости для 8СВ?
Мы будем вместо роботов-манипуляторов которым этот ИИ будет говорить:"Выньте штепсель из розетки и вставьте себе в ухо" :)
Предположим, что есть защелка. Читаем младшую часть(старшая в защелку), получаем прерывание, уходим на обработчик в котором тоже читается этот счетчик и портит защелку. Возвращаемся и читаем уже непонятно что. Разве не так?
Спасибо. Отличная статья.
Все время забываю про ИИ. Он пишет, что 4К бпф 66-й делает за 26000-29000 тактов при самом лучшем расположении данных. Но меня больше сразила цифра тактов для 16К - 328000. Или 131000 если использовать реализацию на все ядра. Но , конечно, веры в эти цифры нет :)
Когда-то я работал с DSP К1967ВН44. Для ориентира , у него БПФ с такими же числами для 4К- 23420 тактов, 16К - 117930, 64К-635000. Судя по всему у Вас еще не самый лучший результат получился.
Правильно ли я понял, что лучший результат для БПФ 4К комплексных float это 15078 тактов? Сколько тактов такое же БПФ на С66?
Помню, в 97-м прошлого века в КБ при заводе сделали НИР и получили рабочий чип. Затем я увидел ТЗ на ОКР с окончанием в 2013. Я думал, что шутка. Но в 2013 чип реально появился. А Вы говорите 7.5 месяцев. Это если за Вас кто-то все уже сделал :)
Вы , как и я, еще не привыкли к ИИ :) Если задать ему Ваш вопрос по поводу популярности в прошлые годы, то одной из фраз будет такая:" По данным на 2018 год, около 80% проектных групп в мире использовали Verilog или SystemVerilog. "
PS. ИИ рекомендует использовать SCR1 :)
Вот над этим хорошо бы акцентировать внимание. Когда-то я делал ASIC для автомобильного ключа на 8-разрядном МК: ядро+SRAM+ flash+простой последовательный интерфейс. Нажимаем кнопку - подается питание, МК читает из флэша число, шифрует его , отправляет, записывает во флэш новое число и отключается. Какое ядро из этих двух лучше подойдет для такого применения? Требования - чтобы батарейка работала как можно дольше и чип был как можно дешевле.
Не вижу проблем использовать SCR1 в точно такой же конфигурации.
Этот тест был бы информативнее, но на мой взгляд, в статье нужно было немножко больше рассказать об особенностях исполнения команд в PicoRV32. Суть в том, что у него нет никакого конвейера и если вы выставите наилучшие условия для быстрой работы, то даже NOP команда будет исполняться за 3 такта. Если память работает не идеально, т.е. запрос на чтение команды в текущем такте, а сама команда в следующем такте, то уже как минимум 4 такта на любую команду. Поэтому нужно ожидать , что по тактам Picorv32 будет в 4 раза проигрывать SCR1 на одинаковом коде. Если используется С расширение, то иногда команда уже выбрана и тогда для неё 3 такта. Итого ухудшение по тактам будет меньше 4-х. Сравнивать эти ядра как-то даже не интересно если есть мысли о каком-то быстродействии.
Скорее всего причина в том, что в МАХ версии у Вас конвейер 4 стадии, а в МИН только 2. На этом можно сильно потерять из-за переходов.
я посмотрел времянку SCR1 на этом тесте. Скажу так - тест выбран очень неудачно. Сами представьте: всего 453 такта на итерацию в которой только одна операция умножения. Поэтому и выводы такие, что лучше выбирать минимальную конфигурацию SCR1 (без умножения) т.к. она не уступает максимальной (с аппаратным однотактным умножителем). Все верно, но только для этого теста. Попробуйте другой тест.
Спасибо за статью. Подскажите, у Вас в конфигурации IM(max) в обоих ядрах используется однотактный аппаратный умножитель?