C++ *

В 2014 году в движке Unity набралось столько критических изменений и новинок, что «пятерка» фактически была другим движком. И хотя многие за одинаковым фасадом не особо этого и заметили, но изменения коснулись всех компонентов движка, начиная от файловой системы и заканчивая рендером. Питерский офис EA имел свою ветку основного репозитария, отставая от мастера максимум на месяц. Я уже писал про различные реализации и типы строк в игровых движках, но в Unity была своя реализация, имевшая как положительные так и отрицательные стороны, которая использовалась практически во всех подсистемах. К ней привыкли, знали слабые стороны и плохие «use cases» и хорошие «best practices». Поэтому когда эту систему стали выпиливать из движка много чего поломалось, и если у обычных пользователей был сразу переход на новую версию и наблюдались только отголоски шторма, то допущенные до «тела» наловили много прикольных багов.

В этой статье мы будем рассматривать решения СЛАУ вида Ax = b, где A - симметричная разреженная матрица. Такие матрицы появляются, например, при решении задач методом наименьших квадратов. Для симметричных СЛАУ разработаны специальные методы, такие, как метод Холецкого и LDL^T разложение. Так как первый из них применим к более узкому классу матриц, чем второй, поэтому далее будем рассматривать только LDL^T разложение, хотя выводы этой статьи применимы к обоим методам.

Сразу предупреждаю, мои вкусы очень специфичны. Красота ошибки в том, что человеку её очень сложно найти. Я не верю, что её можно заметить при обзоре кода. Если только заранее знать, что она есть, и искать её целенаправленно.

Ошибку я нашёл в проекте DPDK. В нём есть и другие ошибки, но про них потом. Они меркнут перед этим алмазом. Только не ждите чего-то эдакого. Ошибка проста до безобразия. Вот только найти её, просматривая код, ой как непросто. Собственно, попробуйте сами.

В данной статье подробно рассмотрим, как собрать ядро, поддерживающее EVL core, и библиотеку, реализующую пользовательский API для этого ядра. А также разберем некоторые аспекты реализации драйвера устройства и приложения под Xenomai 4.

Xenomai — Фреймворк для разработки приложений реального времени на базе ядра Linux. Проект Xenomai был запущен в 2001 году с целью эмуляции традиционной ОСРВ и облегчения ее переноса на GNU/Linux с сохранением гарантий работы в режиме реального времени. Изначально Xenomai был связан с RTAI (интерфейсом приложений реального времени), но на данный момент он независим.

Мы будем работать с Xenomai версии 4. Xenomai 4 имеет архитектуру с двумя ядрами. Первое ядро Linux: для задач, отличных от реального времени, и ядро Xenomai: для задач реального времени. Ядро Linux и ядро реального времени работают практически асинхронно, оба выполняют свой собственный набор задач, всегда отдавая последнему приоритет над первым. Для осуществления доступа к основным сервисам реального времени в проекте Xenomai предусмотрена библиотека С, известная как libevl.

Xenomai поддерживает множество архитектур, таких как PowerPC, Blackfin, ARM, x86, x86_64 др. В данной статье мы используем компьютер c архитектурой x86_64 (Процессор: 12th Gen Intel® Core™ i5-12400 × 12, память: 32,0 ГиБ), операционной системой Debian GNU/Linux 12 (bookworm).

О понятии Sentinel говорят мало, особенно в русскоязычном пространстве. Вместе с Юрием Вашинко, опытным тимлидом и спикером нашего курса «С++ разработчик» сегодня рассмотрим, что такое Sentinel и как его использовать:

Недавно мне довелось работать над новым алгоритмом приближённого поиска ближайших соседей, который называется RaBitQ. Автор этого алгоритма уже предоставил достаточно скоростную реализацию на C++. Я попытался переписать этот алгоритм на Rust (ещё один случай «а почему бы не переписать на Rust»). Однако, я обнаружил, что моя реализация гораздо медленнее оригинальной. Далее я расскажу, как шаг за шагом доработал её производительность.

В данной статье речь пойдет про использование очень маленькой Luckfox Pico Mini. Я расскажу про особенности платы, её настройку, а также о том как запускать на ней нейронные сети для детекции объектов с камеры.

Мне удалось добиться скорости детекции в 15 FPS (или даже 50!), результат, который по силам далеко не каждому одноплатнику.

void в плюсах довольно забавная штука. Мы можем привести к void почти любой тип, завести указатель с типомvoid*, который может адресовать что угодно. Еще можем сделать функцию с возвращаемым типом void , которая ничего не возвращает. Объявление функции типа void f(void) будет просто функцией без аргументов. Но вот иметь объекты типа void или написать что-то вроде void& не можем. Это немного странно, но не настолько, чтобы вызывать у вас бессонные ночи, пока вы не начинаете ловить странные баги, когда void вообще не void.

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

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

На протяжении нескольких лет я участвовал в разработке блокчейн-платформы, вначале как разработчик, затем как руководитель команды (team lead, как это принято сейчас называть). За это время мне посчастливилось пройти все стадии жизненного цикла продукта, от идеи до выхода в продакшн. И это был уникальный опыт, в каком-то смысле драматический.  Дело в том, что в процессе своей довольно длительной карьеры я участвовал в огромном множестве самых различных проектов, но до сих мне не приходилось сталкиваться с таким количеством нетривиальных задач, которые требовали нестандартных решений.  И я хотел бы поделиться этим опытом.

Для кого? В первую очередь для специалистов, занимающихся проектированием блокчейн-систем – ведь всегда полезно посмотреть, что происходит у коллег по цеху. Руководителям команд, мне кажется, будет интересно понаблюдать за борьбой идей, процессом выработки решений, допущенными ошибками и их исправлениями. Остальным категориям разработчиков ПО представится возможность заглянуть во внутреннюю кухню блокчейна, увидеть, как это работает «под капотом», и применить полученные знания в других областях, не обязательно связанных с блокчейном.

Привет, Хабр! В предыдущей статье был разобран первичный анализ работы приложения, какие инструменты стоит использовать для сбора информации и как с этими инструментами работать. Напомню, что речь шла о двух утилитах: poor man's profile (pt‑pmp), которая позволяет комплексно оценивать работу приложения, отображая off-cpu и on-cpuчасти; и perf, которая обладает высокой точностью и мощной функциональностью в целом. Оба этих инструмента применяются для анализа производительности, так как их комбинация позволяет целиком и со всех сторон осмотреть «пациента».

Однако есть один пункт, который не был раскрыт в прошлой части: использование этих инструментов на настоящих продуктах. Синтетический пример на базе open‑source‑проекта — это хорошо, но будет не лишним показать, какие реальные проблемы были найдены, исправлены и какой прирост производительности удалось в итоге получить. В этой статье мы поговорим о практическом применении pt-pmp и perf, с помощью которых удалось обнаружить места для оптимизации работы программы. Меня по‑прежнему зовут Александр Слепнев, устраивайтесь поудобнее, начинаем!

Привет, Хабр! Меня зовут Алексей Салтыков, я инженер-программист в команде КОМПАС-3D. Решил поделиться соображениями насчет оптимизаций в С++ глазами обычного разработчика. Хочется сразу предупредить, что статья никого ни к чему не призывает. Цель – наглядно показать, как незначительные трансформации кода могут помочь компилятору лучше оптимизировать код и насколько это вообще эффективно.

Привет, Хабр! Меня зовут Кирилл Колодяжный, я пишу код на С++ для систем хранения данных в YADRO. Помимо основной работы, интересуюсь машинным обучением и его возможностями, в том числе на «плюсах». Недавно мне стало интересно разобраться, как развернуть модель компьютерного зрения на мобильном устройстве с операционной системой Android.

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

Расскажу, как реализовать обнаружение объектов в реальном времени с помощью камеры на мобильной платформе Android с использованием библиотек PyTorch и NCNN и моделей компьютерного зрения YOLOv5 и YOLOv4. Шаблон моего приложения пригодится тем, кто хочет проверить прототип функциональности для компьютерного зрения на С++, использующий OpenCV на Android, но не хочет глубоко погружаться в программирование под Android. 

В первой части цикла мы:

• создадим проект в IDE Android Studio,

• реализуем сессию непрерывного захвата изображений камеры,

• преобразуем изображения в матрицу OpenCV, чтобы сделать дальнейшую работу удобной.

Всем привет!

Не так давно на Хабре появился занятный пост о разработке процессора, и я понял, что созрел для своей первой статьи как раз в этом направлении.

Тема разработки эмуляторов олдскульных микропроцессоров типа того же Intel 8080 не нова. Если вы уже разбираетесь в вопросе, то для вас этот пост не будет чем-то новым, разве что вы увидите еще один подход к реализации такого проекта. Для тех, кто ничего об этом не слышал – прошу под кат.

Статический анализатор PVS-Studio постоянно совершенствуется для повышения эффективности анализа кода. В этой статье мы расскажем о последних обновлениях анализатора, которые существенно улучшают анализ проектов на основе Unreal Engine.

Привет, хабр! Программирую на C++ / Qt / QML в среде разработки QtCreator уже 6-ой год. У меня есть определенные пересечения мыслей с мозгом груга и еще мне постоянно хочется избавиться от глупой и рутинной работы, которая есть на разных этапах разработки. Одна из таких работ - возня с IDE и рабочим окружением, особенно в мире C++ разработки. В статье постараюсь раскрыть проблему и описать свой текущий подход к решению.

Думаю, многих из нас охватывает тёплое чувство ностальгии, когда речь идёт о PSP. Эта портативная консоль, выпущенная в 2004 году, стала настоящим прорывом для своего времени. Она подарила нам возможность наслаждаться полноценными игровыми проектами в дороге, что было невероятно новаторским для того периода. У вас словно была маленькая частичка домашней консоли в кармане.

В конце 90-х годов историческая серия градостроев от Sierra была на вершине популярности, получала отличные отзывы и породила немало последователей и подражателей, начиная от Сhildren of Nile и не заканчиваясь в Banished (2014), Pharaoh: A New Era(2023), Nebuchadnezzar (2021), Builders of Egypt(к сожалению закрытая) став фактически дедушкой жанра. Фараон появился в 1999 году после двух лет разработки, вслед за любимой многими Caesar III. Это была первая игра серии, которая перенесла сеттинг из Древнего Рима в Древний же Египет и предложила (хотя на самом деле фактически повторила, реальным шагом по механикам стал Зевс) сложный игровой процесс, не завязанный однако на микроменеджменте зданий и жителей. Собственно многие и помнят эти игры, благодаря сотням проваленных миссий, когда император в гневе присылал войска или королевство отзывало титул изза долгов. До первой игры от "пароходов" еще целый год, да и жанры и сеттинги достаточно далекие, так что 1999 и 2000 Фараон собирает лавры и сливки с продаж, а Simon Bradbury, главный технический гений студии и душа проекта, покидает команду и основывает свою Firefly Studios, чтобы подарить нам Stronghold.

В процессе кодоархеологических раскопок бинарника, что Цезаря, что Фараона было найдено немало интересных окаменелостей легаси технических решений, многие из которых я видел в других проектах и не только игровых. Возможно это дремучее легаси (хотя и не такое дремучее как AoE1/2) может показаться топорным, но красота решений определенно есть, и учтите что игры запускались и выдавали неплохие фпс (15-30), работая на разных первых пеньках, 586, атлонах с 32 мб памяти всего, а не только кеша. И работали быстро, красиво и на одном ядре.

Хабр, привет! Меня зовут Никита, я софтвер-инженер в Huawei. Мой путь в IT был не совсем обычным — я осваивал алгоритмы раньше языка, откатывался почти к старту на каждом месте работы, а однажды даже занял второе место в хакатоне для «питонистов» без знания Python. Но обо всём по порядку.

В мире программирования создание собственных библиотек — это не просто возможность пополнения своего портфолио или способ структурировать код, а настоящий акт творческого самовыражения (и иногда велосипедостроения). Каждый разработчик иногда использовал в нескольких своих проектах однообразный код, который приходилось каждый раз перемещать. Да и хотя бы как упаковать свои идеи и знания в удобный и доступный формат, которым можно будет поделиться с сообществом.

Если вы ловили себя на мысли: «А почему мне бы не создать свою полноценную библиотеку?», то я рекомендую прочитать вам мою статью.

Эту статью вы можете использовать как шпаргалку для создания проектов, и не только библиотек.

Некоторые из вас могут подумать, что мы изобретаем велосипед. А я в ответ спрошу — сможете ли вы прямо сейчас, без подсказок, только по памяти, нарисовать велосипед без ошибок?

Добро пожаловать во вторую, скорее всего финальную часть статьи! Здесь мы окончательно допишем код, исправим некоторые ошибки.