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


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

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

В действительности система памяти образует иерархию устройств хранения с разными ёмкостями, стоимостью и временем доступа. Регистры процессора хранят наиболее часто используемые данные. Маленькие быстрые кэш-памяти, расположенные близко к процессору, служат буферными зонами, которые хранят маленькую часть данных, расположеных в относительно медленной оперативной памяти. Оперативная память служит буфером для медленных локальных дисков. А локальные диски служат буфером для данных с удалённых машин, связанных сетью.


Иерархия памяти работает, потому что хорошо написанные программы имеют тенденцию обращаться к хранилищу на каком-то конкретном уровне более часто, чем к хранилищу на более низком уровне. Так что хранилище на более низком уровне может быть медленнее, больше и дешевле. В итоге мы получаем большой объём памяти, который имеет стоимость хранилища в самом низу иерархии, но доставляет данные программе со скоростью быстрого хранилища в самом верху иерархии.

Многие читали мой пост "Эмулятор RFID", где я в деталях рассказывал об устройстве EM Marine, о том как намотать антенну, и как сделать RFID-эмулятор из трёх деталей. Но, будем честны, несмотря на гениальную простоту того устройства, оно достаточно сложно для повторения. Не каждый имеет дома осциллограф, для того чтобы поймать резонанс, да и для прошивки ATtiny85 требуется отдельный программатор.

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

_{Habib M’henni / Wikimedia Commons, CC BY-SA}

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

Здравствуйте, друзья, как вы думаете, если мы напишем такой код:

s = a+b;
z = s-a;
t = b-z;

то не кажется ли вам, что в результате его выполнения получится, что t=0? С точки зрения привычной математики действительных чисел это и правда так, а вот с точки зрения двоичной арифметики с плавающей запятой в переменной t будет кое-что другое. Там будет то, что спасает нас от потери точности при сложении чисел $$ и $$. Кого интересует данная тема, прошу под кат.

Начнём конечно с аберрации. Затем рассчитаем и проиллюстрируем графиками, как выглядит звёздное небо в иллюминаторах ракеты в зависимости от её скорости. И, наконец, выясним, как выглядит на фотографии, пролетая мимо Земли, сама эта ракета. Но предупреждаю, картина будет только одна (и то так себе), остальное чертежи, аналитика и графики. Из них, кстати, видно, что несмотря на лоренцево сжатие, только что появившаяся на горизонте приближающаяся ракета возможно даже визуально будет казаться длиннее, и уж точно должна такой оказаться на фотографии, чем если бы она была неподвижна в той же точке траектории. Поскольку все вычисления будем проводить опираясь на физическую суть явлений при субсветовых скоростях, преобразования Лоренца не понадобятся. Автор будет признателен за замечания.

Дорогие друзья. Так получилось, что предыдущую мою публикацию унесло НЛО, сочтя ее чрезмерно политизированной. Это вторая попытка опубликовать этот текст. Мне, увы, так и не удалось выяснить, какие конкретно формулировки являются на Хабре запретными. Поэтому я убрал все названия и все упоминания популярных персон и телевизионных каналов, чтобы лишний раз не вызывать беспокойство в пылких сердцах особо сердобольных читателей и, тем самым, умерить накал страстей в комментариях. Это мое скромное детище было придумано с единственной целью, вынуть моих любимых родителей из телевизионного "информационного пузыря" и предоставить им дополнительную и, вместе с тем, привычную по формату альтернативу из наших семейных роликов, а так же разнообразных видео из сети Интернет, интересных и полезных для расширения кругозора. Надеюсь, что на этот раз НЛО оставит пост в покое, а вы, дорогие коллеги, получите удовольствие от прочтения.

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

Все началось с того, что мы с дочкой в очередной раз приехали к родителям в гости. Родители мои в возрасте. И, как у всех пожилых пенсионеров, радости у них простые: цветочки полить, в парке погулять, пообщаться с детьми и внуками ну и, разумеется, телевизор. Куда же без него.

Родители впервые смотрят нашумевший пару лет назад на Youtube фильм. (На крышке телевизора "голый" RPI первой модели, пруф оф концепт, так сказать)

В 2017 двое ученых, канадец John Aycock и британка Tara Copplestone, опубликовали анализ классической игры Entombed для игровой приставки Atari 2600. Механика этой игры, выпущенной в 1982, крайне проста: археолог, управляемый игроком, должен пробраться по прокручивающимся снизу вверх катакомбам, уворачиваясь от зомби.

У Atari 2600 было всего 128 байт ОЗУ; тем не менее, кажущийся бесконечным лабиринт при каждом запуске был новым, т.е. генерировался в памяти. Как же программистам это удалось? Вот комментарий Стивена Сидли — программиста, 38 лет назад создавшего эту игру:

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

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

Крис Парнин (Chris Parnin) из технологического института Джорджии решил восполнить этот недостаток и опубликовал чрезвычайно насыщенную статью со ссылками на различные исследования по этой теме.

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).

Недавно один мой знакомый, начавший интересоваться электроникой и схемотехникой, обратился ко мне с просьбой дать ему какие-то практические советы по разработке электронных устройств. Поначалу этот вопрос немного озадачил меня: как-то так получилось, что для себя я никогда не выделял какие-то перечни обязательных правил проектирования, всё это было у меня где-то на уровне подсознания. Но этот вопрос послужил хорошим толчком для того, чтобы сесть и сформулировать хотя бы небольшой список таких рекомендаций. Когда все было готово, я подумал, что, возможно, это будет интересно почитать кому-то еще, таким образом и получилась данная статья.

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

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

Сейчас, когда многие из нас находятся на карантине из-за COVID-19, видеозвонки стали куда более частым явлением, чем раньше. В частности, сервис ZOOM неожиданно стал очень популярным. Вероятно, самой интересной возможностью Zoom является поддержка виртуального фона (Virtual Background). Она позволяет пользователям, в интерактивном режиме, заменять фон, находящийся позади них, на любое изображение или видео.

Я уже давно применяю Zoom на работе, на опенсорсных встречах, посвящённых Kubernetes, делая это обычно с корпоративного ноутбука. Теперь я, в режиме работы из дома, склонен к использованию более мощного и удобного персонального настольного компьютера для решения некоторых из моих опенсорсных задач.

К несчастью, Zoom поддерживает лишь способ удаления фона, известный как «хромакей» или «зелёный экран». Для использования этого метода нужно, чтобы фон был бы представлен неким сплошным цветом, в идеале — зелёным, и был бы равномерно освещён.

Так как зелёного экрана у меня нет, я решил просто реализовать собственную систему удаления фона. А это, конечно, куда лучше, чем наведение порядка в квартире, или постоянное использование рабочего ноутбука.

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

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.

К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.

Затем было очень трудно прохождение теста BigCrush.

Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.

Вот и весь комплект, если есть CAN-шина.

Всего пять лет назад не было нормально работающих нейросетей для того же определения препятствий и краёв стеблестоя, поэтому не было и видеоаналитики. Были «слепые» GPS-методы, которые на практике оказались далеко не лучшими и сильно подмочили престиж автоматизации в сельском хозяйстве. Через пять лет, как мы считаем, все комбайны будут автоматизированы именно визуальными автопилотами, чтобы смотреть из кабины и в стороны и контролировать все аспекты уборки урожая.

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

Такой проект мог стартовать у нас, в Бразилии и ещё в паре стран из-за особенностей рынка. Нужна страна с сельским хозяйством, разработчиками внутри, неэффективной уборкой (то есть чёткой болью сэкономить) и новым парком комбайнов. Повезло со всем, включая парк: после СССР всё развалилось, и сейчас мы наблюдаем машины примерно четырёх- пятилетней давности в основных хозяйствах.

В России 350 тысяч комбайнов, и поставляется ещё 35 тысяч в год. Это не рынок автомобилей, конечно, но, сделав правильное решение сейчас, пока туда ещё никто не пришёл, можно получить его весь.

Но давайте расскажу лучше, как именно это работает и как мы модифицируем комбайны в России.

За 10 лет существования ivi мы собрали базу из 90000 видео разной длины, размера и качества. Каждую неделю появляются сотни новых. У нас есть гигабайты метаданных, которые полезны для рекомендаций, упрощают навигацию по сервису и настройку рекламы. Но извлекать информацию непосредственно из видео мы начали только два года назад.

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

Долго искал книгу, в которой было бы разжёвано, как использовать FFmpeg-подобную библиотеку, известную как libav (название расшифровывается как library audio video). Обнаружил учебник «Как написать видеоплеер и уложиться в менее чем тысячу строк». К сожалению, информация там устаревшая, так что пришлось создавать мануал своими силами.

Большая часть кода будет на C, однако не волнуйтесь: Вы легко всё поймёте и сможете применить на любимом языке. У FFmpeg libav уйма привязок ко многим языкам (в том числе и к Python и к Go). Но даже если Ваш язык прямой совместимости не имеет, всё равно можно привязаться через ffi (вот пример с Lua).

Начнём с краткого экскурса о том, что такое видео, аудио, кодеки и контейнеры. Затем перейдем к ускоренному курсу, посвященному использованию командной строки FFmpeg, и, наконец, напишем код. Не стесняйтесь переходить сразу в раздел «Тернистый путь изучения FFmpeg libav».

Есть мнение (и не только моё), что потоковое интернет-видео уже приняло эстафету от традиционного телевидения. Как бы то ни было, FFmpeg libav точно достоин изучения.

Оглавление

• Вступление
  • Видео — это то, что ты видишь!
  • Аудио — это то, что ты слышишь!
  • Кодек — сжатие данных
  • Контейнер — удобный способ хранения аудио/видео
• Командная строка FFmpeg
  • Инструмент в виде командной строки FFmpeg 101
• Основные операции над видео
  • Транскодирование
  • Трансмультиплексирование
  • Трансрейтинг
  • Трансайзинг
  • Бонус: адаптивный стриминг
  • Выходя за рамки
• Тернистый путь изучения FFmpeg libav
  • Глава 0 — простенький «Hello World»
    • FFmpeg libav архитектура
    • Требования
    • Собственно, код
  • Глава 1 — синхронизация аудио и видео
  • Глава 2 — ремультиплексирование
  • Глава 3 — транскодирование
    • Трансмультиплексирование
    • Транскодирование

Не передать, насколько мне приятно это писать. Данная статья полностью профинансирована подписчиками канала LAB66. Ни один производитель описанных в тексте средств -  своего участия не проявил, так что никакой скрытой рекламы, чиcтый альтруизм и потребительский интерес :)

Сегодня читаем о самом простом, самом доступном и самом действенном антисептике — про гипохлорит натрия (он же «Белизна»). Совместимость с различными материалами, техника безопасности, свойства и эффективность не только против коронавируса, но и против страшной плесени и ее микотоксинов. В качестве «вишенки» — контрольная закупка магазинных отбеливателей и оценка их состава. Чтобы узнать как в эпоху пандемии нас дурят производители бытовой химии и прочий «менеджерский брат» — идем под кат. И обязательно закидываем в закладки. Эта информация пригодится еще не раз ;)

В этой статье я подробно расскажу и покажу, как правильно и быстро прикрутить распознавание русской речи на движке Pocketsphinx (для iOS порт OpenEars) на реальном Hello World примере управления домашней техникой.
Почему именно домашней техникой? Да потому что благодаря такому примеру можно оценить ту скорость и точность, которой можно добиться при использовании полностью локального распознавания речи без серверов типа Google ASR или Яндекс SpeechKit.
К статье я также прилагаю все исходники программы и саму сборку под Android.

Введение

Последнее время я занимаюсь разработкой настольного Rest API клиента. Довольно большая часть работы состоит во взаимодействии с сервером. Для оптимизации обработки запросов был написан класс Requester, обладающий следующими особенностями:

• возможность отправлять как https, так и http запросы
• использование одной функции для всех типов запросов
• возможность получить все данные по запросу с сервера, а не одну страницу(n записей)