[jeka 0]

Задался вопросом оптимизации кода. В интернетах не нашел какой-либо толковой информации по оптимизации кода под M7. Поэтому пришлось поставить несколько экспериментов по быстродействию. Пока только начал, но после изучения скудного описания cortex m7 pipeline результаты для меня весьма неожиданные.

Итак, есть DWT, которым оценивал скорость выполнения инструкций на процессоре stm32h743. В нем использовался счетчик циклов CPU, счетчик циклов ожидания доступа к памяти, счетчик команд с нулевым кол-вом циклов (т.е. выполненных с чем-то параллельно).

1. максимальное число одновременно исполняемых команд за такт. Хотя в архитектуре есть 4 очереди: load-store, 2xAlu и 4xfpu, максимум что добился - 2 инструкции за такт, как ни крутил.

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

3. Load/store. По моей логике, load-store должен выполняться в отдельной очереди и не мешать работать alu. Но на практике это не совсем так. Например, есть 16 FPU инструкций, выполняющиеся за 8 тактов. Если в начало добавить LDM 8ми CPU регистров из TCM памяти, то добавляется еще 6-7 тактов.

4. ALU. Тут всё гораздо приятней чем на FPU. Если результат использовать через 1 инструкцию, то стабильно получаем 2 инструкции за такт. За исключением умножения. Еще, в некоторых случаях, результат команд битовых манипуляций непосредственно в следующей инструкции выполнялся за 1 такт.

Умножитель. Мне не удалось выполнить более одного умножения за такт (кроме инструкций SMUAD and SMUSD). т.е. умножение надо параллелить с другими операциями, либо использовать команды сдвоенного умножения.

 

p.s. Это мои первые зксперименты, на истину не претендую, тем не менее общее представление уже начинает формироваться.

[SII 0]

2 minutes ago, jeka said:

1. максимальное число одновременно исполняемых команд за такт. Хотя в архитектуре есть 4 очереди: load-store, 2xAlu и 4xfpu, максимум что добился - 2 инструкции за такт, как ни крутил.

Это определяется количеством команд, которые процессор может запускать или завершать одновременно. Выполняться параллельно может большее число команд, но с внешней точки зрения -- только столько, сколько можно запустить/завершить.

[jeka 0]

Итак, коротко про параллельное исполнение в H7:

(1) Базовая арифметика (+,-, логика, сдвиги): mov, mvn, cmp, cmn, add, sub, adc,sbc, srb, and, orr, eor, bic, orn, asr, lsl, lsr, ror, rrx - может выполняться по 2 операции за такт и параллелиться с остальным.

(2) Остальная логика-арифметика (Всё остальное кроме FPU и умножения): SIMD (sadd8/16,...), PKH*, SXT,UXT, saturating - увы, только одна операция за такт. Может параллелиться со всем остальным. Поэтому их нужно чередовать с другими операциями.

(3) Умножение - одна операция за такт. Может параллелиться со всем остальным.

(4) FPU - может выполняться по 2 операции за такт и параллелиться с остальным. Латентность FPU инструкций - 2 такта. Т.е. результат можем использовать через 2 такта.

(5) CPU load/store: одинарные операции могут параллелиться с остальными. dual load - ни с чем не параллелится, занимает 1 такт. LDM - кол-во тактов равно количеству регистров. Параллельно с LDM выполнится только одна инструкция. Т.е. для лучшего распараллеливания нужно разбивать LDM на единичные загрузки и мешать с другими инструкциями. Или использовать dual операции при работе с 64бит памятью.

(6) FPU load/store: но занимают (5) и (4). В деталях не изучена.

(7) CPU/FPU vmov: занимают (2) и (4). В деталях не изучена.

[mantech 33]

17.01.2021 в 07:22, jeka сказал:

Итак, коротко про параллельное исполнение в H7:

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

[jcxz 181]

5 минут назад, mantech сказал:

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

...а на практике самые критичные по вычислительным затратам места программы пишут на ассемблере. И хорошее знание архитектуры CPU при этом крайне необходимо.

[mantech 33]

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

...а на практике самые критичные по вычислительным затратам места программы пишут на ассемблере

Может лет 15 назад так и делали, сейчас проще взять более производительный процессор и писать как "белые люди", на Сях...

[jcxz 181]

6 минут назад, mantech сказал:

взять более производительный процессор

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

[MrBearManul 0]

7 минут назад, mantech сказал:

Может лет 15 назад так и делали, сейчас проще взять более производительный процессор и писать как "белые люди", на Сях...

Холивар бегин детектед) Если серьёзно, не согласен. Может оказаться так, что у вас перед глазами уже запаянная плата с годным микроконтроллером, могущим сделать всё необходимое, а вы из-за незнания заказываете другой, более производительный МК, перезаказываете печатку, тратите время...

7 минут назад, mantech сказал:

"белые люди", на Сях...

OFF: они уже давно пишут на Си++ или джавах)

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

А в реальном embedded-устройстве кроме процессора имеется куча других требований

Люто плюсую.

Изменено 20 января, 2021 пользователем MrBearManul

[jcxz 181]

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

Холивар бегин детектед) Если серьёзно, не согласен. Может оказаться так, что у вас перед глазами уже запаянная плата с годным микроконтроллером, могущим сделать всё необходимое, а вы из-за незнания заказываете другой, более производительный МК, перезаказываете печатку, тратите время...

......и получаете в результате более дорогое устройство, приносящее меньше прибыли работодателю при серийном производстве. По уму работодатель тогда должен просто вычесть упущенную прибыль из ЗП такого "специалиста". 

[mantech 33]

20.01.2021 в 11:40, jcxz сказал:

Так делают только быдлокодеры и ПК-программеры.

Нет. Так делают все нормальные люди, ибо как сам работодатель, и не буду тратить ЗП на долгие изыскания и ручную оптимизацию нескольких тактов в программе, это все время, которое стоит недешего и сколь его потратит этот "гений" в итоге мне придется его оплатить вместо того, чтобы он лучше тестировал свое творение. А на счет  "А в реальном embedded-устройстве кроме процессора имеется куча других требований " - так вообще-то при "закладке" МК в устройство нужно еще и рассчитывать на то, что будут еще новые требования в процессе разработки и придется впихивать доп. функционал, поэтому выбирать МК с запасом, т.к. еще не встречал ни одного заказчика, который может сразу и грамотно написать ТЗ, и в процессе работы нужно будет еще и то и это... Может быть у вас заказчики очень умные и грамотные в плане ТЗ, а мне вот так не повезло.

20.01.2021 в 11:45, jcxz сказал:

......и получаете в результате более дорогое устройство,

Да какое дорогое... Проснитесь, мы тут о нескольких тактах говорим, что они решат? Или выбираете МК так, что 99% он будет загружен задачей? О чем это вообще...

Я все понимаю, если б мы были в то время, когда был МК 8051, ценой в 50р или альтернатива АВР ценой в 100, и если бы оптимизация позволяла впихнуть прогу вместо дорогого авра в 51й то да, это было бы круто, но сегодня огромный выбор, причем более современные и быстрые МК будут даже дешевле устаревших...

Изменено 21 января, 2021 пользователем mantech

[SII 0]

1 hour ago, mantech said:

Да какое дорогое... Проснитесь, мы тут о нескольких тактах говорим, что они решат? Или выбираете МК так, что 99% он будет загружен задачей? О чем это вообще...

А если эти несколько тактов идут в цикле, выполняемом миллионы раз?

[mantech 33]

29 минут назад, SII сказал:

А если эти несколько тактов идут в цикле, выполняемом миллионы раз?

А зачем? Можете реальный пример привести?

[SII 0]

4 minutes ago, mantech said:

А зачем? Можете реальный пример привести?

Какое-нибудь там БПФ и прочая обработка сигналов с приличными по размерам массивами данных, например. Но да, "нормальные люди" под такие задачи используют ПЛИСы или, на худой конец, 100500-тыщеядерные процы на 100500-тыщ ГГц. А, ещё, программировать всё это сейчас надо на Питоне.

[jcxz 181]

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

А зачем? Можете реальный пример привести?

Приводили уж и не раз. Реальный пример: https://electronix.ru/forum/?app=core&module=system&controller=content&do=find&content_class=forums_Topic&content_id=148778&content_commentid=1583380

А теперь покажите: Как реализовать то же самое (нахождение максимального или минимального 16-разрядного значения в массиве) без использования ассемблера, при этом - не более чем на "несколько тактов" медленнее этого ассемблерного варианта? 

А если то же самое нужно сделать для массива 8-разрядных данных - как?  

 

3 часа назад, mantech сказал:

Да какое дорогое... Проснитесь, мы тут о нескольких тактах говорим, что они решат? Или выбираете МК так, что 99% он будет загружен задачей? О чем это вообще...

О чём? Что такое "батарейное устройство" слышали? А если этому устройству нужно много считать (какую-нить цифровую обработку делать)? Например - периодически обрабатывать пришедший с АЦП массив данных. А если оптимизация на ассемблере даёт возможность время этой обработки сократить в 2 раза и соответственно - в 2 раза увеличить время работы устройства от одного заряда батарей?

Вот когда Ваш девайс, сделанный человеком никогда не заглядывавшим в систему команд МК, уже не проснётся, в то время как другой точно такой же девайс, но сделанный человеком знающим ассемблер, будет ещё и просыпаться и просыпаться и работать и работать. Вот тогда и будете ему кричать "Проснитесь!".  

Тогда может и поймёте "О чем это вообще"

[jcxz 181]

3 часа назад, mantech сказал:

Нет. Так делают все нормальные люди, ибо как сам работодатель, и не буду тратить ЗП на долгие изыскания и ручную оптимизацию нескольких тактов в программе, это все время, которое стоит недешего и сколь его потратит этот "гений" в итоге мне придется его оплатить

Ну да, а потом сляпанный "как попало главное быстрее" девайс, выходит на рынок. Допустим - он вышел на рынок на месяц раньше, чем девайс сделанный другой конторой профессионалом и умеющий работать в 2 раза дольше на той же задаче и батарее. Да - месяц 1-й девайс будет продаваться. Но потом появится лучший девайс, пользователи увидят разницу и перестанут покупать 1-й девайс. Вообще перестанут. Вы бы наверное и сами такой не купили, если рядом лежит однозначно лучший, не правда ли? 

И работодатель, который не хотел "тратить ЗП на долгие изыскания" и нанял быдлокодера, сляпавшего продукт побыстрее, разорится. Потому что за месяц продаж никак не окупить разработки сложного продукта. И конечно уволит быдлокодера. Хотя будет уже поздно.....

 

PS: Нет - никогда Вам не стать работодателем. Потому что не понимаете таких базовых вещей.