[demiurg_spb 0]

CFLAGS += -Wdouble-promotion

чтобы компилятор поругался на даблы там где их не должно быть...

 

[adnega 11]

CFLAGS += -Wdouble-promotion

чтобы компилятор поругался на даблы там где их не должно быть...

Отличнейшая опция!

 

Странно, при -Os итерация порядка 1700 тактов и листинг:

   dist = 2.0f * asinf(sqrtf(sdlat * sdlat + cosf(clat) * cosf(lat) * sdlon * sdlon)) * 6367444.6571225f;
80015c4: ed9d 0a07   vldr  s0, [sp, #28]
80015c8: f000 f856   bl  8001678 <cosf>
80015cc: eef0 aa40   vmov.f32  s21, s0
80015d0: ed9d 0a06   vldr  s0, [sp, #24]
80015d4: f000 f850   bl  8001678 <cosf>
80015d8: ee2a 0a80   vmul.f32  s0, s21, s0
80015dc: ee20 0a09   vmul.f32  s0, s0, s18
80015e0: ee20 0a09   vmul.f32  s0, s0, s18
80015e4: eea8 0aa8   vfma.f32  s0, s17, s17
80015e8: f000 f920   bl  800182c <sqrtf>
80015ec: f000 f8c6   bl  800177c <asinf>

 

А при -O2 итерация 1048 тактов и задействуется vsqrt

   dist = 2.0f * asinf(sqrtf(sdlat * sdlat + cosf(clat) * cosf(lat) * sdlon * sdlon)) * 6367444.6571225f;
8001bae: ed9d 0a07   vldr  s0, [sp, #28]
8001bb2: f000 f85f   bl  8001c74 <cosf>
8001bb6: eeb0 aa40   vmov.f32  s20, s0
8001bba: ed9d 0a06   vldr  s0, [sp, #24]
8001bbe: f000 f859   bl  8001c74 <cosf>
8001bc2: ee2a 0a00   vmul.f32  s0, s20, s0
8001bc6: ee60 7a28   vmul.f32  s15, s0, s17
8001bca: ee67 7aa8   vmul.f32  s15, s15, s17
8001bce: eee8 7a08   vfma.f32  s15, s16, s16
8001bd2: eeb1 0ae7   vsqrt.f32 s0, s15
8001bd6: eeb4 0a40   vcmp.f32  s0, s0
8001bda: eef1 fa10   vmrs  APSR_nzcv, fpscr
8001bde: d13f        bne.n 8001c60 <main+0x1cc>
8001be0: f000 f8ca   bl  8001d78 <asinf>

 

При этом размер кода отличается всего на 32 байта, а производительность более чем на 38%

[AHTOXA 15]

Отличнейшая опция!

Есть ещё

-fsingle-precision-constant

.

Что касаемо -Os - по моему опыту, в ARM-ах это какая-то неудачная оптимизация. Самый нормальный уровень - -O2. -O3 иногда делает побыстрее, но не всегда. Зато гарантированно раздувает код.

[demiurg_spb 0]

Есть ещё

-fsingle-precision-constant

Не, ну так не честно. Я бы на неё не стал закладываться.

[adnega 11]

Не, ну так не честно. Я бы на неё не стал закладываться.

Из-за этого: " This section includes experimental options that may produce broken code."?

[klen 1]

Но может чуть-чуть волнует вызов "80015b8: f000 f916 bl 80017e8 <sqrtf>" при живом "VSQRT{cond}.F32 Sd, Sm"

 

нивапрос... уже разжовывал ввыше по тексту зачем и почему:

 

static inline float __attribute__ ((always_inline)) vsqrt (float value)
        {
            float result;
            asm volatile (     "vsqrt.f32 %0, %1 \r\n"
                      : "=w" (result) : "w" (value) );
            return (result);
        }

static inline float __attribute__ ((always_inline)) vabs (float value)
        {
            float result;
            asm volatile (     "vabs.f32 %0, %1 \r\n"
                  : "=w" (result) : "w" (value) );
            return (result);
        }

 

далее вызывайте вместо sqrtf() vsqrt(), fabs можно не трогать - как нистранно компиллер его превращает в vabs.f32.

 

[adnega 11]

нивапрос... уже разжовывал ввыше по тексту зачем и почему:

далее вызывайте вместо sqrtf() vsqrt(), fabs можно не трогать - как нистранно компиллер его превращает в vabs.f32.

Так не пойдет. Это все равно, что на асме писать; vsqrt ведь не библиотечная функция.

Не понятно почему при оптимизации Os вызывается библиотечная функция, а при O2 подставляется инструкция FPU.

 

[_Pasha 0]

Так не пойдет. Это все равно, что на асме писать; vsqrt ведь не библиотечная функция.

Костылями накройте: #define sqrtf vsqrt

 

[adnega 11]

Костылями накройте: #define sqrtf vsqrt

Не-не-не.

Это какая-такая религия запрещает компилятору использовать инструкцию, которая входит в реализацию fpv4-sp-d16.

Можно подумать, что в отличии от "обычных" арифметических действий, которые всегда дадут результат (даже при делении на ноль), извлечение квадратного корня несколько расширяет диапазон результата (особенно для отрицательных аргументов), поэтому должно быть функцией. Или ход мыслей неверный?

[AHTOXA 15]

Не, ну так не честно. Я бы на неё не стал закладываться.

Зато с её помощью можно легко проверить, не забыл ли ты где-либо написать суффикс f :)

Не понятно почему при оптимизации Os вызывается библиотечная функция, а при O2 подставляется инструкция FPU.

Чего же тут непонятного. Это баг. Можете сделать багрепорт.

[ReAl 0]

Оптимизацию на размер просили?

С вызовом библиотечной функции код этого куска стал меньше?

Так какой же это баг?

 

Ключа «оптимизация на размер, но догадываться, где будет обида на упавшую скорость» пока нет.

 

p.s. Я и для AVR в какой-то момент перешел на -O2. Именно по этой причине «сказано на размер, значит на размер» и идет вызов библиотечной функции ради экономии нескольких байт по месту.

[adnega 11]

Оптимизацию на размер просили?

С вызовом библиотечной функции код этого куска стал меньше?

Так какой же это баг?

 

Ключа «оптимизация на размер, но догадываться, где будет обида на упавшую скорость» пока нет.

Дык, реализация библиотечного корня судя по листингу два экрана строк.

Может это проблема библиотеки?

Но зачем компилятор использует функцию, а не инструкцию.

По поводу размера: он уменьшился лишь в комплексе, конкретный кусок при этом стал больше.

[_Pasha 0]

Но зачем компилятор использует функцию, а не инструкцию.

По поводу размера: он уменьшился лишь в комплексе, конкретный кусок при этом стал больше.

Эта функция sqrtf используется один раз? Если так, - то бага. Если несколько раз - фича :)

 

Не-не-не.

Если костылик правильно завернуть в #ifdef , то исходник у Вас будет чистый, а в конкретном случае Вы не будете завязаны на способ оптимизации.

Проверить builtin macros

#if (defined(__VFP_FP__) && !defined(__SOFTFP__))

Но там бардак, в частности CS от вольного ставит эти макросы.

Рекомендовали проверять __ARM_PCS_VFP

но тама фигурировала бага...

Интересно, что в kgp с этими макросами?

--

блин, когда же я на х64 перееду...

[AHTOXA 15]

Эта функция sqrtf используется один раз? Если так, - то бага. Если несколько раз - фича :)

Во-во:) Хотя, если

При этом размер кода отличается всего на 32 байта, а производительность более чем на 38%

, то значит не бага: размер-то всё-таки уменьшился в итоге:)

Интересно, что в kgp с этими макросами?

Вот же, недавно тема была.

 

[adnega 11]

Задам вопрос иначе: может, у меня просто нет библиотеки, в которой математические функции реализуют hard по-максимому?