Evgeny_CD, Архитектор (26.07.2013 14:14, просмотров: 234) ответил VVB на А вот и результат недавней работы. Представляю вниманию сравнение различных архитектур ARM "лоб в лоб" с целью определения быстродействия для классического теста linpack для операций над числами с плавающей точкой двойной точности.-
- Нет ничего поразительного, т.к. linpack-тест загружает CPU "плавучкой" (умножением и сложением чисел с плавающей точкой). Все остальные трудозатраты (в т.ч. обращение к внешней пямяти) меркнут на ее фоне. А "рвёт как тузик грелку" тот МК, у Ксения(114 знак., 26.07.2013 14:44)
- Я, кстати, не смог заставить кейл использовать библиотеки без 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,
)
- 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)
- Пусть число байт в переменной типа double скажут, а то всяк считает так, как это ему выгодно. - Ксения(26.07.2013 16:09)
- поясните чтобы стало ясно - double там для галочки? всё считалось во float? - Mahagam(26.07.2013 15:55)
- Там double float - VVB(26.07.2013 15:53)
- между прочим, для RM48L результаты весьма странные. FPU там, насколько я помню, только single-precision. как оно даблы ускоряло - неясно ни разу. ооочень вероятно что компилер тупо стал "treat double as float". - Mahagam(26.07.2013 15:52)
- Моя фраза не относится к плавучке. 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)
- В вашем коде linpack-теста я ни одной из этих функций не вижу. Ни callgraph, ни __aeabi_* - Ксения(26.07.2013 15:56)
- Специально для Вас callgraph VVB(28 знак., 26.07.2013 15:46 - 15:50)
- Назовите хоть одну, а то я никаких "больших библиотечных функций" в вашем коде не вижу. - Ксения(26.07.2013 15:43)
- LPC43xx ядро М4 имеет 3 отдельные шины (данные, код, периферия). Я раскидал код и данные по разным шинам, именно для реального применения, и показал замедление при нахождении кода и данных в одной шине. Оно совсем незначительное. - VVB(26.07.2013 15:25)
- Не забывайте, что linpack вызывает кейловские (в моём случае) библиотечные функции значительного объёма. - VVB(26.07.2013 15:28)
- А если использовать 16-бит SDRAM, то результаты будут ещё сильнее различаться. Недаром Texas не стал делать 32-бит интерфейс к SDRAM, а ограничился 16-битным (кэш спасёт). - VVB(26.07.2013 14:56)
- Хотя ОЗУ обычно бывает быстрее, чем Flash, но размещение в ней кода создают толкучку, т.к. тогда выдергивать из памяти надо как программу, так и данные. Образуется пробка, снижающая производительность. И тут спасение либо в кэшировании кода Ксения(354 знак., 26.07.2013 15:21 - 15:23)
- Физику процесса я понимаю. Тем не менее, цифры, полученные на живых камнях (еще раз спасибо VVB), все равно впечатляют. - Evgeny_CD(26.07.2013 14:45)
- Я, кстати, не смог заставить кейл использовать библиотеки без FPU для RM48L. Галочка "use FPU" влияет на его инициализацию. А так ещё планировал сделать то же самое для программной эмуляции. - VVB(26.07.2013 15:02)
- И, соответственно, приятные перспективы у Ренесаса с их 100 Мгц флешем... - Evgeny_CD(26.07.2013 14:19)
- Нет ничего поразительного, т.к. linpack-тест загружает CPU "плавучкой" (умножением и сложением чисел с плавающей точкой). Все остальные трудозатраты (в т.ч. обращение к внешней пямяти) меркнут на ее фоне. А "рвёт как тузик грелку" тот МК, у Ксения(114 знак., 26.07.2013 14:44)