Xenia 45 6 сентября, 2014 Опубликовано 6 сентября, 2014 · Жалоба а мне лично Форта (Forth) за глаза хватает. Форт использовать нельзя - в нем обратная польская запись! :) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopa 0 6 сентября, 2014 Опубликовано 6 сентября, 2014 (изменено) · Жалоба Форт использовать нельзя - в нем обратная польская запись! :) А Вы попробуйте :) Или например Factor язык. Тогда будет предметный разговор без этих "страшилок" Преимуществ в "польской" записи больше чем мнимых недостатков. P.S. Некоторых задач вне использования Форт даже не представляю трудоёмкость и возможность их решения. Изменено 6 сентября, 2014 пользователем Kopa Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 6 сентября, 2014 Опубликовано 6 сентября, 2014 · Жалоба Могу переписать медиану, так чтобы был использован std::nth_element. Сравним. Вот ссылка на мой код: https://bitbucket.org/Glavny/medest/src В Keil MDK-Lite 5.11 он работает в два раза быстрее чем код klen (в репозитории его нет. но если надо, могу выложить здесь). Так у klen-а (сылка) тоже используется nth_element (class TMedianFilterNth). А выигрыш, думаю, от того, что klen производит копирование всего массива при каждом вычислении медианы. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Major 0 7 сентября, 2014 Опубликовано 7 сентября, 2014 · Жалоба А выигрыш, думаю, от того, что klen производит копирование всего массива при каждом вычислении медианы. Мысль ошибочная. Это проблема второго порядка малости (смотрел профайлером в MSVC и в Keil), оставить каждый-раз-копировать копирование рука не повернулась. Основная идея состоит в том, чтобы использовать упорядоченную ранее последовательность (std::find). Да и спор был не про скорость. А про качество кода и применимость С++. Нет причин для того чтобы не использовать ++ (хотя бы шаблоны + STL) в разработке программ для МК. Этот код на MSVC обгоняет код klen в пять раз (на N=64). Это означает, что с развитием общего знания о сортировках ваш код улучшается сам по себе. Использование STL: читаемость, портабельность, уверенность в безошибочности. Есть нюансы, но они обычно относятся к сложности алгоритмов и проблеме выбора контейнера. Про "ни как причин", это я погорячился. Если это std, то нет причин не использовать алгоритмы, они как правило noexcept. В остальном надо думать. Но если у вас при работе с контейнером возникает исключение (out of range например), то у вас и без std все плохо. Я предпочитаю чисто статическую раскладку памяти. Так чтобы на момент старта программы все capacity были определены и в дальнейшем не происходило изменения емкости. Есть такой документ (с участием Страуструпа) "JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS FOR THE SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAM": http://www.stroustrup.com/JSF-AV-rules.pdf Эти правила совсем жесткие, но к прочтению рекомендуются. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 7 сентября, 2014 Опубликовано 7 сентября, 2014 · Жалоба Основная идея состоит в том, чтобы использовать упорядоченную ранее последовательность (std::find). Да и спор был не про скорость. А про качество кода и применимость С++. Моя реплика была именно про скорость, остальной спор мне не особо интересен. То есть, выигрыш от того, что на изначально упорядоченной последовательности std::nth_element отрабатывает быстрее? Выходит, выигрыш чисто алгоритмический, а не от более правильного использования C++? :) Но если у вас при работе с контейнером возникает исключение (out of range например), то у вас и без std все плохо.Проблема не в возникновении исключений, а в их испоьзовании вообще. Как только появляется намёк на использование исключений, -- сразу же подтягиваются динамическое распределение памяти и куча нежелательного кода (по крайней мере в gcc). (Я тоже предпочитаю статическую раскладку). Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 7 сентября, 2014 Опубликовано 7 сентября, 2014 · Жалоба Кому интересно (стр. 4). Вот ссылка на мой код: https://bitbucket.org/Glavny/medest/src В Keil MDK-Lite 5.11 он работает в два раза быстрее чем код klen (в репозитории его нет. но если надо, могу выложить здесь). В MSVC на окне 64 в 5 раз быстрее. Если компилировать для контейнера container_std_array_t, то даже std::vector не зацепится. Неплохо, неплохо. Вплотную приблизились к лучшим образцам на C-и. Ну всего лишь в полтора раза проиграли алгоритму Ekstrom. ---------------------------------------------- Algorithm 'Qsort' (standart C library ): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=64.1 Measured min. time(us)=0.2 Measured aver.time(us)=44.9 ---------------------------------------------- Algorithm 'Shell' (http://electronix.ru/forum/index.php?s=&showtopic=114436&view=findpost&p=1181687): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=26.8 Measured min. time(us)=11.4 Measured aver.time(us)=17.2 ---------------------------------------------- Algorithm 'Select' (Numerical Recipes in C, 8.5 Selecting the Mth Largest p.341): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=16.1 Measured min. time(us)=1.8 Measured aver.time(us)=5.6 ---------------------------------------------- Algorithm 'Selip' (Numerical Recipes in C, 8.5 Selecting the Mth Largest p.343): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=46.8 Measured min. time(us)=17.3 Measured aver.time(us)=36.3 ---------------------------------------------- Algorithm 'Xenia' (http://electronix.ru/forum/index.php?s=&showtopic=114436&view=findpost&p=1180687): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=37.9 Measured min. time(us)=1.5 Measured aver.time(us)=15.8 ---------------------------------------------- Algorithm 'Neiver' (http://electronix.ru/forum/index.php?s=&showtopic=114436&view=findpost&p=1180944): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=15.8 Measured min. time(us)=2.7 Measured aver.time(us)=3.5 ---------------------------------------------- Algorithm 'Ekstrom' (http://embeddedgurus.com/stack-overflow/tag/median-filter/): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=9.7 Measured min. time(us)=2.0 Measured aver.time(us)=2.8 ---------------------------------------------- Algorithm 'Klen' (http://electronix.ru/forum/index.php?s=&showtopic=114436&view=findpost&p=1180679) ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=63.5 Measured min. time(us)=12.6 Measured aver.time(us)=39.0 ---------------------------------------------- Algorithm 'Major' (http://electronix.ru/forum/index.php?showtopic=122083&view=findpost&p=1278129 ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=12.6 Measured min. time(us)=3.8 Measured aver.time(us)=4.9 ---------------------------------------------- Algorithm 'VAI' (http://caxapa.ru/170626.html): ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=36.3 Measured min. time(us)=28.4 Measured aver.time(us)=29.2 Здесь использовался IAR C/C++ 6.50.6 на платформе Kinetis K70 (150 МГц, внутренняя RAM) Понятно что мотивов переходить на C++ пока никаких. Да, алгоритм nth_element неплох в составе C++, но что-то многовато обвязки чтобы его использовать. А алгоритм KLEN оказался еще и непереносимым на RTOS, поскольку использовал статическую инициализацию вектора. В окружении RTOS это вызывало аборт. Вектора в шаблонах то используют malloc. А он на этапе старта осью не поддерживается. Т.е. резюме: кроме лишней писанины шаблоны C++ вызывают дополнительные проблемы портирования. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Major 0 7 сентября, 2014 Опубликовано 7 сентября, 2014 · Жалоба Ради одного nth_element переходить на С++ даже вредно. Разговор не об этом. По таблице: алгоритм Neiver надо исключить. Он не выдает честную медиану. То есть он фильтр, но не медианный. Это видно на случайном потоке. Остальные образцы (кроме klen) не проверял на честность. Поэтому выражу обобщенное сомнение. P.S. Ekstrom заценил, изящно сделано. Добавлено: По мотивам Ekstrom внес изменения в свой алгоритм. Скорость выросла на 41% (в Keil и MSVC одинаковый прирост). На числовых объектов различий с Ekstrom нет (код в репозитории). Потенциально, подход Ekstrom все равно лучше (stopper можно переделать). В моем варианте двойное копирование объектов, и необходимо чтобы T имел операцию сравнения ==. По большому счету это УГ. Я придумал как избежать эти две беды, но получится Ekstrom вывернутый мехом внутрь. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 8 сентября, 2014 Опубликовано 8 сентября, 2014 · Жалоба Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! :) Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса.Именно так и делаю. Процедуру прерывания не обязательно делать членом класса. Более того, была плата с разными интерфейсами (UART, CAN, SPI....), это не помешало сделать классы/объекты. Если возникает проблема, которую среди всего форума решили только два человека, то этот факт уже настораживает. Настораживает тем, что некое средство требует для своего использования определенных сверхспособностей, отсутствующих у большинства.это вообще не проблема, и не нужно ни каких сверхспособностей. Если 5-ый этаж проблема, чем 1-ый не устраивает? Если есть причины не использовать классы и шаблоны, почему нужно переходить на СИ? Чем с++ без ООП не устраивает? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 8 сентября, 2014 Опубликовано 8 сентября, 2014 · Жалоба Что-то я не понял последних сообщений в дискуссии. Вы алгоритмами меряетесь или языками? Неужели на C++ можно написать более производительную программу, чем на C? Может, вернемся к ассемблеру? :rolleyes: Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 8 сентября, 2014 Опубликовано 8 сентября, 2014 · Жалоба По мотивам Ekstrom внес изменения в свой алгоритм. Скорость выросла на 41% (в Keil и MSVC одинаковый прирост). На числовых объектов различий с Ekstrom нет (код в репозитории). Что-то "не выходит каменный цветок" :laughing: ---------------------------------------------- Algorithm 'Major' (http://electronix.ru/forum/index.php?showtopic=122083&view=findpost&p=1278129 ---------------------------------------------- Results CRC = 7CBB Number of samplles = 31 Number of iterations = 10000 Measured max. time(us)=65.5 Measured min. time(us)=0.0 Measured aver.time(us)=20.1 Хорошо хоть результат правильный. Алгоритм Neiver действительно иногда дает неправильный результат (но достаточно редко), поэтому я его оставил. Там наверно всего одно условие добавить надо, это удлинит его максимум на 0.1 мкс Что-то я не понял последних сообщений в дискуссии. Вы алгоритмами меряетесь или языками? Неужели на C++ можно написать более производительную программу, чем на C? Может, вернемся к ассемблеру? :rolleyes: Меряемся эффективностью, разве непонятно. Эффективность это комплексный параметр. Насколько проще найти алгоритм на C-и , насколько легче его отладить, насколько легче запустить на реальном железе, насколько легче рефакторить, насколько легче вообще опубликовать и объяснить другим ... Все в контексте микроконтроллеров, конечно. Имеете что-то по ассемблеру? Давайте! А то с чего это любители C++ так нервничают. Он же такой мощный этот C++, красивей не бывает. А уж как он облегчает описание реального мира. Сидели бы молча и хранили бы секрет своего могущества. Страуструп неплохой НЛП-шник, это надо признать. ;) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Abell 0 8 сентября, 2014 Опубликовано 8 сентября, 2014 · Жалоба Может, вернемся к ассемблеру? :rolleyes: +1 :) У "правильного" программиста на ассемблере со временем накапливается своя библиотека решений, причем - досконально отработанных, оптимизированных и наглядных, так что программирование на ассемблере сложности уже не представляет :laughing: ИМХО, ассемблер - единственный язык, понятный и машине, и человеку, все остальное - лишь оболочки и переводчики разной степени кривости :laughing: Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Major 0 8 сентября, 2014 Опубликовано 8 сентября, 2014 · Жалоба Общение двух, это излишне и уже не по теме получается. По С/C++ на МК: понял что писать можно только если приперло. После C++11 и других языков все кажется серым и убогим. По медиане: сделал обобщенный алгоритм, который принимает любой тип объектов с оператором сравнения '<' (другие операции не нужны). Сложный объект копируется один всего раз. Функция nth_element оказалась не нужна (обошлось min и max_elements). На ПК обгоняет Ekstrom в 1,7 раз (N=32, случайный поток + пила). На единицу выходят только для N=4. Вечером залью в реп. Кому надо пользуйте, вопросы можно в личку. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 13 сентября, 2014 Опубликовано 13 сентября, 2014 · Жалоба В одной канторе ПО для МК(для всякой мелочи) пишут исключительно на UML, а вы говорите С++ не для эмбэддед. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Russky 0 17 ноября, 2014 Опубликовано 17 ноября, 2014 · Жалоба Всем привет! Очень интересная тема! Люблю такие. :) Мне показалось, что большенство ответов пытаются перевести обсуждение asm/C/C++/C# (ява как аналог C#) из технологической области в филосовскую. Это не правильно. Я знаком со всей линейкой и вот что скажу. По идее переходя от этапа к этапу, т..е. от ами к С, к С++ и к С# мы жертвуем чем-то ради достижения чего-то. При переходе от ассемблера, мы унифицируем структуру процессора (его ассемблер на все случаи жизни) в язык С. При этом обязанность использования ассемблера максимально эффективно мы отдаем компилятору. При переходе к С++ мы унифицируем вызовы виртуальных ф-й в вызов виртуальных методов и наследование. И еще динамическое размещение объектов. (С++ имеет смысл только если используется virtual. Все остальное в нем вторично). Оптимальность вызова и размещение памяти мы снова передаем компилятору. При переходе к С# мы вообще переходим от компилятора к интерпретатору. Это когда компилятор думает не о том как преобразовать язык в ассемблер, а о том, как вызвать блок из фреймворка (библиотеки оптимально реализованных блоков). И вот этот момент очень важен и как-то не прозвучал здесь. Работа с памятью и указатели, это все вторично. Изначально .NET можно сравнить с громадной DSP библиотекой в которой содержаться все блоки обработки, а C# это такой язык, который эти оптимально реализованные блоки соединяет. Чисто симулинк. :) Канечно, при каждом переходе мы приносим в жертву производительность. Но приобритаем мы функциональность и удобство в отладке и разработке. Но процесс этот нелинейный. Чем сложнее приложение, тем меньше будет разница в производительности кода написанного на С# (с использованием оптимизированных библиотек, написанных на С или даже на asm) и кода написанного на С. В связи с тем, что все больше ф-й уже реализованно в виде оптимизированных библиотек, выигрывает тот, кто может не реализовывать и писать эти самые библиотеки, а соединять блоки между собой и использовать их. Лично мне очень нравится C#. Просто потрясный язык и среда. MSVS13 просто фантастика! Но даже VS2008 неплохо, по сравнению с CCS и эклипсом. :) И еще. Стоимость процессоров и памяти упала настолько, что смысла выбирать и оптимизировать ее просто нет. И совсем еще. Переводя разработку для устройств на C#, вы автоматом переносим разработку из области embedded в разработку software. Это совсем другие правила, стоимость разработки и рынок труда. :) В общем резюмируя: самые критические по производительности и времени части я пишу а ассемблере. Менее критические на С. Затем, инициализацию и размещение real-time объектов я пишу на С++. Просто потому что это удобно. И приложения не критические к производительности, и где это возможно, я пишу на С#.Отказываться от asm, С или С++ я не собираюсь, хотя мой любимый язык именно C#. Как-то так. :) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 17 ноября, 2014 Опубликовано 17 ноября, 2014 · Жалоба При переходе к С++ мы унифицируем вызовы виртуальных ф-й в вызов виртуальных методов и наследование. Не расскажете, чем виртуальные функции отличаются от виртуальных методов? И как одно "унифицируется" в другое? С++ имеет смысл только если используется virtual. Все остальное в нем вторично). <...> Затем, инициализацию и размещение real-time объектов я пишу на С++. Правильно ли я понял, что инициализация и размещение выполняются исключительно путём виртуальных вызовов? И ещё поясните, пожалуйста, что такое "real-time объекты"? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
