caxapa.ru :: Нет ничего поразительного, т.к. linpack-тест загружает CPU "плавучкой" (умножением и сложением чисел с плавающей точкой). Все остальные трудозатраты (в т.ч. обращение к внешней пямяти) меркнут на ее фоне. А "рвёт как тузик грелку" тот МК, у

Ксения (26.07.2013 14:44, просмотров: 131) ответил Evgeny_CD на Спасибо! Очень интересно. Поражает то, что переход от SRAM -> SDRAM в части данных вызывает совсем небольшой прирост времени исполнения. И наглядно показано, что такое "обычный FLASH" на частоте 200 МГц.

Нет ничего поразительного, т.к. linpack-тест загружает CPU "плавучкой" (умножением и сложением чисел с плавающей точкой). Все остальные трудозатраты (в т.ч. обращение к внешней пямяти) меркнут на ее фоне. А "рвёт как тузик грелку" тот МК, у которого операции с плавающей точкой встроены аппаратно и/или тот, для которого double компилируется как float.

Ответить

- Я, кстати, не смог заставить кейл использовать библиотеки без FPU для RM48L. Галочка "use FPU" влияет на его инициализацию. А так ещё планировал сделать то же самое для программной эмуляции. - VVB(26.07.2013 15:02)
  - между прочим, для RM48L результаты весьма странные. FPU там, насколько я помню, только single-precision. как оно даблы ускоряло - неясно ни разу. ооочень вероятно что компилер тупо стал "treat double as float". - Mahagam(26.07.2013 15:52)
    - Там double float - VVB(26.07.2013 15:53)
      - поясните чтобы стало ясно - double там для галочки? всё считалось во float? - Mahagam(26.07.2013 15:55)
        
        Пусть число байт в переменной типа double скажут, а то всяк считает так, как это ему выгодно. - Ксения(26.07.2013 16:09)
        
        64 bit - _VVB(26.07.2013 16:58, )
        
        float в исходниках нигде не фигурирует, везде double. Я также смотрел сгенерированный код, там для RM48 действительно генерируются команды двойной точности для сопроцессора. Ну и префикс _d* в callgraph как бы намекает об использовании двойной VVB(10 знак., 26.07.2013 15:59)
        
        понял. показалось что ядро M4F, а там R4F. оно уже с поддержкой double - Mahagam(26.07.2013 16:06)
- Моя фраза не относится к плавучке. VVB(140 знак., 26.07.2013 14:52)
  - Хотя ОЗУ обычно бывает быстрее, чем Flash, но размещение в ней кода создают толкучку, т.к. тогда выдергивать из памяти надо как программу, так и данные. Образуется пробка, снижающая производительность. И тут спасение либо в кэшировании кода Ксения(354 знак., 26.07.2013 15:21 - 15:23)
    - Не забывайте, что linpack вызывает кейловские (в моём случае) библиотечные функции значительного объёма. - VVB(26.07.2013 15:28)
      - Назовите хоть одну, а то я никаких "больших библиотечных функций" в вашем коде не вижу. - Ксения(26.07.2013 15:43)
        
        Специально для Вас callgraph VVB(28 знак., 26.07.2013 15:46 - 15:50)
        
        В вашем коде linpack-теста я ни одной из этих функций не вижу. Ни callgraph, ни __aeabi_* - Ксения(26.07.2013 15:56)
        
        Конечно, их вставляет компилятор. VVB(192 знак., 26.07.2013 16:03)
    - LPC43xx ядро М4 имеет 3 отдельные шины (данные, код, периферия). Я раскидал код и данные по разным шинам, именно для реального применения, и показал замедление при нахождении кода и данных в одной шине. Оно совсем незначительное. - VVB(26.07.2013 15:25)
  - А если использовать 16-бит SDRAM, то результаты будут ещё сильнее различаться. Недаром Texas не стал делать 32-бит интерфейс к SDRAM, а ограничился 16-битным (кэш спасёт). - VVB(26.07.2013 14:56)
    - Думаю, фишка в другом. кеш лайн поди 16 байт. 8 пересылок по 16 битной шине и 4 - по 32битной. Если подсчитать совокупную пропускную способность через транзакции ((16 байт)/(период клока * тактов на транзакцию)), то выигрыш от 32 бит будет Evgeny_CD(221 знак., 26.07.2013 15:02)
- Физику процесса я понимаю. Тем не менее, цифры, полученные на живых камнях (еще раз спасибо VVB), все равно впечатляют. - Evgeny_CD(26.07.2013 14:45)

ARM, RISC-V контроллеры