[k155la3 26]

В 07.10.2022 в 18:06, iiv сказал:

Ключевой вопрос у меня - какой стиль написания на С++ использовать, чтобы

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

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

3. производительность не потерять.

То есть подходит под этот стиль template с типами typename, или есть какие-то еще более нативные в С++ конструкции для такого рода разработки?

1. В код вставляйте проверочные блоки кода (которые будут выключены в Release) вроде if( sizeof( MyTypeVar32) != 4  ) . . . // porting error

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

2. Грех не использовать такую возможность.

3. Хорошо, если все зависит от автора ПО. Если тормозить будет системный или библиотечный "вызов" - все-равно придется разбираться индивидуально. Но это на порядок проще, если известно что на другой платформе эта проблема отсутствовала.

>> Ключевой вопрос у меня - какой стиль написания на С++ использовать, чтобы

Насчет "стиля написания" один из главных принципов - "проработка" интерфейсов функций-классов, библиотек, драйверов итд. Оно-же - один из принципов работы с ООП, а их там несколько. Чтобы для добавления или модификации функциональности не приходилось переписывать "всю консерваторию" с первого этажа по 10. 

[jcxz 220]

15 часов назад, k155la3 сказал:

1. В код вставляйте проверочные блоки кода (которые будут выключены в Release) вроде if( sizeof( MyTypeVar32) != 4  ) . . . // porting error

Вообще-то для такого есть специальные стандартные макросы: assert_static(expression) (или ASSERT_STATIC(expression)). Они часто уже реализованы в компиляторе, а если нет - можно самостоятельно добавить.

И выключать в Release их не надо. Какой смысл? Может вы попутали их с runtime-проверками (assert, ASSERT, VERIFY, etc.)? Вот тех полезно в Release выключать.

[jcxz 220]

В 07.10.2022 в 18:06, iiv сказал:

3. производительность не потерять.

Касательно производительности: чтобы её не потерять, скорее всего придётся заводить более пёстрый набор типов переменных. Так как на той же Cortex-M архитектуре, если скажем переменная может принимать значения в пределах байта, то хранить её прагматичнее в unsigned char (команды LDRB/STRB почти такие же по весу, что и LDR/STR). Но вот использование unsigned char в выражениях и в аргументах/return-значениях функций в некоторых случаях может приводить к генерации множества лишних команд расширения значения (UXT../SXT..). А значит - к неэффективному коду.

Кроме того, на 32-битных архитектурах, большая разрядность регистров позволяет в некоторых алгоритмах в одной переменной объединять сразу несколько переменных (например: в старших битах - счётчик цикла, а в младших битах - какие-нить флажки, битовые маски, etc.). При правильном построении алгоритма, работа с частями такой комбинированной переменной не добавит лишних команд, но позволит компилятору разместить в регистрах больше переменных, а значит - повысить производительность кода. На малоразрядных архитектурах такой финт уже не пройдёт - потребуются действительно отдельные переменные. А значит эффективный производительный код, для такого алгоритма, будет выглядеть совершенно по-разному для разных архитектур.

Ещё один момент - наличие специализированных команд (типа CLZ, USAT, команд умножения/деления, команд эксклюзивного доступа или команд DSP- расширений на Cortex-M). Если известно, что на целевой архитектуре имеются такие команды, то бывает полезно даже изменить алгоритм решения какой-то задачи, чтобы подстроиться под использование этих команд. Так как это может дать существенный прирост скорости выполнения. Но что делать на архитектурах, где таких команд нет???

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

[iiv 19]

Большое, спасибо k155la3, jcxz и всем советовавшим за очень важные и полезные замечания!

 

Полностью согласен с мнением jcxz что на все архитектуры сделать один код не получится.

 

У меня дополнительно есть специфика - то, что находится в моей библиотеке (которую я сейчас в основном через template переписал) связано с вычислительным алгоритмами, которые интенсивно используют плавающую точку. Более того, обычно я использую хорошо оптимизированные библиотеки BLAS/Lapack где, конечно это возможно. Понятно, что эти громоздкие библиотеки в восьмибитные контроллеры физически не лезут, но на них я и не планировал тяжелые алгоритмы гонять, а для некоторых моих темплейтов мне достаточно подставить несколько уже в ручную отоптимизированных под заданную архитектуру функций из BLAS.

 

Но, грубо говоря, соблазн иметь квазиньютоновский минимизатор с классом для аналитического вычисления градиента в том числе и на восьмибитнике имеется. Раньше я такого рода софты с обычных платформ на МК вручную конвертировал, а сейчас пытаюсь, с Вашими советами разумно унифицировать.

 

Про using - не додумался, про assert_static - не звал, спасибо огромное за советы и общие наставления как это разумно организовать!

[Сергей Борщ 132]

12 часов назад, iiv сказал:

про assert_static - не знал,

Если захотите узнать - ищите static_assert().