Вы имеете в виду устройства что управляются по радиоканалу? Оно не очень удобно в использовании. Zigbee сеть сейчас удобнее юзать тк те устройства что подключены к постоянному источнику питания могут работать как ретрансляторы. Поэтому некоторые датчики работают годами (например датчик открытия двери на батарейке cr2032 у меня работает уже года 3). Да и покрытие сети получается больше...
Смысла в фильтре особого нет. Новая логика в записывлке все равно проредит старые данные. Тут проблема в том что передача этих данных не имеет смысл и излишне нагружает сеть. для маленьких сетей не очень страшно. а если устройств больше 10 то могут начаться проблемы в виде задержек в отсылке команд. а то и вообще падении zigbee сети на какое-то время.
у меня раз в секунду шлет. причем значения почти не меняются. логичнее слать если сильно поменялось значение. для сети из 10 устройств может и не критично. у меня сейчас около 50 умных устройств. разбил их на 2 категории - те что спамят подключил к sls. он неплохо переваривает такой спам. в z2m сеть с 2-мя спамящими термостатами периодически падала...
ее руками и надо создавать. в том месте где у вас z2m лежит. рядом с его конфигом. по умолчанию оно лежит в папке /homeassistant/zigbee2mqtt. Ставьте аддон File editor. Я таким макаром перешивал термостаты. Стали работать стабильно и не спамят в сеть ...
На youtube есть канал Геоэнергетика. Ведущий — Борис Леонидович Марцинкевич. В одном из роликов, посвященных серии БН, было сказано что на этих АЭС нарабатывается энергетический плутоний а не оружейный. Разница между оружейным и энергетическим — изотопный состав. В энергетическом один из изотопов сильно не стабильный и не годится для вояк…
Поэтому от МАГАТЭ к этим АЭС претензий по поводу плутония нет.
Стандарт явно не описывает размеры float, double, long double. Есть только определение что точность long double выше double и точность double выше float.
И в совсем общем случае каст в int любого размера (как и memcpy) даст неопределенное поведение.
Поэтому «Каст double к int64_t не может вызвать проблем с выравниванием» справедливо только в частном случае когда размер double равен 8 байт.
В какой части кода ошибка: в функции foo(double *bar) или в функции что ее вызывает?
И да в некоторых случаях foo(double *bar) может ожидать что адрес не выравненный.
Пример:
template<class Type, class Ptr>
Type readUnaligned(Ptr *ptr) {
Type rv;
memcpy(&rv, ptr, sizeof(Type));
return run
}
И даже больше скажу я ловил креши из-за этого UB. На старых arm процессорах которые не умеют читать по не выровненному адресу…
Так что да memcpy оно более безопасно. В релизе (-O3) оно все равно упрощается до нескольких инструкций (если это безопасно)
Немного практических примеров когда такое нужно:
1) Объект состоит из геометрии (ее не надо хранить всегда, после объединения в батчи выкидывается) и из атрибутов. Атрибутов может быть много они часто повторяются и некоторые нужны после обработки. Сами атрибуты могут быть не большими (особенно числа) и оверхед от shared_ptr существенно увеличит использование памяти.
2) вычисление стиля прорисовки объекта подразумевает много работы над атрибутами. Причём многие действия не создают новые атрибуты а выбирают из уже существующих (например выбрать из возможных локализаций нужный текст или выбрать из набора цветов один нужный). И тут мои замеры показывали что shared_ptr копирует себя медленнее чем вариант без поддержки слабых ссылок. И причина очевидна — shared_prt для копии надо записать 2 указателя и увеличить счётчик, тогда мое самописанное без поддержки слабых ссылок — 1 указатель и увеличить счётчик…
3) Есть набор пользовательских букмарок. Выбрав из всех букмарок те что видны — сделали кластеризацию. Букмарка по сути представляет из себя 2 координаты, ссылку на стиль прорисовки и ещё пару мелких флагов. Поэтому в памяти занимает не много но если для менеджмента использовать shared_ptr возникает очень большой оверхед. Эту самую кластеризацию нужно держать и на случай если надо проверить нажатие и для подготовки прорисовки и для поиска.
Как видите во всех случаях идёт работа с большим набором простых данных. Причём когда объект станет не нужным неизвестно…
Кастомные аллокаторы мы используем тоже.
Особенно весело получилось в триангуляции (когда надо полигон покрыть треугольниками чтоб можно было рисовать на GPU).
Вообще зная некоторые особенности данных (одинаковый размер, одинаковое время жизни, малое количество результатов на выходе итд) можно придумать решение с менеджментом памяти которе будет работать значительно быстрее стандартного. Этим и крут c++.
И да многие при оценке сложности работы алгоритма не учитывают, что работа с памятью не бесплатная…
Если вам интересно — подобный механизм управления памятью я использую в мобильном приложении Guru Maps. А конкретнее в подготовке векторных тайлов для прорисовки. Исходные данные такие: есть тайлы в которых может быть около 100000 объектов и стиль который определяет как это все рисовать. Если использовать стандартные подходы то на стареньком телефоне прожевать такое будет очень проблематично. В итоге приходится использовать всякие хитрые оптимизации:
— кастомный аллокатор при загрузке объектов. Никаких счетчиков тут не используется ибо даже они приводят к ощутимым педалям. А так как время жизни четко известно то и удалять все можно одной пачкой.
— те данные что должны получится на выходе (геометрия для прорисовки, высчитанные параметры и прочее) используют счетчики. Тут уже критичен оверхед по памяти. Ибо +-мебагайт памяти на тайл это уже не мало.
Да. Требует 2 функции — увеличить счетчик и уменьшить счетчик. Я такой подход применяю только в тех местах где нужна максимальная скорость и/или минимальный объем использованной памяти (а это почти всегда пишется на c++:)
Иными словами зачастую стандартный std::shared_ptr — содержит избыточные функции за которые платим скоростью и памятью…
Каждый объект содержит в себе счетчик. А умный указатель управляет этим счетчиком. В отличии от универсального решения — счетчик можно положить в любое место и уменьшить размер объекта в памяти. Из-за выравнивания часто получаем небольшой оверхед при наследовании или композиции. Этот небольшой оверхед может раздуть объект например с 16 байт до 24 (~30%)…
Именно по этой причине я не использую std::shared_ptr если слабые ссылки не нужны.
Самописанный умный указатель на атомарном счетчике (лежи в объекте) работает гораздо быстрее чем std::make_shared и кушает меньше памяти…
это по сути фильтры. они ничего не смогу сделать с нагрузкой на zigbee сеть.
Вы имеете в виду устройства что управляются по радиоканалу? Оно не очень удобно в использовании. Zigbee сеть сейчас удобнее юзать тк те устройства что подключены к постоянному источнику питания могут работать как ретрансляторы. Поэтому некоторые датчики работают годами (например датчик открытия двери на батарейке cr2032 у меня работает уже года 3). Да и покрытие сети получается больше...
Смысла в фильтре особого нет. Новая логика в записывлке все равно проредит старые данные. Тут проблема в том что передача этих данных не имеет смысл и излишне нагружает сеть. для маленьких сетей не очень страшно. а если устройств больше 10 то могут начаться проблемы в виде задержек в отсылке команд. а то и вообще падении zigbee сети на какое-то время.
у меня раз в секунду шлет. причем значения почти не меняются. логичнее слать если сильно поменялось значение. для сети из 10 устройств может и не критично. у меня сейчас около 50 умных устройств. разбил их на 2 категории - те что спамят подключил к sls. он неплохо переваривает такой спам. в z2m сеть с 2-мя спамящими термостатами периодически падала...
ее руками и надо создавать. в том месте где у вас z2m лежит. рядом с его конфигом. по умолчанию оно лежит в папке
/homeassistant/zigbee2mqtt. Ставьте аддон File editor. Я таким макаром перешивал термостаты. Стали работать стабильно и не спамят в сеть ...В новой версии z2m (2.0+) их достаточно положить в папку external_converters.
Поэтому от МАГАТЭ к этим АЭС претензий по поводу плутония нет.
И в совсем общем случае каст в int любого размера (как и memcpy) даст неопределенное поведение.
Поэтому «Каст double к int64_t не может вызвать проблем с выравниванием» справедливо только в частном случае когда размер double равен 8 байт.
И да в некоторых случаях foo(double *bar) может ожидать что адрес не выравненный.
Пример:
template<class Type, class Ptr>
Type readUnaligned(Ptr *ptr) {
Type rv;
memcpy(&rv, ptr, sizeof(Type));
return run
}
Так что да memcpy оно более безопасно. В релизе (-O3) оно все равно упрощается до нескольких инструкций (если это безопасно)
1) Объект состоит из геометрии (ее не надо хранить всегда, после объединения в батчи выкидывается) и из атрибутов. Атрибутов может быть много они часто повторяются и некоторые нужны после обработки. Сами атрибуты могут быть не большими (особенно числа) и оверхед от shared_ptr существенно увеличит использование памяти.
2) вычисление стиля прорисовки объекта подразумевает много работы над атрибутами. Причём многие действия не создают новые атрибуты а выбирают из уже существующих (например выбрать из возможных локализаций нужный текст или выбрать из набора цветов один нужный). И тут мои замеры показывали что shared_ptr копирует себя медленнее чем вариант без поддержки слабых ссылок. И причина очевидна — shared_prt для копии надо записать 2 указателя и увеличить счётчик, тогда мое самописанное без поддержки слабых ссылок — 1 указатель и увеличить счётчик…
3) Есть набор пользовательских букмарок. Выбрав из всех букмарок те что видны — сделали кластеризацию. Букмарка по сути представляет из себя 2 координаты, ссылку на стиль прорисовки и ещё пару мелких флагов. Поэтому в памяти занимает не много но если для менеджмента использовать shared_ptr возникает очень большой оверхед. Эту самую кластеризацию нужно держать и на случай если надо проверить нажатие и для подготовки прорисовки и для поиска.
Как видите во всех случаях идёт работа с большим набором простых данных. Причём когда объект станет не нужным неизвестно…
Особенно весело получилось в триангуляции (когда надо полигон покрыть треугольниками чтоб можно было рисовать на GPU).
Вообще зная некоторые особенности данных (одинаковый размер, одинаковое время жизни, малое количество результатов на выходе итд) можно придумать решение с менеджментом памяти которе будет работать значительно быстрее стандартного. Этим и крут c++.
И да многие при оценке сложности работы алгоритма не учитывают, что работа с памятью не бесплатная…
— кастомный аллокатор при загрузке объектов. Никаких счетчиков тут не используется ибо даже они приводят к ощутимым педалям. А так как время жизни четко известно то и удалять все можно одной пачкой.
— те данные что должны получится на выходе (геометрия для прорисовки, высчитанные параметры и прочее) используют счетчики. Тут уже критичен оверхед по памяти. Ибо +-мебагайт памяти на тайл это уже не мало.
Иными словами зачастую стандартный std::shared_ptr — содержит избыточные функции за которые платим скоростью и памятью…
Самописанный умный указатель на атомарном счетчике (лежи в объекте) работает гораздо быстрее чем std::make_shared и кушает меньше памяти…