Да же не знаю как и про комментировать.
С одной стороны Вы говорите про то что пишете под raw железо (что само по себе весьма не тривиально без глубоко знания периферии)..
Отвечу коротко: Нет. USB вариант это медленней, чем интегрированная камера + GPU
В принципе, я же написал… python host (библиотека picamera).
А практически все скриншоты с параметрами по умолчанию: bitrate 500000. разрешение /2 экрана телефона, fps=15.
bitrate 100% определяет трафик, а разрешение + fps — определяет сколько будет артефактов при быстром движении в кадре. Это же h.264… а не mjpeg
А то, о чем Вы говорите — это github.com/Motion-Project/motion
Я его и упоминал. Сравнение кадров там вполне оптимально на "C".
но максимальный fpv = 4 при практически 100% загрузке проца. И… потребление на 40mA больше чем через анализ векторов.
Вектора считает не CPU… поэтому и энергопотребление и нагрузка небольшие в этом режиме.
количество векторов это: width*height кадра/ 4 /4
Каждый вектор: 1 байт X + 1 байт Y + 2 байта (short int) на SAD.
А сравнение кадров это программа motion на fps=4 максимум и чип на raspberry pi горячий.
Объем вычислений не сопоставим.
После того, как мне пришлось влазить в исходники swagger и править там кусочек, что бы получить сгенеренный корректный код клиента, я решил, что не поленюсь руками код писать. По крайней мере это более предсказуемо по срокам.
Авторы интерфейса сказали "а мы swagger используем только для документирования и у нас проблем нет".
Уже не помню в чем там была проблема… года 2 назад было. Но осадочек остался.
Результаты исследования показывают, что приложение, основанное на микросервисах, и использующее gRPC, оказывается примерно на 30% производительнее аналогичного приложения, в котором для обмена данными между микросервисами используется HTTP/1.1.
Когда вижу всякие сравнения по производительности микросервисов сразу этот личный опыт вспоминается… Результаты производительности железки (HSM через TCP/IP):
Обращение по локальному соединению — 10ms на операцию.
По внутренней сетке днем — 50..60ms
По внутренней сетке в обед — 250..550ms на операцию (обед… в Интернете все лазят)
По внутренней сетке вечером (рабочий день закончен) — 30-40ms
Могу предложить идею гаджета для параноиков.
Браслет (перстень) с мощными инфракрасными светодиодами на руке, которая PIN код вводит.
Ослепит практически любую микро камеру, направленную на PIN клавиатуру.
Вот же блин…
Теперь придется закрывать счета в Сбере.
У меня было подозрение, что корреляция между спамом "купи!" и пополнением счета в Сбере есть.
А теперь это подозрение превращается в уверенность об утечках их Сбера..
Это потенциальная (и наступал на это) "слабое место" для ошибок.
В простых программках, когда нужно быстро быстро решить какую то задачу (на те же 500 строк кода) — это может оказаться преимуществом. А в программах которые потом сопровождать и где исходного кода на пару сотен кбайт, лично я предпочитаю C++ или Java. (Java лучше, поскольку проблемы с версиями Unix/Oracle client задрали..)
При прочих равных, производительность — это то же важно..
В повседневной работе сейчас:
в основном, новые проекты на Java.
Сопровождаю старый код на C++ (которой частично и сам писал).
питон — для анализа логов (нестандартные задачи), не стандартные разовые отчеты, вместо sh/bash (когда его возможностей мало), и т.п.
js — web морды для пользователей. Регулярно..
PL-SQL + SQL — когда долго ждать когда у разработчика Oracle время появится и нужно срочно..
Для хобби: C++, java и питон.
Все сказанное — мое личное мнение, на моем личном опыте. А не на теоретических рассуждениях.
Все эти споры "какой язык лучше"…
Да пофиг, по большому счету, на чем кодить… У всего есть недостатки и достоинства.
"Есть лож, а есть статистика.."
Я то же питон активно пользую. Очень удобно простой скрипт скидать для анализа лога, генерации отчетов (выборок из БД… срочно срочно..) и тому подобных задач.
Но основное языки для разработки все равно остаются Java и С++.
Поскольку "дружелюбность для разработчика" заканчивается на уровне программ в 500..1000 строк кода.
Что то более объемное — лучше Java.
А почему все решили что этот стиль правильный?
Вот лично мне удобнее когда называние слева.
Я не китаец, который привык сканировать сверху вниз взглядом…
Мне лично как то удобнее, слева направо.
Но почему то "все" решили, что "пользователям так удобнее..." Проводился опрос?
И для этого нужна статья?
Жду на хабре статей "как завязать шнурок, что бы не споткнуться".
По крайней мере это будет оригинальней (меньше встречается в поиске) чем для банальность про многопоточность и сервлеты.
Жду возмущенных криков "для для нас это полезно… мы первый раз об этом слышим.."
Да же не знаю как и про комментировать.
С одной стороны Вы говорите про то что пишете под raw железо (что само по себе весьма не тривиально без глубоко знания периферии)..
Отвечу коротко: Нет. USB вариант это медленней, чем интегрированная камера + GPU
В принципе, я же написал… python host (библиотека picamera).
А практически все скриншоты с параметрами по умолчанию: bitrate 500000. разрешение /2 экрана телефона, fps=15.
bitrate 100% определяет трафик, а разрешение + fps — определяет сколько будет артефактов при быстром движении в кадре. Это же h.264… а не mjpeg
Это не та задача, которую я решал для себя.
А то, о чем Вы говорите — это github.com/Motion-Project/motion
Я его и упоминал. Сравнение кадров там вполне оптимально на "C".
но максимальный fpv = 4 при практически 100% загрузке проца. И… потребление на 40mA больше чем через анализ векторов.
Вектора считает не CPU… поэтому и энергопотребление и нагрузка небольшие в этом режиме.
количество векторов это: width*height кадра/ 4 /4
Каждый вектор: 1 байт X + 1 байт Y + 2 байта (short int) на SAD.
А сравнение кадров это программа motion на fps=4 максимум и чип на raspberry pi горячий.
Объем вычислений не сопоставим.
Странно, почему "дети" во множественном числе.
После того, как мне пришлось влазить в исходники swagger и править там кусочек, что бы получить сгенеренный корректный код клиента, я решил, что не поленюсь руками код писать. По крайней мере это более предсказуемо по срокам.
Авторы интерфейса сказали "а мы swagger используем только для документирования и у нас проблем нет".
Уже не помню в чем там была проблема… года 2 назад было. Но осадочек остался.
А что взять более другой в линейки и писать через FSMC — это экономия на центах?
Когда вижу всякие сравнения по производительности микросервисов сразу этот личный опыт вспоминается… Результаты производительности железки (HSM через TCP/IP):
Могу предложить идею гаджета для параноиков.
Браслет (перстень) с мощными инфракрасными светодиодами на руке, которая PIN код вводит.
Ослепит практически любую микро камеру, направленную на PIN клавиатуру.
Вот же блин…
Теперь придется закрывать счета в Сбере.
У меня было подозрение, что корреляция между спамом "купи!" и пополнением счета в Сбере есть.
А теперь это подозрение превращается в уверенность об утечках их Сбера..
В python (и JS) мне не нравится:
Это потенциальная (и наступал на это) "слабое место" для ошибок.
В простых программках, когда нужно быстро быстро решить какую то задачу (на те же 500 строк кода) — это может оказаться преимуществом. А в программах которые потом сопровождать и где исходного кода на пару сотен кбайт, лично я предпочитаю C++ или Java. (Java лучше, поскольку проблемы с версиями Unix/Oracle client задрали..)
При прочих равных, производительность — это то же важно..
В повседневной работе сейчас:
Для хобби: C++, java и питон.
Все сказанное — мое личное мнение, на моем личном опыте. А не на теоретических рассуждениях.
Все эти споры "какой язык лучше"…
Да пофиг, по большому счету, на чем кодить… У всего есть недостатки и достоинства.
"Есть лож, а есть статистика.."
Я то же питон активно пользую. Очень удобно простой скрипт скидать для анализа лога, генерации отчетов (выборок из БД… срочно срочно..) и тому подобных задач.
Но основное языки для разработки все равно остаются Java и С++.
Поскольку "дружелюбность для разработчика" заканчивается на уровне программ в 500..1000 строк кода.
Что то более объемное — лучше Java.
Забавно… народ таким развлекался когда то еще на PDP-11
Не… читать переводные статьи…
Насколько понятна формулировка в оригинале, настолько коряво и непонятно выглядят оба варианта перевода.
А почему все решили что этот стиль правильный?
Вот лично мне удобнее когда называние слева.
Я не китаец, который привык сканировать сверху вниз взглядом…
Мне лично как то удобнее, слева направо.
Но почему то "все" решили, что "пользователям так удобнее..." Проводился опрос?
Это вы просто к другому жаргону привыкли…
По жаргону можно даже определить выходца из той или иной "школы" (компании).
А жаргонное название "ISO-образ" не только к CD/DVD относят…
Слияние хабра выбивает..
раньше никогда худ.лит. на хабре не видел (и не знал/не интересовался что есть) и вдруг…
безумный микс технических статей и пр.
samlib регулярно смотрю… там кажется аудитория то для такого то побольше будет.
Может я и ошибаюсь, но чего бы вам свои тексты на samlib.ru не выкладывать.
Зачем превращать habr в помойку.
А где характеристики?
статья напоминает "научно популярную" из желтой прессы...
Если что, в чипе Java card платежной карты (а размеры практически те же) умещает:
2Кб ram
32..64Кб eeprom
… rom c Java OS и пр.
Статья по большому счету ни о чем.
И для этого нужна статья?
Жду на хабре статей "как завязать шнурок, что бы не споткнуться".
По крайней мере это будет оригинальней (меньше встречается в поиске) чем для банальность про многопоточность и сервлеты.
Жду возмущенных криков "для для нас это полезно… мы первый раз об этом слышим.."