VVB (26.07.2013 15:02, просмотров: 164) ответил Ксения на Нет ничего поразительного, т.к. linpack-тест загружает CPU "плавучкой" (умножением и сложением чисел с плавающей точкой). Все остальные трудозатраты (в т.ч. обращение к внешней пямяти) меркнут на ее фоне. А "рвёт как тузик грелку" тот МК, у-
- между прочим, для 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)