Вопросы по С/С++ (СИ)

Z_h_e

Можно особо критичные к скорости функции перенести в ОЗУ, коли ARM.

Реклама

Reflector

Z_h_e писал(а):

Можно особо критичные к скорости функции перенести в ОЗУ, коли ARM.

Разве что в CCM, из обычного ОЗУ исполняется медленнее.

Реклама

Z_h_e

Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,

Реклама

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

arkhnchul

ARV писал(а):

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

нет, это просто тип, без storage class-а.

Reflector писал(а):

компилятор по сути один

не то чтобы :dont_know:

Реклама

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Reflector

arkhnchul писал(а):

не то чтобы :dont_know:

Я пробовал компилить gcc небольшие примеры сишного кода и если их компилить как С++, то часто получался точно такой же бинарник.

Z_h_e писал(а):

Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,

Ок, проведем эксперимент:

Код:

volatile uint64_t a = -1;

for (int i = 0; i < 20; i++)
{
   a /= 7;
}

F429, работающий на 300MHz (6WS) выдает 2801 тактов при работе из флеша и 3440, для RAM, у которой никаких WS нет...
Для F103, работающего на 72MHz, получается 3516 vs 3627, все равно из флеша быстрее выполняется, даже без ART Accelerator.

Реклама

Реклама

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

uk8amk

Всем спасибо за высказывание мыслей.
Перечитав ответы, подумал ещё раз, пересмотрел код и пришёл к следующему итогу:
1. Действительно, первый вариант кода моего примера проще к восприятию.
3. Перечитал статьи в интернете, кое-что вспомнилось про квалификатор volatile.
2. В настоящий момент нет острой необходимости к ускорению вычислений. На тактовой 24МГц прерывание может "съесть" до 30мкс. При текущих оборотах энкодера это вполне допустимо(есть хороший запас). Если обороты возрастут и задержка станет недопустмой, то перейду на проц F103 72МГц. Также может освободится ресурс если пересмотреть сам алгоритм вычислений вместо попытки вручную оптимизировать переменные volatile.

Теперь ответы на вопрос почему много вычислений происходит в прерываниях:
1. Сигнал с энкодера имеет не совсем обычный вид(см рис.). Поэтому аппаратный интрефейс обычного энкодера не подходит.
2. Энкодер генерирует мало импульсов на оборот. Для отслеживания позиции используется экстраполяция с учётом ускорений диска. Ожидаемый интервал корректируется программой с каждым новым импульсом.

Реклама

Z_h_e

Reflector писал(а):

Ок, проведем эксперимент:

Чтобы не оффтопить, создал новый топик по этому поводу.

Реклама

ARV

arkhnchul писал(а):

нет, это просто тип, без storage class-а

для чего он введен? я так полагаю, что для тех платформ, где есть разные storage classes, с разным временем доступа, компилятор должен стремиться (очевидно, в зависимости от параметров оптимизации?) подбирать для переменных этих типов наиболее быстрый класс хранения... ведь auto - это значит "на усмотрение компилятора" в зависимости от контекста... вот как бы fast-типы это дополнительная подсказка компилятору. я не прав в своих предположениях?

Реклама

Oxford

Reflector писал(а):

arkhnchul писал(а):

или нет. Компилятор в общем случае не обязан этого делать

Этот register компилятор скорее всего проигнорит, т.к. в С++17 код с ним уже даже не компилится, а до этого он долго был depricated и игнорировался, потому учитывая общую кодовую базу компиляторов можно ожидать такое поведение и в С, но в том же gсс есть еще другая форма записи, с привязкой к конкретному регистру, вот тот register точно работает.

register это специфичная для компилятора функция. В KEIL (ARMCC) это позволяет использовать переменные именованные конкретным регистром на архитектуре ARM.

Синтаксис register unsigned int My_R0 __asm("r0");

Так же не забываем указывать директиву __inline или __forceinline для встраиваемой функции.

Реклама

arkhnchul

ARV писал(а):

для чего он введен?

процессоры (и память/конвееры/предсказатели/черти рогатые) могут по-разному работать с переменными разного размера. К примеру, x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные. На amd64 64-битные еще чуть быстрее 32-битных. Если скучно, можете потестировать :dont_know:

определения из gcc с линуксовым libc, x86-64:

Код:

arkhnchul@arkhost-scow:~$ gcc -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ long unsigned int
#define __UINT_FAST32_TYPE__ long unsigned int
#define __UINT_FAST64_TYPE__ long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char

там же, но 32 bit ABI:

Код:

arkhnchul@arkhost-scow:~$ gcc -m32 -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort
#define __INT_FAST16_TYPE__ int
#define __INT_FAST32_TYPE__ int
#define __INT_FAST64_TYPE__ long long int
#define __INT_FAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ unsigned int
#define __UINT_FAST32_TYPE__ unsigned int
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char

ARV писал(а):

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

еще раз - нет, это только тип. Storage class - отдельная сущность.

ARV писал(а):

ведь auto - это значит "на усмотрение компилятора"

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

Oxford писал(а):

register это специфичная для компилятора функция.

register это стандартный спецификатор, его обязаны понимать (не выполнять) все компиляторы.

Oxford

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

jcxz

uk8amk писал(а):

Я подумал, а нельзя ли включить оптимизацию над этой переменной в обработчиках прерываний и выключить в главном цикле. Всё это затевается чтобы немного сократить время выполнения обработчиков.

На входе в функцию скопировать эту переменную в локальную: uint v = v16;
И при каждом изменении этой переменной внутри функции обновлять сразу обе: v16 = v = <expression>;
Конечно не забывая про размерности и связанные с ними эффекты.
И естественно так можно делать при условии, что данная функция не может быть прервана другой, имеющей внутри записи в данную volatile-переменную. Т.е. - если прерыван-ия (-ие) на время выполнения такого кода запрещены или если данное прерывание имеет наивысший приоритет из всех, где есть записи в данную переменную.
Я везде именно так и работаю с volatile-переменными.

Добавлено after 9 minutes 4 seconds:

Reflector писал(а):

F429, работающий на 300MHz (6WS) выдает 2801 тактов при работе из флеша и 3440, для RAM, у которой никаких WS нет...

Сказки рассказываете. Максимальная тактовая ядра для F429 == 180МГц.

Добавлено after 5 minutes 5 seconds:

arkhnchul писал(а):

x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные.

Зависит от режима CPU. В 16-битном режиме как раз самыми быстрыми (в среднем) будут 16-битные операции (т.к. отсутствуют префиксы переопределения размера операнда).

Голимый

Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?

Reflector

jcxz писал(а):

Сказки рассказываете. Максимальная тактовая ядра для F429 == 180МГц.

Серьезно? Даже на 181 уже работать не будет?

arkhnchul

Голимый писал(а):

Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?

это значит, что программист пытается сказать "сия константа типа Unsigned Long". Некоторые (далеко не все) компиляторы его даже поймут.