Не так давно в свет вышло устройство Movidius Neural Compute Stick (NCS), представляющее собой аппаратный ускоритель для нейронных сетей с USB интерфейсом. Меня заинтересовала потенциальная возможность применения устройства в области робототехники, поэтому я приобрел его и задумал запустить какую-нибудь нейросеть. Однако большинство существующих примеров для NCS решают задачу классификации изображений, а мне хотелось попробовать кое-что другое, а именно обнаружение лиц. В этой публикации я хотел бы поделиться опытом, полученным в ходе такого эксперимента.

Весь код можно найти на GitHub.

Насколько трудно может быть измерить производительность простой функции, вроде вот этой?

// func.cpp
void benchmark_func(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

Ну, давайте просто завернём её в какой-нибудь микробенчмарк, вызовем её много-много раз (для усреднения результатов) и посмотрим, что получится, да? Ну ладно, мы можем ещё посмотреть на сгенерированные инструкции просто чтобы убедиться, что компилятор чего-то там не «наоптимизировал». Мы можем также провести несколько разных тестов, чтобы убедиться, что именно цикл является узким местом. Ну и всё. Мы понимаем, что мы измеряем, да?

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

// func.cpp
void foo(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

void benchmark_func(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

И вот однажды ваш менеджер приходит к вам и показывает претензию от пользователя вашей библиотеки, которая заключается в том, что она не работает настолько быстро, как вы обещали. Но постойте, мы ведь хорошо измерили производительность и обещали ровно то, что получили по результатам тестов. Что же пошло не так?

За пару последних десятилетий, пока вычислительные системы эволюционировали от одноядерных скалярных до многоядерных векторных архитектур, значительно выросла популярность управляемых языков, а также появились новые языки программирования. Но старый добрый C++, позволяющий писать высокопроизводительный код, остается более чем популярным. Однако, до недавнего времени стандарт языка не предоставлял каких-либо инструментов для выражения параллелизма. Новая версия стандарта (C++17 [1]) предоставляет набор параллельных алгоритмов Parallel STL, дающий возможность преобразовать существующий последовательный C++ код в параллельный, что, в свою очередь, позволяет задействовать такие аппаратные возможности, как многопоточность и векторизация. Эта статья познакомит вас с основами Parallel STL и его реализацией в Intel Parallel Studio XE 2018.

Вам приходилось сталкиваться с необходимостью взаимодействия кода на C# и native-C++ (или скорее С)? Причины могли быть разными: библиотека уже есть, на С/С++ написать проще, разработка частей приложения ведётся разными командами, _______________ (нужное вписать).

Известно, что языки базируются на совершенно разных наборах аксиом.

В С# (CLR, если точнее) вы имеете дело с типами фиксированных размеров (за редкими оговорками), код может быть скомпилирован JIT-компилятором под любую из поддерживаемых целевых платформ (если явно не оговорено иное).

В мире C++ всё совсем иначе: одни и те же типы могут иметь разные размеры при компиляции на разные платформы (привет, size_t), код генерируется по-разному для разных платформ, операционных систем и прочих прелестей.

Под катом будем пробовать их подружить с учётом указанных особенностей.

Всем привет! Я надеюсь, вы успели соскучиться по плюсовым докладам и общению с коллегами, потому что очередная конференция C++ Russia уже не за горами. В этом году конференция снова пройдёт в городе трёх революций.

Конференция состоится 19-21 апреля в Санкт-Петербурге. 19 апреля — день мастер-классов, 20-21 — основная программа. Jon Kalb открывает первый день конференции. Темы докладов конференции: память, краш-репорты, асинхронность, software transactional memory, reflective metaprogramming, ranges, акторы, Herb Sutter.

Подробности под катом.

Вместо вступления

Всем привет! Сегодня хотелось бы поговорить о том, как просто и с удовольствием писать тестируемый код. Дело в том, что в нашей компании мы постоянно контролируем и очень ценим качество наших продуктов. Еще бы – ведь с ними ежедневно работают миллионы человек, и для нас просто недопустимо подвести наших пользователей. Только представьте, наступил срок сдачи отчетности, и вы тщательно и с удовольствием, используя заботливо разработанный нами пользовательский интерфейс СБИС, подготовили документы, еще раз перепроверили каждую циферку и вновь убедились, что встречи с вежливыми людьми из налоговой в ближайшее время не будет. И вот, легким нажатием мыши кликаете на заветную кнопку «Отправить» и тут БАХ! приложение вылетает, документы уничтожаются, жарким пламенем пылает монитор, и кажется, люди в погонах уже настойчиво стучат в двери, требуя сдачи отчетности. Вот как-то так все может и получиться:

Кадровый буфер

На текущий момент мы уже успели воспользоваться несколькими типами экранных буферов: буфером цвета, в котором хранятся значения цвета фрагментов; буфером глубины, хранящим информацию о глубине фрагментов; буфером трафарета, позволяющим отбросить часть фрагментов согласно определенному условию. Комбинация этих трех буферов зовется кадровым буфером (фреймбуфером) и хранится в определенной области памяти. OpenGL достаточно гибка, чтобы позволить нам самим создавать собственные кадровые буферы, посредством задания собственных буферов цвета и, опционально, буферов глубины и трафарета.

Эта статья возникла из-за одной моей ошибки и двух багов — по одному в Chromium Headless и ChromeDriver. В результате пришлось собрать всё это из исходников (в статье есть подробнейшая инструкция), отладить цепочку взаимодействия Selenium<->ChromeDriver<->Chromium в отладчике IntelliJ IDEA и Microsoft Visual Studio, покопаться в Java, C++ и JS.

Статья будет интересна тем, кто хочет понять, чем им грозит переход на Selenium + Headless Chrome и как с этим жить. А также всем, кто просто хочет немного поглумиться над несчастным быдлокодером.

Под катом есть пачка скриншотов (трафик!).

Кстати, всё это можно было бы сделать скринкастом — но нельзя, потому что время компиляции C++ необычайно долгое. Вместо этого тут будут скриншоты для привлечения внимания.

Вначале напомню названия участвующих продуктов. Их три штуки:

• Chromium — это браузер. Небрендированная версия Google Chrome, без автообновлений, анальных следящих зондов, но и без несвободных компонентов типа кодеков.
• Chromium ChromeDriver — это часть Chromium, которая отвечает за управление им с помощью внешних инструментов. Это standalone фронт-сервер (отдельный exe-файл), реализует стандарт W3C WebDriver и использует в качестве бэкенда Chrome DevTools.
• Selenium и его Selenium Chrome Driver — эта штука предоставляет Java API для управления Хромиумом. Джава тут не принципиальна, на JavaScript и jWebDriver было бы то же самое (а на Puppeteer — возможно, нет, ибо он использует DevTools напрямую).

Всё вместе даёт нам в руки браузер, управляемый с помощью API на Java, JavaScript и так далее.

Вспомнили? Поехали дальше.

Отсечение граней

Попробуйте представить куб и подсчитать максимальное число его граней, которое вы можете увидеть с любого направления. Если ваше воображение не излишне живое, то, верней всего, вы придете к выводу, что это число 3. Из какой бы точки или с какого бы направления вы не смотрели на куб, вы никогда не сможете увидеть больше чем три грани. Так к чему же тратить вычислительные мощности на отрисовку оставшихся трех граней, если их не будет видно? Если бы мы могли отбросить их обработку каким-то образом, то сэкономили более чем половину выполнений фрагментного шейдера!

Вступление

Многие языки программирования имеют такой инструмент, как properties: C#, Python, Kotlin, Ruby и т.д. Этот инструмент позволяет вызывать какой-то метод класса при обращении к его "полю". В стандартном C++ их нет если хотите узнать, как можно их реализовать, прошу под кат.

Можно ли использовать продольно расположенный полупроводниковый гироскоп, который измеряет угловую скорость разворота самолета, для удержания крена? Проверим это на авиасимуляторе с внешним автопилотом. А также хотелось бы проверить алгоритмы управления самолетом. Такую возможность предоставляет авиасимулятор XPLANE.

Рис.1

Почему именно XPLANE? Он позволяет выводить данные с датчиков симулируемого самолета

Всем привет.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать сотни тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш.

Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

1. Вступление

Радиоуправляемыми самолетами я увлекся еще в 2002 году, живя в Праге. Первый самолет был с размахом крыла 1.2 м, двигатель 2-х тактный ДВС. Вот фрагмент видеозаписи тех времен. Однажды в 2008 году мне в руки попал акселерометр ADXL202E. Имея опыт разработки устройств на контроллере семейства MCS-51(это был Рубидиевый стандарт частоты и система сбора данных), я решил сделать автопилот для радиоуправляемой модели Mentor. Первым делом я подключил акселерометр к контроллеру. Для простоты я выбрал отладочную плату с контроллером AT91SAM7, за удобство и простоту работы с ней. Надо заметить, что я решил не изучать ничего про автопилоты в интернете, а делать все самостоятельно с "0", чтобы было интересней.

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

Приветствую жителей Хабра!

Итак, новые «криптографические игрища» пришли по мою душу. Поэтому сегодня поговорим о занудном упражнении, ориентированном на полный перебор паролей, реализации тривиального многопоточного брутера силами C++ и OpenMP, а также кратко об использовании криптобиблиотеки CryptoPP и стороннего модуля fastpbkdf2 (для Си и Плюсов) в своих проектах.

Го под кат, печеньки out there!

Никогда не сдавайтесь

Действительно ли Билл Гейтс произнёс фразу «640 КБ должно хватить всем»? Её история довольно туманна, однако чаще всего её приписывают Биллу, так что, возможно, он действительно такое говорил.

Его довольно часто за это высмеивали. Мысль о общем пространстве памяти размером всего 640 КБ по современным стандартам смехотворна. В этот размер не уместится даже исполняемые файлы большинства программ-установщиков.

Для сравнения: калькулятор в Windows 10 занимает в состоянии простоя 16,2 МБ оперативной памяти — почти в 26 раз больше, чем объём доступной DOS-программам памяти в 1980-х.

Странные дела

Поверите ли вы мне, если я скажу, что до сих пор существует активное сообщество, использующее эту устаревшую платформу и разрабатывающее для неё ПО?

Наверно, вашим первым вопросом будет «Но зачем?» И я хорошо вас понимаю. Давайте рассмотрим некоторые группы, которые до сих пор заинтересованы во вложениях усилий в DOS.

Давным-давно случилось мне поработать над проектом с Arduino, где были довольно специфические требования к предсказуемости генерации кода, а работать с чёрным ящиком местами раздражало. Так родилась идея несколько поднастроить процесс сборки и внедрить некоторые дополнительные шаги при сборке.

Сейчас я изучаю отчёт очередной проверки проекта Chromium и используемых в нём библиотек, с помощью анализатора кода PVS-Studio. По итогам проверки у меня намечается цикл статей, посвященный разбору некоторых видов ошибок, и тому, как их можно избежать. Однако, одна ошибка так сильно понравилась, что я решил не откладывать её описание, а сразу написать маленькую заметку в блог.

Представлена семантика разработанной библиотеки pde++ для программирования конечно-разностных методов в операторном стиле. Основными объектами библиотеки являются сеточная функция, сеточная ячейка и сеточные операторы, арифметические соотношения между которыми максимально приближают программный код к его математической нотации. Библиотека pde++ представлена всего несколькими заголовочными файлами, не имеет внешних зависимостей и использует концепцию ленивых вычислений.

В прошлой статье про написание конечных автоматов я обещал упаковать наш гениальный код в виде класса на C++ для повторного удобного использования. Делать буду так же на примере своей старой разработки SmartButton. Итак, влезаем в непонятный мир ардуининых библиотек и ООП.

Зачем всё это нужно?

Когда чайник, уперевшись в необходимость отойти от простой последовательности действий, задаёт на хабре вопрос типа "как сделать вот это?", ему с вероятностью 70% отвечают "погугли конечные автоматы" и 30% "используй finite state machine" в зависимости от страны работодателя профессионала. На следующий вопрос "а как?" отправляют в гугл. Идёт такой чайник, что только закончил мигать светодиодом и вытер пот со лба, что учил в школе немецкий и всю жизнь работал бульдозеристом в этот гугл и видит там статьи типа Википедия про конечные автоматы с формулами и в которых понятны только предлоги.

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