k155la3 27 8 октября, 2022 Опубликовано 8 октября, 2022 · Жалоба В 07.10.2022 в 18:06, iiv сказал: Ключевой вопрос у меня - какой стиль написания на С++ использовать, чтобы 1. алгоритмы можно было быстро без бубнов компилировать на разных архитектурах с разными длинами слов и разными размерами индексов, 2. чтобы можно было на одной архитектуре отладить и ожидать, что на остальных все или сразу заработает, или потребуется минимум отладки, 3. производительность не потерять. То есть подходит под этот стиль template с типами typename, или есть какие-то еще более нативные в С++ конструкции для такого рода разработки? 1. В код вставляйте проверочные блоки кода (которые будут выключены в Release) вроде if( sizeof( MyTypeVar32) != 4 ) . . . // porting error и вообще, стараться обрабатывать все ошибочные ситуации своим кодом, не дожидаясь пока это вылезет как ошибка/warn компилятора или глюк. 2. Грех не использовать такую возможность. 3. Хорошо, если все зависит от автора ПО. Если тормозить будет системный или библиотечный "вызов" - все-равно придется разбираться индивидуально. Но это на порядок проще, если известно что на другой платформе эта проблема отсутствовала. >> Ключевой вопрос у меня - какой стиль написания на С++ использовать, чтобы Насчет "стиля написания" один из главных принципов - "проработка" интерфейсов функций-классов, библиотек, драйверов итд. Оно-же - один из принципов работы с ООП, а их там несколько. Чтобы для добавления или модификации функциональности не приходилось переписывать "всю консерваторию" с первого этажа по 10. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 9 октября, 2022 Опубликовано 9 октября, 2022 · Жалоба 15 часов назад, k155la3 сказал: 1. В код вставляйте проверочные блоки кода (которые будут выключены в Release) вроде if( sizeof( MyTypeVar32) != 4 ) . . . // porting error Вообще-то для такого есть специальные стандартные макросы: assert_static(expression) (или ASSERT_STATIC(expression)). Они часто уже реализованы в компиляторе, а если нет - можно самостоятельно добавить. И выключать в Release их не надо. Какой смысл? Может вы попутали их с runtime-проверками (assert, ASSERT, VERIFY, etc.)? Вот тех полезно в Release выключать. 2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 9 октября, 2022 Опубликовано 9 октября, 2022 · Жалоба В 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). Если известно, что на целевой архитектуре имеются такие команды, то бывает полезно даже изменить алгоритм решения какой-то задачи, чтобы подстроиться под использование этих команд. Так как это может дать существенный прирост скорости выполнения. Но что делать на архитектурах, где таких команд нет??? Всё это приводит к тому, что (как я уже писал выше) универсальный код (компилируемый для разных платформ) очень часто значительно (иногда - кратно) уступает в производительности специализированном коду, заточенному под конкретную платформу. Поэтому, если производительность важна, то лучше для каждой платформы делать собственные реализации алгоритма. А общими делать только участки кода, для которых производительность не важна. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iiv 27 9 октября, 2022 Опубликовано 9 октября, 2022 · Жалоба Большое, спасибо k155la3, jcxz и всем советовавшим за очень важные и полезные замечания! Полностью согласен с мнением jcxz что на все архитектуры сделать один код не получится. У меня дополнительно есть специфика - то, что находится в моей библиотеке (которую я сейчас в основном через template переписал) связано с вычислительным алгоритмами, которые интенсивно используют плавающую точку. Более того, обычно я использую хорошо оптимизированные библиотеки BLAS/Lapack где, конечно это возможно. Понятно, что эти громоздкие библиотеки в восьмибитные контроллеры физически не лезут, но на них я и не планировал тяжелые алгоритмы гонять, а для некоторых моих темплейтов мне достаточно подставить несколько уже в ручную отоптимизированных под заданную архитектуру функций из BLAS. Но, грубо говоря, соблазн иметь квазиньютоновский минимизатор с классом для аналитического вычисления градиента в том числе и на восьмибитнике имеется. Раньше я такого рода софты с обычных платформ на МК вручную конвертировал, а сейчас пытаюсь, с Вашими советами разумно унифицировать. Про using - не додумался, про assert_static - не звал, спасибо огромное за советы и общие наставления как это разумно организовать! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 10 октября, 2022 Опубликовано 10 октября, 2022 · Жалоба 12 часов назад, iiv сказал: про assert_static - не знал, Если захотите узнать - ищите static_assert(). 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться