[AlexandrY 2]

13 minutes ago, jcxz said:

Много ума не надо чтобы вставить код не по теме.

А вот соптимизируйте ка это 

/* inverse of a 3x3 matrix */
void gl_M3_Inv(M3 *a,M3 *m)
{
	 float det;
	 
	 det = m->m[0][0]*m->m[1][1]*m->m[2][2]-m->m[0][0]*m->m[1][2]*m->m[2][1]-
		 m->m[1][0]*m->m[0][1]*m->m[2][2]+m->m[1][0]*m->m[0][2]*m->m[2][1]+
		 m->m[2][0]*m->m[0][1]*m->m[1][2]-m->m[2][0]*m->m[0][2]*m->m[1][1];

	 a->m[0][0] = (m->m[1][1]*m->m[2][2]-m->m[1][2]*m->m[2][1])/det;
	 a->m[0][1] = -(m->m[0][1]*m->m[2][2]-m->m[0][2]*m->m[2][1])/det;
	 a->m[0][2] = -(-m->m[0][1]*m->m[1][2]+m->m[0][2]*m->m[1][1])/det;
	 
	 a->m[1][0] = -(m->m[1][0]*m->m[2][2]-m->m[1][2]*m->m[2][0])/det;
	 a->m[1][1] = (m->m[0][0]*m->m[2][2]-m->m[0][2]*m->m[2][0])/det;
	 a->m[1][2] = -(m->m[0][0]*m->m[1][2]-m->m[0][2]*m->m[1][0])/det;

	 a->m[2][0] = (m->m[1][0]*m->m[2][1]-m->m[1][1]*m->m[2][0])/det;
	 a->m[2][1] = -(m->m[0][0]*m->m[2][1]-m->m[0][1]*m->m[2][0])/det;
	 a->m[2][2] = (m->m[0][0]*m->m[1][1]-m->m[0][1]*m->m[1][0])/det;
} 

Это функция из библиотеки tinygl для рисования 3D сцен которая подключается к ugfx.
 

[jcxz 184]

2 минуты назад, AlexandrY сказал:

Много ума не надо чтобы вставить код не по теме.

В чём именно "не по теме"?

3 минуты назад, AlexandrY сказал:

А вот соптимизируйте ка это 

Сколько готовы заплатить?

[aaarrr 63]

34 minutes ago, jcxz said:

И я, зная что (cnt == 0 || cnt > 4) и что входные данные (*src) - 14-битные (0...0x3FFF) и выровнены на 32бита, оптимизировал её так

Ну а что мешало сказать то же самое и компилятору?

Загрузить данные через LDM и перемножить несколько чисел одновременно он сможет ничуть не хуже.

[jcxz 184]

11 минут назад, aaarrr сказал:

Ну а что мешало сказать то же самое и компилятору?

Загрузить данные через LDM и перемножить несколько чисел одновременно он сможет ничуть не хуже.

Сказать что и как?

LDM IAR например никогда не использует, даже для u32 *.

[aaarrr 63]

11 minutes ago, jcxz said:

Сказать что и как?

Ну, хотя бы грузить словами, использовать где нужно uint64_t, да и вообще арифметику переписать по ассемблерному образцу и подобию.

Вы привели две совершенно разные программы, и почему-то делаете вывод о неэффективности C-компилятора.

 

12 minutes ago, jcxz said:

LDM IAR например никогда не использует, даже для u32 *.

Грусть-печаль.

 

[jcxz 184]

16 минут назад, aaarrr сказал:

Ну, хотя бы грузить словами, использовать где нужно uint64_t, да и вообще арифметику переписать по ассемблерному образцу и подобию.

Вы привели две совершенно разные программы, и почему-то делаете вывод о неэффективности C-компилятора.

Так приведите си-исходник, который будет компилироваться в такой код (который будет 64-битными словами и т.п.).

Я привёл не 2 совершенно разные программы, а взял результат компиляции одной программы и его оптимизировал на асме.

Я вообще-то говорю не об неэффективности компилятора, а показываю что он неидеален, и что код ТС-а скорей всего также возможно вручную оптимизировать лучше компилятора.

[aaarrr 63]

2 minutes ago, jcxz said:

Так приведите си-исходник, который будет компилироваться в такой код (который будет 64-битными словами и т.п.).

Сколько готовы заплатить?

3 minutes ago, jcxz said:

...взял результат компиляции одной программы и его оптимизировал на асме.

Заодно поменяв арифметику.

[jcxz 184]

1 минуту назад, aaarrr сказал:

Сколько готовы заплатить?

Отсюда вывод: мой код лучше чем у компилятора.

 

1 минуту назад, aaarrr сказал:

Заодно поменяв арифметику.

Компилятор, когда компилит, тоже её может менять. И что с того?

[aaarrr 63]

4 minutes ago, jcxz said:

Отсюда вывод: мой код лучше чем у компилятора.

Дороже не значит лучше.

 

4 minutes ago, jcxz said:

Компилятор, когда компилит, тоже её может менять. И что с того?

На таком уровне не может и не должен.

[haker_fox 60]

5 hours ago, jcxz said:

Как видно - разница очень даже заметная.

Это классно - разобраться в ассемблере ARM'а. Сам я, к сожалению, его знаю не очень хорошо. Освоился в своё время только с ассемблером AVR и x86(старых). Но... не теряется ли переносимость кода? Занимаясь оптимизацией функций на низкоуровневом языке что будет, если завтра придётся переносить код на другую архитектуру? Либо как тогда доверять компилятору и оптимизатору его работу? Проверять каждую из десятка тысяч функцию? Либо проверять тогда, когда возникают проблемы? Я вот, правда, в глубоких раздумьях. Ещё недавно я считал, что компилятор "неплохо" оптимизирует код, и доверялся ему.

[AlexandrY 2]

4 hours ago, haker_fox said:

Ещё недавно я считал, что компилятор "неплохо" оптимизирует код, и доверялся ему.

Да не стоит волноваться.
uGFX достаточно монструозная система чтобы глаза на лоб вылезли у любого ассемблерного "оптимизатора". 
Насколько вижу uGFX умеет использовать для рисования Chrom-Art Accelerator, который есть у некоторых STM-ов
Вот его использование действительно что-то ускорит.
Кстати у i.MX RT есть такая же штука и даже более функциональная, называется Pixel Pipeline (PXP) 

[Kabdim 0]

13 часов назад, jcxz сказал:

"Весьма неплохо" - это на взгляд тех, кто не хочет напрягать свой мозг и изучать ассемблер.

 

Вы же компилятору не сообщили что они выравнены по слову. Такое объединение по стандарту считается выравненным на 2 байта. Со всеми вытекающими из этого возможностями для оптимизации. Вам стоило обявить так:

union AdcFastData {
  struct {
    u16 ampU;
    u16 ampV;
    u16 ampW;
    u16 voltH;  //UQ0.16
  };
  u16 raw[4];
  uint32_t align_placeholder; // или прагамами для структуры. а для всяких ссе нужно было добавить еще лучше выравнивание
};

[jcxz 184]

1 час назад, Kabdim сказал:

Вы же компилятору не сообщили что они выравнены по слову. Такое объединение по стандарту считается выравненным на 2 байта. Со всеми вытекающими из этого возможностями для оптимизации. Вам стоило обявить так:

А Вы сами пробовали то, что предлагаете? И какой именно компилятор использует для такого кода LDM? И с какими ключами?

Ну или обратите внимание на https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=149936&do=findComment&comment=1598708

Попробовал скомпилить свой текущий проект, объёмом ~2.5 МБ исходников, с максимальной оптимизацией. Потом сделал поиск по .lst-файлам. И нашёл только в одном .lst получившемся из си-файла, пару LDM/STM. А уж обращений по указателю типа (u32 *) там пруд пруди.

И да - мне известно, что в данном конкретном случае можно использовать LDRD. Только дальше то что делать? Ведь дальше идёт суммирование 14-битных данных.

 

PS: Да и вообще приведённый мной пример - это был именно пример решения конкретной задачи оптимизации практической задачи в данном конкретном случае. Именно - пример. Чтобы показать ТС-у один из путей решения его задачи. Смысла обсуждать тут этот пример нет. Только если конечно кто-то не предложит способ получить более оптимальный код, за что я буду только благодарен.  

[Kabdim 0]

Я вас не критикую, и да компилятор может такой код, даже с подсказкой о выравнивании, скомпилировать неоптимально. Но тем обиднее видеть что пример сформулирован не до конца корректно.

[jcxz 184]

19 минут назад, Kabdim сказал:

Я вас не критикую, и да компилятор может такой код, даже с подсказкой о выравнивании, скомпилировать неоптимально. Но тем обиднее видеть что пример сформулирован не до конца корректно.

Я пытался его компилировать по-разному. И подобно тому как Вы предлагали - тоже. И никак не получил LDM. Потом убрал из структуры лишнее (не люблю лишнего мусора в исходниках).

Если Вы знаете как сказать IAR-у чтобы он использовал LDM/STM - я буду благодарен. Так как в коде куча всяких обращений к памяти через (u32 *). И что я только не пробовал - у меня не получилось заставить его использовать LDM/STM. Пришлось в таких критических местах (си-исходников) приводить к (u64 *) и хоть так улучшать код.

Если Вы знаете как сказать IAR-у что (u32 *) - выровненный на 32 бита и что он может использовать LDM/STM - скажу большое СПАСИБО  

Может я что-то проглядел в документации....