| |
|
  |
 С/С++, Почему до сих пор все сидят на древних языках вроде С и С++ |
|
|
|
|
 Sep 6 2014, 18:08
|
Знающий
Группа: Участник
Сообщений: 598
Регистрация: 22-08-05
Пользователь №: 7 861
|
Цитата(Xenia @ Sep 6 2014, 20:35)  Форт использовать нельзя - в нем обратная польская запись!  А Вы попробуйте Или например Factor язык. Тогда будет предметный разговор без этих "страшилок" Преимуществ в "польской" записи больше чем мнимых недостатков. P.S. Некоторых задач вне использования Форт даже не представляю трудоёмкость и возможность их решения.
Сообщение отредактировал Kopa - Sep 6 2014, 18:10
|
|
|
|
|
|
|
|
Sep 6 2014, 19:03
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(Major @ Sep 3 2014, 15:59) Могу переписать медиану, так чтобы был использован std::nth_element. Сравним. Цитата(Major @ Sep 6 2014, 01:57) Вот ссылка на мой код: https://bitbucket.org/Glavny/medest/srcВ Keil MDK-Lite 5.11 он работает в два раза быстрее чем код klen (в репозитории его нет. но если надо, могу выложить здесь). Так у klen-а ( сылка) тоже используется nth_element (class TMedianFilterNth). А выигрыш, думаю, от того, что klen производит копирование всего массива при каждом вычислении медианы.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Sep 7 2014, 03:07
|
Знающий
Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375
|
Цитата А выигрыш, думаю, от того, что 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Эти правила совсем жесткие, но к прочтению рекомендуются.
|
|
|
|
|
|
|
|
Sep 7 2014, 06:01
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(Major @ Sep 7 2014, 09:07) Основная идея состоит в том, чтобы использовать упорядоченную ранее последовательность (std::find).
Да и спор был не про скорость. А про качество кода и применимость С++. Моя реплика была именно про скорость, остальной спор мне не особо интересен. То есть, выигрыш от того, что на изначально упорядоченной последовательности std::nth_element отрабатывает быстрее? Выходит, выигрыш чисто алгоритмический, а не от более правильного использования C++? Цитата(Major @ Sep 7 2014, 09:07) Но если у вас при работе с контейнером возникает исключение (out of range например), то у вас и без std все плохо. Проблема не в возникновении исключений, а в их испоьзовании вообще. Как только появляется намёк на использование исключений, -- сразу же подтягиваются динамическое распределение памяти и куча нежелательного кода (по крайней мере в gcc). (Я тоже предпочитаю статическую раскладку).
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Sep 7 2014, 11:49
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(Major @ Sep 5 2014, 22:57) Кому интересно (стр. 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++ вызывают дополнительные проблемы портирования.
|
|
|
|
|
|
|
|
Sep 8 2014, 05:22
|
Профессионал
Группа: Свой
Сообщений: 1 261
Регистрация: 14-05-09
Из: Челябинск
Пользователь №: 49 045
|
Цитата(Xenia @ Sep 6 2014, 17:48) Скажем у МК есть 6 штук UART'ов (на разных портах), обмен с которыми организован одинаково. Казалось бы, такой обмен можно описать в виде класса, а затем на его основе создать объекты для каждого порта. Но не тут-то было! Процедуры прерывания у каждого порта свои, и далеко не очевидно, как сделать так, чтобы объект для данного порта вписался в нужные адреса. И это на фоне того, что начинающие вообще не могут организовать процедуру прерывания, как функцию члена класса. Именно так и делаю. Процедуру прерывания не обязательно делать членом класса. Более того, была плата с разными интерфейсами (UART, CAN, SPI....), это не помешало сделать классы/объекты. Цитата Если возникает проблема, которую среди всего форума решили только два человека, то этот факт уже настораживает. Настораживает тем, что некое средство требует для своего использования определенных сверхспособностей, отсутствующих у большинства. это вообще не проблема, и не нужно ни каких сверхспособностей. Если 5-ый этаж проблема, чем 1-ый не устраивает? Если есть причины не использовать классы и шаблоны, почему нужно переходить на СИ? Чем с++ без ООП не устраивает?
|
|
|
|
|
|
|
|
Sep 8 2014, 06:15
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(Major @ Sep 7 2014, 16:04) По мотивам Ekstrom внес изменения в свой алгоритм. Скорость выросла на 41% (в Keil и MSVC одинаковый прирост).
На числовых объектов различий с Ekstrom нет (код в репозитории). Что-то "не выходит каменный цветок"  Код ----------------------------------------------
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 мкс Цитата(ViKo @ Sep 8 2014, 08:45) Что-то я не понял последних сообщений в дискуссии. Вы алгоритмами меряетесь или языками? Неужели на C++ можно написать более производительную программу, чем на C? Может, вернемся к ассемблеру?  Меряемся эффективностью, разве непонятно. Эффективность это комплексный параметр. Насколько проще найти алгоритм на C-и , насколько легче его отладить, насколько легче запустить на реальном железе, насколько легче рефакторить, насколько легче вообще опубликовать и объяснить другим ... Все в контексте микроконтроллеров, конечно. Имеете что-то по ассемблеру? Давайте! А то с чего это любители C++ так нервничают. Он же такой мощный этот C++, красивей не бывает. А уж как он облегчает описание реального мира. Сидели бы молча и хранили бы секрет своего могущества.  Страуструп неплохой НЛП-шник, это надо признать. 
|
|
|
|
|
|
|
|
Sep 8 2014, 06:31
|
профессиональный дилетант
Группа: Участник
Сообщений: 866
Регистрация: 16-03-06
Из: Шебекино - Лысьва - Тюмень
Пользователь №: 15 292
|
Цитата(ViKo @ Sep 8 2014, 09:45) Может, вернемся к ассемблеру? +1 У "правильного" программиста на ассемблере со временем накапливается своя библиотека решений, причем - досконально отработанных, оптимизированных и наглядных, так что программирование на ассемблере сложности уже не представляет ИМХО, ассемблер - единственный язык, понятный и машине, и человеку, все остальное - лишь оболочки и переводчики разной степени кривости
--------------------
Скоро дело сказывается, да не скоро сказка делается, или тише будешь - дальше уедешь...   |
|
|
|
|
|
|
|
Nov 17 2014, 11:58
|
Частый гость
Группа: Участник
Сообщений: 84
Регистрация: 17-11-11
Пользователь №: 68 371
|
Всем привет! Очень интересная тема! Люблю такие. Мне показалось, что большенство ответов пытаются перевести обсуждение asm/C/C++/C# (ява как аналог C#) из технологической области в филосовскую. Это не правильно. Я знаком со всей линейкой и вот что скажу. По идее переходя от этапа к этапу, т..е. от ами к С, к С++ и к С# мы жертвуем чем-то ради достижения чего-то. При переходе от ассемблера, мы унифицируем структуру процессора (его ассемблер на все случаи жизни) в язык С. При этом обязанность использования ассемблера максимально эффективно мы отдаем компилятору. При переходе к С++ мы унифицируем вызовы виртуальных ф-й в вызов виртуальных методов и наследование. И еще динамическое размещение объектов. (С++ имеет смысл только если используется virtual. Все остальное в нем вторично). Оптимальность вызова и размещение памяти мы снова передаем компилятору. При переходе к С# мы вообще переходим от компилятора к интерпретатору. Это когда компилятор думает не о том как преобразовать язык в ассемблер, а о том, как вызвать блок из фреймворка (библиотеки оптимально реализованных блоков). И вот этот момент очень важен и как-то не прозвучал здесь. Работа с памятью и указатели, это все вторично. Изначально .NET можно сравнить с громадной DSP библиотекой в которой содержаться все блоки обработки, а C# это такой язык, который эти оптимально реализованные блоки соединяет. Чисто симулинк. Канечно, при каждом переходе мы приносим в жертву производительность. Но приобритаем мы функциональность и удобство в отладке и разработке. Но процесс этот нелинейный. Чем сложнее приложение, тем меньше будет разница в производительности кода написанного на С# (с использованием оптимизированных библиотек, написанных на С или даже на asm) и кода написанного на С. В связи с тем, что все больше ф-й уже реализованно в виде оптимизированных библиотек, выигрывает тот, кто может не реализовывать и писать эти самые библиотеки, а соединять блоки между собой и использовать их. Лично мне очень нравится C#. Просто потрясный язык и среда. MSVS13 просто фантастика! Но даже VS2008 неплохо, по сравнению с CCS и эклипсом. И еще. Стоимость процессоров и памяти упала настолько, что смысла выбирать и оптимизировать ее просто нет. И совсем еще. Переводя разработку для устройств на C#, вы автоматом переносим разработку из области embedded в разработку software. Это совсем другие правила, стоимость разработки и рынок труда. В общем резюмируя: самые критические по производительности и времени части я пишу а ассемблере. Менее критические на С. Затем, инициализацию и размещение real-time объектов я пишу на С++. Просто потому что это удобно. И приложения не критические к производительности, и где это возможно, я пишу на С#.Отказываться от asm, С или С++ я не собираюсь, хотя мой любимый язык именно C#. Как-то так.
|
|
|
|
|
|
|
|
Nov 17 2014, 13:47
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
QUOTE (Russky @ Nov 17 2014, 18:58) При переходе к С++ мы унифицируем вызовы виртуальных ф-й в вызов виртуальных методов и наследование. Не расскажете, чем виртуальные функции отличаются от виртуальных методов? И как одно "унифицируется" в другое? QUOTE (Russky @ Nov 17 2014, 18:58) С++ имеет смысл только если используется virtual. Все остальное в нем вторично).
<...>
Затем, инициализацию и размещение real-time объектов я пишу на С++. Правильно ли я понял, что инициализация и размещение выполняются исключительно путём виртуальных вызовов? И ещё поясните, пожалуйста, что такое "real-time объекты"?
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
