Приветствую! В этой статье я расскажу, как мне удалось запустить DOOM на осциллографе Siglent SDS5034X. Для этого пришлось найти шелл (вендор получил мой репорт), адаптировать систему ввода игры под энкодеры на лицевой панели и вывести звук на встроенную «пищалку».
Недавно пришлось собирать ffmpeg под Windows компилятором MSVC. И знаете — я чуть не помер. Официальная документация по сборке проекта под Windows безнадежно устарела. В Интернете есть даже статьи, которые так и заявляют: "Официальная документация по сборке ffmpeg под Windows безнадежно устарела — вот как теперь это делается". И смех в том, что эти статьи уже тоже устарели и не дают работающего решения "press X to compile".
Поэтому я просто оставлю здесь инструкцию, которая работает на февраль 2026. И, возможно, устареет, как и все предыдущие. Но вы тогда мне просто об этом напишете, и я попробую актуализировать эту инструкцию.
Tarantool – это in-memory СУБД с открытым исходным кодом, разрабатываемая VK Tech. Существует два способа разработки приложений для Tarantool. Как и к большинству СУБД, к Tarantool можно подключаться из внешнего приложения по TCP/IP. С этой целью для многих популярных языков программирования (включая Go, Python, C#, С++, Java и др.) разработаны соответствующие коннекторы. Это – первый способ.
Кроме этого, Tarantool обладает замечательной особенностью: он позволяет запускать бизнес-логику на встроенном сервере приложений. В этом случае пользовательский код исполняется в одном адресном пространстве с данными, что обеспечивает высокое быстродействие. Это – второй способ.
Если мы ведем разработку для встроенного сервера приложений Tarantool, то выбор языков программирования более ограничен. Основным языком программирования, в этом случае, является Lua. Также, часть логики может быть реализована на C/C++. Но набор доступных языков расширяется. Например, с некоторого времени, поддерживается Rust. Помимо этого, Tarantool может выполнять Wasm-приложения. Скоро код библиотеки для разработки на Wasm будет открыт.
Tarantool – высокопроизводительная СУБД, часто используемая для построения highload-систем. Какой из вариантов разработки позволяет достичь максимального быстродействия (которое в таких системах будет не лишним)? В настоящей статье я хотел бы рассмотреть возможные способы вызова C-кода из Lua/LuaJIT/Tarantool (в режиме сервера приложений) и то, как это может ускорить и без того быструю СУБД.
Недавно на работе мы столкнулись с большим потреблением памяти в игре. Связано оно было с хранением большого количества информации о террейне и свойствах его клеток, которое нужно игре для разных геймплейных расчетов. Проблема насущная, особенно остро проявляется как раз в больших массивах или матрицах с большими размерностями.
Довольно типичный случай — у вас есть вполне себе нормальная структура, которая хранит информацию об одном объекте. Но самих объектов очень и очень много. Скажем, у вас 1000x1000 клеток террейна. А это уже целый миллион объектов! И вот ваша структура размером с несчастные 32 байта множится миллион раз и разрастается до объемов 30.5 Mб оперативной памяти.
Эта статья — она не про умные решения этой проблемы, она чуть приземленнее. Прежде чем приступать к дорогостоящим по времени и ресурсам переделкам, стоит совершить, так сказать, нулевой шаг оптимизации - попробовать оптимизировать саму структуру или класс, хранящий информацию, так, чтобы он стал занимать меньше места. Сэкономим на спичках!
Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень) и алгоритмах на языке C!
Если вы видите эту статью, значит еще не все тайны C раскрыты. В этом материале будет еще больше свежих хаков, фанов, трюков, еще больше магии и скорости! А также нетипичных алгоритмов и структур данных, что позволит вам почерпнуть и полезную информацию тоже.
Добро пожаловать в восьмую часть. Прошу под кат — там будет жарко, быстро и очень, очень интересно.
Привет, Хабр! Недавно я задумался: Python — не единственный инструмент, которым я хочу оперировать в своих инструментах. Python, понятно, легко освоить и он применяется везде, но язык-то не идеальный! Ресурсов требует много, да и время выполнения не ахти, а учитывая нынешние темные времена... Мне нужно что-то получше. В общем, тут я вздумал попробовать Си.
Как Вы могли заметить, у микроконтроллеров STM32F4 секторы NOR Flash памяти обладают разным размером: 16kByte(4 шт), 64kByte (1 шт), 128kByte ( 7+ шт.).
Это накладывает определенную специфику на программирование микроконтроллеров STM32F4.
Из каких секций обычно состоит Flash память микроконтроллерной программы?
В этом тексте я предлагаю простое решение проблемы разметки памяти для случая работы с микроконтроллерами STM32F4.
Приветствую всех, кто хочет делать свой код быстрым и оптимальным. В этой статье мы расссмотрим один из способов, как можно просто и легко оптимизировать программу на C++ при работе со структурами/классами, почти не меняя код.
Приветствую всех читающих это продолжение недавней статьи про мои изыскания в мире программирования отечественного микроконтроллера К1946ВК035 в качестве регулятора оборотов бесколлекторных двигателей.
Ровно полгода назад, 18 августа 2025 года, я опубликовал здесь свою первую статью о портировании прошивки AM32 на отечественный микроконтроллер К1946ВК035.
Ссылка на статью - https://habr.com/ru/articles/938128/
Те, кто читал ту статью (а таких людей, уверен, немного), помнят: не весь функционал удалось портировать с сохранением исходной производительности из-за некоторых ограничений в работе периферийных модулей отечественного микроконтроллера.
Напомню суть проблемы: микроконтроллер слишком часто уходит в прерывания для обработки входящих сигналов DSHOT, которые мы пытались обрабатывать сугубо софтварно, без применения DMA (но с небольшими хитростями). Отсюда и проблемы со своевременной обработкой сигналов других частей программы.
В данной статье я описал, как мы разрабатываем систему для функционального контроля микросхем ADV7180BCPZ (SDTV Video Decoder) и ADV7343BSTZ (Multiformat Video Encoder). Показана архитектура системы, общий алгоритм и сценарии тестирования.
Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.
Считайте этот пост краткой подборкой тех вещей, которые мне действительно помогают. Рискуя, что меня могут обвинить в тщеславии, назову их «наилучшими практиками», хотя, это действительно мои рабочие практики, поэтому, если они вам понравятся — смело берите их на вооружение.
Одно из недооценённых событий уходящего года деревянной змеи - в проекте стандарта языка С появился оператор числа элементов. Как заметил один мудрый товарищ, Алексей Годин, даже полвека ещё не прошло, а наконец, дождались.
Признаюсь, я питаю слабость к классическому DOOM. Игре уже 31 год, но благодаря открытому исходному коду она живёт на всём — от смартфонов до осциллографов. В силу разных обстоятельств я стал сопровождать несколько пакетов, связанных с DOOM, в Fedora Linux.
Перед каждым релизом Fedora проводит массовую пересборку всех пакетов — и в этот раз chocolate-doom её не пережил. Виновник этому — маленький bool.
340% рост AI-атак за 2025 год, а защита LLM всё ещё — «закиньте промпт в облако, подождите 200ms». Я построил альтернативу: SENTINEL — open-source стек из C, Rust и Python, который фильтрует jailbreak за <3ms on-premise. Ключевая фича — Micro-Model Swarm: рой из моделей <2000 параметров, который ловит то, что не видят регулярки.
В вашем ядре сейчас есть баги, которые не найдут в течение многих лет. Я знаю это, потому что проанализировала 125 183 из них, каждый в 20-летней git-истории ядра Linux помечен прослеживаемым тегом Fixes:.
Средний баг ядра существует 2,1 года. А некоторые подсистемы намного хуже: драйверы CAN‑шины [шины сети контроллеров] — в среднем 4,2 года, работа с сетью SCTP — 4,0 года. Самый долгоживущий баг в моём наборе данных — переполнение буфера в ethtool — сохранялся в ядре 20,7 лет. Подробно остановлюсь на утечке памяти из‑за подсчёта ссылок в netfilter, существовавшей 19 лет.
Я создала инструмент, который выявляет 92% исторических багов в отложенном тестовом наборе данных о времени коммита. Вот что я узнала.
Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.
Привет Хабр!
Сегодня я решил закрыть трилогию статей, а закончи парой не мало важных тем. Хочу сказать огромное спасибо тем кто активничает и задает вопросы. Ну что ж, начнем.
В данной статье я описываю свой опыт разработки приложений с OpenCL/SYCL.
Вычисления на видеокартах ассоциируются преимущественно с графикой, научными вычислениями и с недавних пор с нейросетями. Но чаще всего с графикой.
Тем не менее, графические процессоры обладают свойствами, за счёт которых их очень удобно использовать в задачах, напрямую не связанных с перечисленным выше. И главное из этих свойств – массовый параллелизм.
Самый краткий ввод в гетерогенное программирование: у нас есть две роли — хост и девайс, задача хоста – формировать задачи и отдавать их на девайс, в то время как задача девайса обработать их и вернуть результат. При этом хост и девайс могут быть одним вычислительным устройством (это не обязательно CPU + GPU, так как CPU может отдавать задачи сам себе).
Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но раздвигает границы дозволенного. А иногда позволяет найти необычные эффективные решения. В этой статье я хочу рассказать вам об интересных алгоритмах, и невозможных возможных трюках.
Идея написать эту статью зародилась из моего поста, после него я начал серию статей, которая раскрывала много интересных моментов — от математических алгоритмов и оптимизации до ГПСЧ и битовых трюков.
Если вы видите на экране эту часть нашей бесконечной саги о ненормальном программировании на C, значит, мы с вами прошли уже немало.
В этой статье будет еще порция свежих алгоритмов, фанов, трюков, еще больше магии и скорости! Код Мортона, GNU расширенияи и многое другое.
Добро пожаловать в новую часть. Прошу под кат — там будет жарко, быстро и очень, очень круто.
