Скорость выделения памяти от сборки мусора не зависит. Использовать несколько пулов для оптимизации скорости выделения памяти можно и без сборщика мусора.
А вот случаи, когда система уходила в задумчивость из-за того, что программист понадеялся на сборщик мусора, а тот просто не успевал освобождать память, я встречал неоднократно. Например, в системе сбора данных при пиковых нагрузках.
Я ни в коем случае не утверждаю, что сборщик мусора есть плохо. Я утверждаю, что есть случаи, когда производительность системы выше без него и эффективней освобождение памяти вручную.
Не надо меня агитировать за VCS. Там где это действительно необходимо, я пользуюсь или SVN, или git. Но если весь проект состоит из нескольких десятков строк для восьмибитного МК в двух файлах (*.c + *.h), которые пишутся за один вечер для души, то никакого смысла в создании репозитория для него я не вижу. В таких проектах, обычно, разводить плату и паять дольше, чем программировать. А сваливать в один репозиторий совершенно разношерстный код - тоже не удобно.
Вот путь разработчик подключает библиотеку статически, а не тянет целиком so/dll в зависимости. И тогда оптимизация во время связывания включит в исполняемый модуль только одну эту функцию, а не всю библиотеку.
А в идеале предлагать оба варианта - со статическим связыванием и с динамическим.
Если быть точнее, то оригинальная версия Elite занимала всего 22КБ. А вот ее версия для ZX Spectrum потолстела почти в два раза - до 40КБ. Но зато было добавлено множество разных звездолётов противников.
Нет, не один. Вышеописанный механизм зависит от языка и накладывает ограничения, если требуется вызывать функции на других языках. Тогда как COW на уровне MMU (через mmap() с MAP_PRIVATE) универсален. Более того, так как он оперирует на уровне страниц виртуальной памяти, для больших объектов, в которых изменяется лишь незначительная часть данных, он существенно эффективней.
Эта проблема элементарно лечится даже незначительным опытом программирования. Например, в школе на уроках информатики. Сразу возникает понимание, что кода без ошибок не бывает. И доверять любой программе следует не более, чем охранной собаке, которая может как поднять лай без толку, так и подружиться со злоумышленником с сосисками.
Личный опыт. Как только началась удалёнка я переехал в деревню. Домик с печным отоплением. Все проблемы со спиной исчезли, как только стал в перерывах выходить на свежий воздух и колоть дрова. Стресс этот процесс тоже очень хорошо снимает. Проверено Челентано )))
В качестве замены Jira я бы предложил рассматривать еще и Redmine. Но поддерживать его более трудоемко, чем Jira, так как плагины, замечательно работавшие с предыдущей версией, вполне могут отвалиться в следующей. Из-за этого переход на новую версию может потребовать самостоятельного кодинга на Ruby-on-Rails или терпеливого ожидания, когда автор плагина его сам обновит. Если такое вообще произойдет.
А что касается облачных хранилищ, то я в GoogleDoc могу разместить только то, чего утечка точно никому не повредит. Все более ценное храню в облаке исключительно в зашифрованном виде. Лично для меня монопенисуально, доверять дяде Сэму или товарищу майору.
Занимаюсь сейчас подобной задачей, но не для автомобилей, а для полувагонов и не на CPLEX, а на River Logic + Gurobi. Наибольшую сложность представляет собой не столько оптимизация, сколько прогнозирование времен перевозки, погрузки, разгрузки, сортировки, планирование ремонтов и т.п. Так же приходится учитывать как административные, так и технические ограничения (и постоянные, и временные).
Ну и в оптимизации ограничений и штрафов много. Даже перевозки для исполнение своих контрактов имеют разные приоритеты, не считая перевозки сторонних грузов.
Ну и объемы, наверно, побольше. Свыше 100 млн. тонн за год.
Почему автор, если для него важна точность хранимых значений, использует представление с плавающей точкой, которое по определению не может быть точным (0.1 - бесконечная периодическая двоичная дробь), а не представление с фиксированной точкой?
Если вы хотите, чтобы ваш умный дом был доступен на смартфоне, то тут ничего не поделаешь. Всё надо будет либо подключать через интернет, либо оснащать сервер двумя сетевыми картами и выводить админку во внешний мир. Более того, вам потребуется либо выделенный адрес, либо какой-нибудь сервис для выведения этого адреса вовне.
Если роутер достаточно надежен, то вполне можно обойтись и одной сетевой картой. Выделенный IP адрес тоже не обязателен. Достаточно, чтобы он был внешним, пусть даже IPv6.
А вот безопасность передачи данных шифрованием в любом случае необходимо обеспечить даже внутри сети. Особенно при использовании радиоканалов. Полагаться на встроенную безопасность того же WiFi я бы не рекомендовал.
Что же касается "админка во внешний мир" - то только с pre-shared ключами. Например, SSH туннель на внутренний proxy, не отказываясь при этом от HTTPS.
Стабильный сервер с хорошим соединением позволит вашим чадам избежать стояния в холодном подъезде по 3 часа, потому что единственный физический ключ есть только у папы, а сервер решил кордампнуть по причине падения IDE жёсткого диска-пенсионера.
Я бы расшифровал это так:
Соединение с интернет должно быть резервировано, например через LTE (или LTE с симкой другого оператора, если основной канал и так LTE). Причем, желательно, не на том же самом роутере, который обеспечивает основной канал, так как роутер тоже может зависнуть.
В идеале, должен быть резервирован и сервер IoT, пусть даже в режиме ограниченной функциональности.
И не забываем о резервном питании. Причем не только роутеров и серверов IoT, но и датчиков охранной сигнализации.
Иметь поддержку TCP/IP + MQTT на выключателе или простейшем датчике, на мой взгляд, и избыточно и дорого. Причем "дорого" не столько поддержка TCP (ESP-01 стоит не дорого), сколько его питание. Поэтому простейшие устройства выгодней делать на mesh сети из nRF24L01+ в паре с ultra-low-power МК. Если это только датчик на двери или окне, то от литиевой CR2032 он способен проработь год или даже более. Или несколько месяцев от LIR2032. Причем напрямую, без DC-DC преобразователя или, тем более AC-DC блока питания!
А уже гейтом MQTT - nRF24L01+ на той же малинке можно получать к этой сети доступ.
Текущий вариант идет похоже тупо по пути повторения советских «Топазов» в большем размере
Топазы использовали термоэлектрические преобразователи, что подразмевало соотношение электрической мощности к тепловой порядка 1:20, тогда как для для Зевса в техническом задании явно указано турбомашинное преобразование тепловой энергии в электрическую, чего в космосе еще ни разу не делали и что подразумевает соотношение электрической мощности к тепловой порядка 1:4.
От капельного холодильника вроде бы тоже никто не отказывался, так как еще в августе этого года было запланировано повторное его испытание на МКС в 2024-2025 годах. Проблему отражения капель от сборника капель, возникшую на предыдущих испытаниях в 2014 году, по видимому, удалось решить.
Что касается двигателя стирлинга - вообще ничего не слышал. Как я писал выше, речь шла только о турбомашинном преобразовании. Поделитесь ссылкой, пожалуйста.
Понятно, что мегаватт это катастрофически мало. Что-то вроде мощности среднего грузового паровоза и 1/10 мощости современного грузового электровоза. Но так как мощность предыдущих реакторов в космосе не превышала и 10 КВт, то это все же существенный рывок. В 100 раз. Не думаю, что оправдано было рисковать и делать рывок сразу в 1000 раз или более, который действительно дал бы экономический эффект даже для Луны, но нес бы в себе намного больше рисков. Если я правильно помню, то в конце прошлого века для полетов на Марс целевым считался реактор мощностью 24 МВт.
Поясните Вашу мысль про проваленные инновации, пожалуйста, более расширенно. Я искренне всегда считал, что запустить в космос, используя текущие технологии, можно даже 100 МВт реактор (без радиационной защиты). Проблема рассеять в космосе 200-300 МВт тепла с этого реактора.
Вот с недостаточным финансированием проекта и последствиями этого - полностью согласен.
Скорость выделения памяти от сборки мусора не зависит. Использовать несколько пулов для оптимизации скорости выделения памяти можно и без сборщика мусора.
А вот случаи, когда система уходила в задумчивость из-за того, что программист понадеялся на сборщик мусора, а тот просто не успевал освобождать память, я встречал неоднократно. Например, в системе сбора данных при пиковых нагрузках.
Я ни в коем случае не утверждаю, что сборщик мусора есть плохо. Я утверждаю, что есть случаи, когда производительность системы выше без него и эффективней освобождение памяти вручную.
Не надо меня агитировать за VCS. Там где это действительно необходимо, я пользуюсь или SVN, или git. Но если весь проект состоит из нескольких десятков строк для восьмибитного МК в двух файлах (*.c + *.h), которые пишутся за один вечер для души, то никакого смысла в создании репозитория для него я не вижу. В таких проектах, обычно, разводить плату и паять дольше, чем программировать. А сваливать в один репозиторий совершенно разношерстный код - тоже не удобно.
Dar в дифференциальном режиме )
Да ладно, многие pet-проекты у меня в систему контроля не включались, так как ежедневного дифференциального бекапа dar-ом для них достаточно.
А если у меня в открытом доступе только C/C++/Assembler для МК (хобби), а в закрытом - T-SQL/PgSQL/PgPerl/MDX/DAX/ClickHouse/C#/R/Python ?
Разговаривать надо с соискателем, а код в открытом доступе - опция
Вот путь разработчик подключает библиотеку статически, а не тянет целиком so/dll в зависимости. И тогда оптимизация во время связывания включит в исполняемый модуль только одну эту функцию, а не всю библиотеку.
А в идеале предлагать оба варианта - со статическим связыванием и с динамическим.
Если быть точнее, то оригинальная версия Elite занимала всего 22КБ. А вот ее версия для ZX Spectrum потолстела почти в два раза - до 40КБ. Но зато было добавлено множество разных звездолётов противников.
Нет, не один. Вышеописанный механизм зависит от языка и накладывает ограничения, если требуется вызывать функции на других языках. Тогда как COW на уровне MMU (через mmap() с MAP_PRIVATE) универсален. Более того, так как он оперирует на уровне страниц виртуальной памяти, для больших объектов, в которых изменяется лишь незначительная часть данных, он существенно эффективней.
Эта проблема элементарно лечится даже незначительным опытом программирования. Например, в школе на уроках информатики. Сразу возникает понимание, что кода без ошибок не бывает. И доверять любой программе следует не более, чем охранной собаке, которая может как поднять лай без толку, так и подружиться со злоумышленником с сосисками.
А что мешало просто перейти на ClickHouse?
Личный опыт. Как только началась удалёнка я переехал в деревню. Домик с печным отоплением. Все проблемы со спиной исчезли, как только стал в перерывах выходить на свежий воздух и колоть дрова. Стресс этот процесс тоже очень хорошо снимает. Проверено Челентано )))
В качестве замены Jira я бы предложил рассматривать еще и Redmine. Но поддерживать его более трудоемко, чем Jira, так как плагины, замечательно работавшие с предыдущей версией, вполне могут отвалиться в следующей. Из-за этого переход на новую версию может потребовать самостоятельного кодинга на Ruby-on-Rails или терпеливого ожидания, когда автор плагина его сам обновит. Если такое вообще произойдет.
А что касается облачных хранилищ, то я в GoogleDoc могу разместить только то, чего утечка точно никому не повредит. Все более ценное храню в облаке исключительно в зашифрованном виде. Лично для меня монопенисуально, доверять дяде Сэму или товарищу майору.
Занимаюсь сейчас подобной задачей, но не для автомобилей, а для полувагонов и не на CPLEX, а на River Logic + Gurobi. Наибольшую сложность представляет собой не столько оптимизация, сколько прогнозирование времен перевозки, погрузки, разгрузки, сортировки, планирование ремонтов и т.п. Так же приходится учитывать как административные, так и технические ограничения (и постоянные, и временные).
Ну и в оптимизации ограничений и штрафов много. Даже перевозки для исполнение своих контрактов имеют разные приоритеты, не считая перевозки сторонних грузов.
Ну и объемы, наверно, побольше. Свыше 100 млн. тонн за год.
Почему автор, если для него важна точность хранимых значений, использует представление с плавающей точкой, которое по определению не может быть точным (0.1 - бесконечная периодическая двоичная дробь), а не представление с фиксированной точкой?
Смотри правило №6 https://2k.livejournal.com/520078.html
А как же PIC32MZ? https://www.microchip.com/en-us/product/PIC32MZ0512EFF064
К тому же MPU может содержать MCU. Пример - STM32MP1
Если роутер достаточно надежен, то вполне можно обойтись и одной сетевой картой. Выделенный IP адрес тоже не обязателен. Достаточно, чтобы он был внешним, пусть даже IPv6.
А вот безопасность передачи данных шифрованием в любом случае необходимо обеспечить даже внутри сети. Особенно при использовании радиоканалов. Полагаться на встроенную безопасность того же WiFi я бы не рекомендовал.
Что же касается "админка во внешний мир" - то только с pre-shared ключами. Например, SSH туннель на внутренний proxy, не отказываясь при этом от HTTPS.
Я бы расшифровал это так:
Соединение с интернет должно быть резервировано, например через LTE (или LTE с симкой другого оператора, если основной канал и так LTE). Причем, желательно, не на том же самом роутере, который обеспечивает основной канал, так как роутер тоже может зависнуть.
В идеале, должен быть резервирован и сервер IoT, пусть даже в режиме ограниченной функциональности.
И не забываем о резервном питании. Причем не только роутеров и серверов IoT, но и датчиков охранной сигнализации.
Иметь поддержку TCP/IP + MQTT на выключателе или простейшем датчике, на мой взгляд, и избыточно и дорого. Причем "дорого" не столько поддержка TCP (ESP-01 стоит не дорого), сколько его питание. Поэтому простейшие устройства выгодней делать на mesh сети из nRF24L01+ в паре с ultra-low-power МК. Если это только датчик на двери или окне, то от литиевой CR2032 он способен проработь год или даже более. Или несколько месяцев от LIR2032. Причем напрямую, без DC-DC преобразователя или, тем более AC-DC блока питания!
А уже гейтом MQTT - nRF24L01+ на той же малинке можно получать к этой сети доступ.
Я Вас не понимаю:
Топазы использовали термоэлектрические преобразователи, что подразмевало соотношение электрической мощности к тепловой порядка 1:20, тогда как для для Зевса в техническом задании явно указано турбомашинное преобразование тепловой энергии в электрическую, чего в космосе еще ни разу не делали и что подразумевает соотношение электрической мощности к тепловой порядка 1:4.
От капельного холодильника вроде бы тоже никто не отказывался, так как еще в августе этого года было запланировано повторное его испытание на МКС в 2024-2025 годах. Проблему отражения капель от сборника капель, возникшую на предыдущих испытаниях в 2014 году, по видимому, удалось решить.
Что касается двигателя стирлинга - вообще ничего не слышал. Как я писал выше, речь шла только о турбомашинном преобразовании. Поделитесь ссылкой, пожалуйста.
Понятно, что мегаватт это катастрофически мало. Что-то вроде мощности среднего грузового паровоза и 1/10 мощости современного грузового электровоза. Но так как мощность предыдущих реакторов в космосе не превышала и 10 КВт, то это все же существенный рывок. В 100 раз. Не думаю, что оправдано было рисковать и делать рывок сразу в 1000 раз или более, который действительно дал бы экономический эффект даже для Луны, но нес бы в себе намного больше рисков. Если я правильно помню, то в конце прошлого века для полетов на Марс целевым считался реактор мощностью 24 МВт.
Поясните Вашу мысль про проваленные инновации, пожалуйста, более расширенно. Я искренне всегда считал, что запустить в космос, используя текущие технологии, можно даже 100 МВт реактор (без радиационной защиты). Проблема рассеять в космосе 200-300 МВт тепла с этого реактора.
Вот с недостаточным финансированием проекта и последствиями этого - полностью согласен.