Pull to refresh
0
0
Send message

Действительно прирост будет, если вместо PyTorch использовать TensorRT.

С помощью этой библиотеки (не внешней утилиты) можно выкачивать свои обновления и заменять свой бинарник.

Ещё один момент - приложение монтируется в read only файловую систему.
Это значит, что приложение не может обновлять само себя, нужны внешние утилиты.

Не совсем так. Для AppImage есть https://github.com/AppImage/AppImageUpdate, который можно использовать как библиотеку для self-update.

Возможно, вместо FNDELAY корректнее использовать O_NONBLOCK.

Он решает проблему простой системы сборки с удобным синтаксисом. Имхо, это дело вкуса.

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

На большинство ваших вопросов есть ответы на сайте meson, можете там почитать про их философию и почему они делают так, а не иначе.

Смотрели ли в сторону Meson? Если да, чем он не понравился?

А что насчет антибиотиков внутрь?
По-моему, самым популярным подходом для трекинга на данный момент являются корреляционные трекеры: KCF, DSST и их вариации. Имеют хорошую производительность, трекать могут все, что угодно и с неплохой точностью.
Интересно, а есть какие-нибудь перспективы у Ethercat в автомобилестроении?
Я согласен, что TK1 — это ужас. И в плане софта в том числе.
Но для TX1/TX2, по-моему, все не так сложно. Вся документация есть, достаточно зарегистрироваться у Nvidia на сайте в качестве разработчика.
А ещё вам нужно будет его развести (материнок для него пока нет)

Их мало, но они есть. Например, от Auvidea. Неприятная особенность заключается в том, что хоть сам Jetson Nano и меньше по размеру, чем Jetson TX2, но вместе с материнкой Nano проигрывает по размерам.

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

У нас почти все вопросы решалась либо через devtalks, либо напрямую с ConnectTech (мы используем их материнки). Да, у Nvidia есть штуки, которые доступны только их партнерам. Например, калибровочные данные для MIPI камер/сенсоров. Но их можно запросить, написав напрямую таким партнерам.

Наверное, еще стоит добавить, что у AGX Xavier есть специальные ускорители для нейронок.
А также, что Jetson'ы в целом умеют еще во много что другое. Например, аппаратный энкодинг/декодинг видео и кучу различных интерфейсов. А для кровавого энтерпрайза есть модули TX2i, с расширенным температурным диапазоном и устойчивостью к ударам.
Самый большой минус, конечно — это цена.
Позже реакторы были модернизированы, добавили защитный контейнмент. Изначально его не было. Как и пишет Легасов, колпаки стали ставить только после того, как построили АЭС для Финляндии. Вот цитата из википедии:

«Первое применение такой гермооболочки в советском реакторостроении — АЭС Ловииса c реакторами ВВЭР-440 в Финляндии (первый блок пущен в 1977 году)»

В то время как, например, Кольскую АЭС начали строить в 1969 году и ввели в эксплуатацию в 1973.

Про Ловииса Легасов и писал, что эта была самая надежная и замечательная АЭС.
«Нет, у нас 14 аппаратов ВВЭР без колпаков.»

Цитата Легасова, взято отсюда
Я не специалист в области реакторов, но если судить по количеству пострадавших, то да — помогло.
Я покопался в фактах, почитал те самые записи Легасова. И знаете, что он писал?
Например, что советские реакторы (и РБМК, и ВВЭР) не обладали защитным контейнментом, который мог предотвратить чернобыльские последствия. Потому что СССР нуждалась в большом количестве энергии «здесь и сейчас». А строить защиту долго и дорого. А вот на Три-Майл-Айлэнд потому и не было таких последствий, что контейнмент там был. Отсутствие такой защиты просто нарушение международных правил, на которые СССР наплевал.
Академики тогда еще до аварии на ЧАЭС много раз поднимали вопрос о защите и безопасности, о культуре производства. Чего только стоит чудом не случившаяся авария на Кольской АЭС.
Спасибо за релиз!
Расскажите, почему перестали развивать cuda модули? Ведь сейчас обработка изображений все больше переезжает на gpu.
Ошибка №18: Создавать намного больше «выполняющихся» потоков, чем доступно ядер

Поясните, пожалуйста, «намного больше» — это насколько?
На компьютере запущено множество процессов (около сотни, допустим) и все они выполняются разными ядрами CPU (в зависимости от планировщика). Получается, что они работают неэффективно? Или я где-то не прав?

Information

Rating
Does not participate
Registered
Activity