Комментарии 32
Какой компилятор вы использовали и с какими опциями оптимизации?
Можно увидеть целиком исходники на проект где вы запускали измерения?
Не совсем понятно почему операции с int16 должны быть дольше чем с int32. и почему вычитание и сложение выполняются за разное время
CubeIDE, gcc (-std=gnu11, --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb - Os)
На операциях int16 применяются дополнительные команды на преобразование полуслова 16bit в слово в 32. Процессор не может оперировать половиной регистра.
Два операнда по 16bit - две дополнительные команды ассемблера при загрузке данных из памяти в 32bit регистры процессора, плюс ещё одна дополнительная команда при выгрузке результата из регистра процессора в память.
Итого на три такта больше, чем сложение целых в формате 32bit, где всего четыре команды: две загрузки, одно сложение и одна выгрузка:
08003146: ldr r2, [r7, #12]
08003148: ldr r3, [r7, #8]
0800314a: add r3, r2
0800314c: str r3, [r7, #4]
Применяемая точность измерения сверхмалых интервалов +/- 1 такт, поэтому есть расхождения в 1-2 такта времени срабатывания int16 и int32, однако это не существенно для изложенной темы.
Какой gcc? Почему -Os, если у вас целью является скорость?
Исходники тестируемого можно увидеть, или у вас чистейшая синтетика, когда вы 16 битами умудряетесь запутать оптимизатор и неоптимально сгенерировать бинарник?
Если пример реальный и разница в 2-4 такта настолько заметна — интересно хоть в двух словах узнать, что происходит, возможно проблему нужно решать не с разрядностью данных.
Ответы в порядке поступления вопросов.
Компилятор:
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
Цель - не скорость.
Цель - повышение утилизации, интенсивности работы бюджетного MCU.
Оптимизация по размеру (-Os) выбрана на основании требований к памяти - 32Кб (64К крайний предел).
Что происходит - дополнительные издержки на преобразование полуслов в слова и обратно на операциях с данными, менее слова.
Оптимизатор запутать нельзя, т.к. на примитивных операциях он отдыхает. Да, и трудно представить, как оптимизировать формулу:
A = B + C, где все слагаемые int ?
Казалось бы ...
Отключение оптимизации (-O0) ухудшило арифметику на int16:
+=========================================
+-------------- # 1 ---------------------
+-- RELEASE at 15:51:09
+-- CPU:48 MHz, STM32 ARM Cortex M4
+-----------------------------------------
+-- cpu time of simple int16 "C"
fn: i3 = i1 + i2, cc: 11, us: 0
fn: i3 = i1 - i2, cc: 11, us: 0
fn: i3 = i1 * i2, cc: 11, us: 0
fn: i3 = i1 / i2, cc: 13, us: 0
fn: i3 = i1 % i2, cc: 14, us: 0
--- is:715826417 ---
+-----------------------------------------
+-- cpu time of simple int32 "C"
fn: l3 = l1 + l2, cc: 4, us: 0
fn: l3 = l1 - l2, cc: 4, us: 0
fn: l3 = l1 * l2, cc: 4, us: 0
fn: l3 = l1 / l2, cc: 8, us: 0
fn: l3 = l1 % l2, cc: 10, us: 0
--- ls:223077021 ---Причина замедления арифметики int16 - издержки на выравнивание границ и слов.
Формула на "С":
A = B + C
все переменные int16
Соответствующий машинный код:
08002a2a: ldrh r3, [r7, #6]
08002a2c: sxth r3, r3
08002a2e: uxth r2, r3
08002a30: ldrh r3, [r7, #4]
08002a32: sxth r3, r3
08002a34: uxth r3, r3
08002a36: add r3, r2
08002a38: uxth r3, r3
08002a3a: sxth r3, r3
08002a3c: strh r3, [r7, #2]Формула на "С":
A = B + C,
Все переменные int32
Соответствующий машинный код:
08003146: ldr r2, [r7, #12]
08003148: ldr r3, [r7, #8]
0800314a: add r3, r2
0800314c: str r3, [r7, #4]Как говорится, найдите 10 отличий. :-)
К вопросу о доверии к методу измерения.
Ассемблерные команды семейства Thumb2 выполняется, в основном, за 1 такт.
Если посчитать строчки ассемблера, то их число совпадёт с результатом соответствующих измерений в тактах из таблице выше по тексту.
А исходники можно увидеть? А то бессмысленные последовательности из sxth-uxth наводят на мысль о каких-то странных преобразованиях типов.
Поигрался вот с разными версиями arm gcc - все упорно выдают то, что ниже выдал сам из головы.
в случае если исходные операнды и результат имеют единственный тип - int16, инструкции sxth и uxth не влияют на итоговый результат и поэтому лишены смысла. Компилятор генерирует какой-то слишком не оптимальный код
Внезапно, отключение оптимизации замедлило выполение.
Как отдыхает оптимизатор и почему? Вопрос зачем он делает неоптимально.
Реального кода нет, есть непонятно какие куски, с очевидно неоптимальным набором инструкций.
Похоже, что у вас где-то в погоне за «утилизацией» в макросах/коде творится страшное и компилятор не может понять, что от него хотят.
Внезапно, отключение оптимизации замедлило выполение.
Это нормально.
Забавно иначе, включение оптимизации замедляет работу алгоритма из 7-и строчек. :-)
Такой случай в примере для FPU x86 здесь, включая исходник:
https://habr.com/ru/post/562572/
Только, что току с того исходника? Зафиксировали факт. Двигаемся далее.
Разработчики компиляторов - они то же программисты, а это значит, что в их работе то же бывают косяки. :-)
компилятор не может понять, что от него хотят
Компилятор не должен "понимать". Компилятор обязан просто переводить алгоритмы программиста в машинный код, ибо программисту виднее, что он хочет посчитать и как. (imho)
В противном случае, имеем то, что имеем.
Вместо обсуждения прикладной задачи по планированию и учёту сверхмалых интервалов времени (вводная статья), профи с уважаемого форума тратят драгоценное внимание на косяки и тараканы в gcc - плотники до блеска натирают молотки вместо забивания гвоздей. :-)
С другой стороны, замусорить машинный код командами, "съёдающими" время без искажения задачи, в режиме -O0, и демонстрировать удивительную производительность с оптимизацией, - отличный маркетинговый ход! Троекратное "у-ра" маркетологам gcc. /* сарказм */ :-)
Но, я за программистов. :-)
У компилятора все правильно.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
A.6.1 Integral Promotion
A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.
Сама инструкция ldrh всегда осуществляет integral promotion (на этой архитектуре невозможна запись в половину регистра), только в случае знакового типа нужна её знаковая версия (ldrsh). Но даже если с -O0 компилятор принципиально разделяет чтение памяти и расширение типа, откуда две инструкции расширения (sxth, затем uxth)? В вашей цитате говорится "или к int или к unsigned int", но не "к int, затем к unsigned int", да и для исходного int16 должна работать первая половина жирного текста, т.е. приводить должны к int. Однако складываются почему-то результаты uxth.
Покажите пример с int16. Совершенно непонятно откуда там лишние операции. Для работы с памятью есть инструкции и для halfword и для byte, вот навскидку сложение двух int16 с тем же кол-вом инструкций:
ldrsh r0, [r2]
ldrsh r1, [r3]
add r0, r1
strh r0, [r2]Дизассемблер машинного кода без оптимизации (-O0) для int16 и int32, версия компилятора здесь:
https://habr.com/ru/post/591925/comments/#comment_23756785
Глядя на дизассемблер понятно, откуда набегают лишние такты.
Код на "C" для 16bit (сложение) выглядит так:
__IO int16_t i1, i2, i3, is;
i1 = RAND_NUMBER_16;
i2 = RAND_NUMBER_16;
i3 = 0;
i3 = i1 + i2;
is += i3;Код на "C" для 32bit (сложение) выглядит похоже:
__IO int32_t i1, i2, i3, is;
i1 = RAND_NUMBER_32;
i2 = RAND_NUMBER_32;
i3 = 0;
i3 = i1 + i2;
is += i3;Участки кода для других арифметических операторов выглядят идентично, за исключением арифметического оператора в строке #7.
Так, а смысл в -О0 смотреть машкод?
Что там за кулисами RAND_NUMBER_x? Вдруг там у вас макрос функции дёргает или ещё что-то страшное творит? Что там с переполнениями?
Да нет там ничего "военного":
#define RAND_NUMBER_16 (int16_t)((rand() - RAND_MAX / 2) % INT16_MAX )Целочисленные переполнения - с этим тоже всё хорошо - проверенная временем практика непрерывной индексации циклических процессов.
У сборки -O0 cмысл в том, чтобы сузить зону поиска трабла, через исключение влияния оптимизатора кода.
Кстати, а для какого микроконтроллера Вы генерируете проверочный код?
У компилятора все правильно.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
A.6.1 Integral Promotion
A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.
Какой компилятор, какие опции, где хотя бы дизасм бинарника?
По поводу неосторожного использования FP — вопросов ни у кого нет, а вот про разницу int16 и int32 уже закрадываются сомнения в правильности измерений(вы сами упоминаете выравнивания и прочее) и тестовой инфраструктуры.
про разницу int16 и int32 уже закрадываются сомнения в правильности измерений.
Замедление скорости вычислений для int16 обосновано в ответе на комментарий выше. Там же ассемблерный код для оператора:
L3 = L2 + L1,
где все переменные с типом int32.
Для той же формулы с переменными int16, в машинном коде появятся дополнительные команды, преобразующие машинное полу-слово в слово и обратно.
Уже ответили, что есть асм-инструкции для полуслов.
Нужно смотреть машкоды и конкретный тулчейн с его опциями. Ну и «синтетичность» задачи.
Пока выглядит очень странно.
Да, нормально оно выглядит. :-)
В ответе выше дизассемблер машинного кода, полученного штатным gcc из исходника на "C" с опцией -O0.
Допускаю, что ручками на макро-ассемблере можно делать более эффективный код, однако тогда теряется смысл языка высокого уровня, а стоимость разработки поднимется на никому не нужную высоту.
Зачем смотреть на -О0, вы можете объяснить?
Для оценки соответствия машинного кода и кода на "C"; для снижения энтропии системы сборки через исключение модуля искажающего первичную алгоритмическую основу.
Дополнительная аргументация здесь:
https://habr.com/ru/post/591925/comments/#comment_23758799
double в 2 раза медленнее, чем float на Cortex M0;
double в 27 раз медленнее, чем float на Cortex M4;
Неудивительно так как у Cortex M0 нету FPU, и double и float вычисляются прогаммно. А вот Cortex M4 имеет FPU, но SP и потому float намного быстрее double. Так что
Есть риск свести "на нет" все преимущества FPU на Cortex M4, используя без должной осмотрительности double.
нету никакого преимущества FPU на Cortex M4 на double.
Если нужен DP FPU, надо смотреть на Cortex M7
fn: i3 = i1 + i2, cc: 7, us: 0
fn: i3 = i1 - i2, cc: 9, us: 0
fn: i3 = i1 * i2, cc: 8, us: 0
Ничего, что команды сложения, вычитания и умножения на M0 выполняются за одинаковое время - 1 такт?
Достаточно ознакомиться с документацией.
developer.arm.com/documentation/ddi0432/c/CHDCICDF
Какой смысл измерять одиночные операции, которые обложены LDR/STR?
Если всё что делает микроконтроллер в вашей программе это выполняет одну(!) арифметическую операцию, о какой оптимизации идёт речь? Оно вам не нужно.
Простой отказ от int16 в пользу int32 повышает производительность участка программы приблизительно на 20%.
Вот тут уже речь идёт об «участке программы». О каком участке?
Да, за счёт дополнительного расширения знака 16-битные вычисления будет медленнее, но это нужно смотреть конкретный код, а не писать цифры «с потолка».
Зачем вы показываете дизасм с -O0, если запускаете с -Os?
Допускаю, что ручками на макро-ассемблере можно делать более эффективный код, однако тогда теряется смысл языка высокого уровня, а стоимость разработки поднимется на никому не нужную высоту.
Не нужно ничего писать.
Вышеозначеный древнючий GCC 5.4 с ключом (-mcpu=cortex-m0 -mthumb -Os) генерит
ldrh r2, [r0]
ldrh r3, [r1]
adds r3, r2, r3
strh r3, [r0]
Ничего, что команды сложения, вычитания и умножения на M0 выполняются за одинаковое время - 1 такт?
Согласен. В теории Вы правы и документация верна.
На практике простейшая операция выполняется минимум за 4 такта: два такта на загрузку двух операндов из памяти в регистры, один такт, как Вы правильно заметили, уходит на саму примитивную операцию, и один такт на возврат результата из регистра в память.
В эти 4 такта может легко вклинится обработчик прерывания, если ему приспичит. Есть множество других, объективных причин, влияющих на время выполнения простейших операций.
Однако вопрос не в том, как с этим бороться, а в том как это учитывать, планируя гарантированную производительность бюджетного устройства.
И какая разница? У вас для 32 бит из памяти в регистры и обратно нет операций загрузки? Между ними не «вклинивается обоаботчик прерываний, если ему приспичит»?
Бороться и учитыватт можно например алгоритмически, можно запрещая прерывания, можно ещё множеством способов если нужна гарантированная производительность.
Пока же вы меряете непонятно что, показывая какие-то обрывки ассемблера, которые никто воспроизвести не может(включая здравый смысл).
Вы правы, есть загрузка из памяти в регистры, и прерывания вклиниваются когда посчитают нужным.
В статье о поиске способа простого планирования и учёта времени работы ответственных участков кода оставаясь в парадигме языка "C".
Говоря о планировании, подразумеваем не обязательство, а цель, допускающую отклонение в пределах установленного допуска.
Это значит - без запретов прерываний, без порочного ожидания "delay()" и т.п.
Предположительное начальное приближения к решению задачи - подсчёт числа простейших арифметических операторов на языке "С" на контрольном участке кода.
Под простейшим оператором понимаем конструкцию типа: A = B + C, где A, B и C - переменные в RAM.
Время срабатывания простейших арифметических операторов "C" поддаётся измерению с удовлетворительно точностью (+/- 1 такт) без понижения абстракции до уровня ассемблера и машинных команд, в контексте синтаксиса "С".
При этом работа оптимизатора - последнее дело. Ибо, важнее на данном этапе смысловая проработка задачи и статистическая устойчивость атомарного замера малых промежутков времени без оглядки на платформу MCU и параметры сборки.
А потом выясняется что где-то ldr был из внешнего sdram и здравствуй добрая сотня тактов. А ваша переменная в памяти могла оказаться в l1d (который может присутствовать в конкретной имплементации контроллера на cortex-m), ccm/tcm, внешнем sram, внешнем sdram.
Даже не говоря по то что все развлечения в статье очень синтетические и даже не заикаются про latency. Что в разговоре про real-time, где актуально считать такты, но оперерировать не столько throughput, сколько предсказуемым временем реакции на событие.
Проектирование промышленных программ исключает обстоятельства, характеризуемые словосочетаниями "потом появляется", "вдруг" и т.п., ибо такие программы сопровождаются технической документацией, содержащей обязательный раздел "Технические условия эксплуатации", обоснованные в ТЭП ещё на этапе планирования разработки до создания исходного текста программы.
Время реакции на событие, предсказуемость времени реакции зависит от времени выполнения критических участков кода, обслуживающих событие. Об этом статья.
Практика всегда опирается на результат с заданной степенью точности. Достижение результата с заданной степенью точности всегда удовлетворяет практиков без оглядки на способ получения такого результата.
Приоритет способа в ущерб результату - это область теоретиков и учеников, допускающая непредвиденные обстоятельства типа "потом появляется", "вдруг" и т.д.
При всём уважении к теоретикам, здесь о практике.
ARM Cortex M* — сколько «весит» примитив?