Easyelectronics.ru

Электроника для всех
Текущее время: 23 окт 2019, 23:34

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/10pcs (Любой цвет!)
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 318 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13
Автор Сообщение
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 17:23 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
я где то писал что это идеально многопоточный буфер??

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 17:46 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1024
cheblin писал(а):
я где то писал что это идеально многопоточный буфер??
я писал что кольцевой буфер для обсуждаемый целей подходит намного лучше простого вектора.
хочется идеала - делай через мютекс.

Это классический неправильно написанный RingBuffer, они все как под копирку. Опять же классическое применение - это когда условный USART добавляет данные в обработчике прерывания, которые потом в основном цикле неспешно забираются, или наоборот. Если бы все работало как написано, т.е. сначала сохраняются данные, а потом инкрементится индекс или указатель, то никакие мютексы не нужны, нужен volatile, который гарантирует, что если, допустим, ждать когда в буфере что-то появится или наоборот освободится место, то при сравнении wr с rd их значения будут постоянно перечитываться, иначе все просто подвиснет. У тебя volatile есть и явно не просто ради того, чтобы негативно сказываться на производительности и все...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 17:55 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
нет.
без мютексов, в многопоточной среде, это работать НЕ будет...
даже атомик операции тут не помогут

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 18:10 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1024
cheblin писал(а):
нет.
без мютексов, в многопоточной среде, это работать НЕ будет...
даже атомик операции тут не помогут

Работает если, как я говорил, в прерывании данные добавляются, вне прерывания забираются, или наоборот, в буфер данные быстро добавили, потом в прерывании идет отправка. Простая реализация для одного из наиболее распространенных сценариев... Если же пишем в буфер в прерывании, но его перебивает другое прерывание в котором идет запись в тот же буфер, то такое уже, естественно, не работает. Обычно если нет RTOS, то вполне можно обойтись такой легковесной реализацией без мютексов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 18:33 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
в микроконтроллерах на прерываниях - иммитация многопоточности.

да, классический сценарий:
отправка и приём - как правило, это прерывания более высокого уровня, чем у того, в котором курутится main, и в котором обычно происходит обработка пакетов... всё так.

однако.
никто не запрещает нечто очень важное выполнить в прерывании ещё более высокого уровня чем у прерывания отправка и приём... и вот тут может случиться страшное ;)

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 18:52 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1024
cheblin писал(а):
однако.
никто не запрещает нечто очень важное выполнить в прерывании ещё более высокого уровня чем у прерывания отправка и приём... и вот тут может случиться страшное ;)

Буфер лишь посредник, одна сторона передает, другая принимает, непонятно зачем еще более высокоуровневому прерыванию вклиниваться посреди приема и начинать принимать данные самому... Никто не запрещает, просто не так легко придумать зачем это делать :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 13 сен 2019, 19:14 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
о-о-о погромисты - они очень изобретательны...
особенно забавляет, когда позабыв всю хрупкость обсуждаемой механики, эту фигню сделает всё тот же погромист, некоторое время спустя...и даже будет гордица как он систему хакнул.

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 14 сен 2019, 01:24 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 543
Когда один читатель - один писатель, то очередь можно сделать используя лишь барьеры. Если несколько читателей или несколько писателей, то да, сложно. Решение сводится к нескольким индивидуальным для каждой пары 1-1 очередям. Либо все же делать лок.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 14 сен 2019, 01:33 
Старожил
Аватара пользователя

Зарегистрирован: 28 янв 2010, 20:18
Сообщения: 543
cheblin писал(а):
Цитата:
всегда можно найти решение проблемы и без динамического выделения памяти

верно, можно.
и это будет называться переизобретением динамического выделения, памяти уже встроенной в С, только на статическую область.... Но зачем?


Часто делают пул из объектов одинакового размера, операции выделения и освобождения простейшие и выполняются за детерминированное время, проблемы фрагментации нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 14 сен 2019, 05:14 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
делают пул из объектов одинакового

наконец то найдено решение у которогл нет недостатков...!!!1111
или они есть.

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

я выбрал кучу, посколько:

99% сетевый приложений получают пакет, выполняют действия с данными и уничтожают полученное.
основное время работы таких приложений - это ожидание новых данных и в это время - около нулевые затраты памяти

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 14:25 
Старожил
Аватара пользователя

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 465
Я хоть и не фанат C++, попытаюсь перечислить + и - из личного опыта:

Итак, положительные моменты:

Очень гибкое управление динамической памятью (не путать с SDRAM, речь идёт о выделении-освобождении памяти). Мы небольшим коллективом пишем игры на микроконтрорллеры. C++ очень сильно выручает, когда нужны вектора, списки, объекты. Ну представьте себе......... в игре появляются противники, у них свой сценарий поведения (стейт-машина), они могут стрелять - а это рождение новых объектов - патроны, у них есть тоже свои атрибуты: координаты, тип траектории, убойная сила итд итп.... Патроны когда попадают - исчезают, но рождают взрыв - а это уже третий новый объект, у него есть фазы взрыва, разлёт на частицы - это уже 4-й обект.... И постоянно идёт генерация новых объектов, удаление старых объектов..... Постоянно активно дёргаются листы, их Push, Pop,.... Классы - тоже очень помогают - наследование признаков со старых противников для новых, модификация.... На голом Си это будет весьма кривовато! С++ - идеальный инструмент для написания игр, там где нужно обеспечить портируемость!

Отрицательные моменты:

С++ рантайм и стартап могут завешать контрорллер. Если не будут прописана обработка эксепшенов или не будут отключены потоки. Большой начальный код.

Резюмируя: следует строго разграничивать код на Asm, C, C++ :

приложения пишем на C, C++
API пишем на C
Драйверы для управления периферией МК - на Asm/C

Тоесть проект пишется на трёх языках одновременно.

как-то так...

Наши программисты, пишущие игры, говорят что C++ очень удобен!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 14:35 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 2417
Откуда: Китай, Пекин
Цитата:
говорят что C++ очень удобен!

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

_________________
unirail.org


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 15:02 
Старожил

Зарегистрирован: 08 июн 2015, 16:26
Сообщения: 370
RepStosw писал(а):
Очень гибкое управление динамической памятью


Да, все верно, в геймдеве это безусловный плюс, конечно...
Только все-таки память нерезиновая у МК. Как вообще с контролем динамической памяти дела обстоят у этих программистов игр на МК? Может, все-таки имеет смысл самописную выделялку делать для таких маленьких платформ? Вон, самый известный пример - первые думы и кваки, в которых было три сорта выделялок под разные нужды: zone, hunk и block memory, написанных на сях.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 15:31 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1024
sdv_cyborg писал(а):
Да, все верно, в геймдеве это безусловный плюс, конечно...
Только все-таки память нерезиновая у МК. Как вообще с контролем динамической памяти дела обстоят у этих программистов игр на МК? Может, все-таки имеет смысл самописную выделялку делать для таких маленьких платформ?

Смысл может и есть, только все равно на плюсах проще написать даже такую выделялку. Пользоваться будет удобнее, эффективность такая-же.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 15:33 
Старожил
Аватара пользователя

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 465
cheblin писал(а):
Цитата:
говорят что C++ очень удобен!

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


С99 поддерживается AVR, ARM и TI DSP.

А Rust генерирует для TI DSP ? :) то-то же... Нету вашего Rust'a на DSP. Посему непортируемо.

тоже самое и Unity и прочие говно-движки для говно-игр... дальше ПеКа и Ведроида эти игры не скакнут. А вот Open Tyrian - шедевр... написан на Си и портируем хоть куда... В отличие от Раста и прочих.

Правильно Oxford сказал в начале темы - держим курс на C (в идеале ANSI).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 15:38 
Старожил
Аватара пользователя

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 465
sdv_cyborg писал(а):
RepStosw писал(а):
Очень гибкое управление динамической памятью


Да, все верно, в геймдеве это безусловный плюс, конечно...
Только все-таки память нерезиновая у МК. Как вообще с контролем динамической памяти дела обстоят у этих программистов игр на МК? Может, все-таки имеет смысл самописную выделялку делать для таких маленьких платформ? Вон, самый известный пример - первые думы и кваки, в которых было три сорта выделялок под разные нужды: zone, hunk и block memory, написанных на сях.


Ну игру Gradius III Total Terror нам удалось запихать в 2 МБ флеша (реально занято 1,8 МБ) и 1 МБ оперативы (реально чуть-меньше). Игра написана на C++. API игры на С.

На счёт памяти, стоит SDRAM 32 - 64 МБ - она RW, хранится как код и данные. Написать свой аллокатор памяти можно, только пока мы довольны штатным. Утечек памяти не наблюдали. Но это всё FOR HOME OR OFFICE USE !!!

Кроме аллокаторов ещё нужно кучу вещей о которых писал выше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 16:06 
Старожил

Зарегистрирован: 10 июн 2011, 23:01
Сообщения: 3300
RepStosw писал(а):
С99 поддерживается AVR, ARM и TI DSP.
А Rust генерирует для TI DSP ? :) то-то же... Нету вашего Rust'a на DSP. Посему непортируемо.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Си++: быть или не быть
СообщениеДобавлено: 04 окт 2019, 16:19 
Старожил
Аватара пользователя

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 465
_pv писал(а):
то что там генерируют компиляторы для DSP, обычно выглядит так, что лучше бы оно не поддерживалось вообще.
а звать интринсики (портируемость, ага) как-то без разницы из какого языка.


Не, ну полифазный фильтр или ещё какая-нибудь DSP-свёртка конечно на ассемблере. Я говорил об обычном "управляющем" коде. TI CC 8.3.3 справляется с этим неплохо. В большинстве случаев, выдаиваются впараллель 2-3 инструкции, что приятно. По этой причине STM32 проигрывают C6745-му на одинаковых частотах.

Интринсики можно самому накидать, главное чтобы вначале компилировалось и собиралось. Оптимизация - это уже второй шаг


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 318 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB