Easyelectronics.ru

Электроника для всех
Текущее время: 24 сен 2020, 07:22

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



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

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

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

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

_________________
unirail.org


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

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

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


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

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

_________________
unirail.org


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

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

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


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

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

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

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

_________________
unirail.org


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

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

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


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

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

_________________
unirail.org


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

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


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

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

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


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


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

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

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

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

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

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

_________________
unirail.org


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

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 710
Я хоть и не фанат 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
Сообщения: 3558
Откуда: Китай, Пекин
Цитата:
говорят что C++ очень удобен!

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

_________________
unirail.org


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

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


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


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

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

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


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

Зарегистрирован: 12 июн 2018, 15:04
Сообщения: 710
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
Сообщения: 710
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
Сообщения: 3459
RepStosw писал(а):
С99 поддерживается AVR, ARM и TI DSP.
А Rust генерирует для TI DSP ? :) то-то же... Нету вашего Rust'a на DSP. Посему непортируемо.

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


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

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


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

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


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


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


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

Сейчас этот форум просматривают: Google [Bot]


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

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

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