С/С++ Portal | Программирование

Одна из самых недооценённых анонсированных на WWDC фич — Container Machines. Она позволяет запускать на Mac лёгкое и постоянное Linux-окружение, в котором домашний каталог пользователя и репозитории автоматически монтируются внутрь контейнера. По сути, разработчики получают Linux-среду, тесно интегрированную с macOS, без необходимости вручную настраивать виртуальные машины или сложную инфраструктуру контейнеров.🍎🐧 https://github.com/apple/container/blob/main/docs/container-machine.md 👉 @Cpportal

Забавный факт: решето Эратосфена позволяет найти все простые числа примерно до 8 миллионов, используя всего около 1 МБ памяти. Один бит хранит информацию об одном числе, а внутренний цикл помечает составные числа с помощью битовых операций. Этот же подход используется в генераторах простых чисел и при выборе размеров хеш-таблиц. Если пост был полезен как и всегда - ставь like 🫢 👉 @Cpportal

Только что наткнулся на довольно безумную штуку — Linux прямо в браузере. ✓ Без установки и настройки, всё работает через WebAssembly ✓ Из коробки доступны Python, C, C++, Vim, cURL и другие инструменты ✓ Есть доступ в интернет, так что можно ставить дополнительные пакеты Потыкать можно здесь: webvm.io Честно, не ожидал, что это будет работать настолько хорошо. 👉 @Cpportal

Этот алгоритм подсчёта установленных битов был опубликован ещё в 1957 году. Он считает все 64 бита параллельно с помощью арифметики над битовыми масками, вместо того чтобы проходить по каждому биту в цикле. Когда инструкция POPCNT недоступна, ядро Linux использует ту же идею в функции __sw_hweight64. 👉 @Cpportal

Я читал исходники SQLite и нашёл интересную вещь. DELETE на самом деле не уменьшает размер файла базы данных. Удалённые страницы попадают во внутренний freelist прямо внутри файла. Новые INSERT сначала переиспользуют эти свободные страницы, а уже потом снова увеличивают базу. Сам файл уменьшается только после VACUUM. Можно удалить всё из базы на 1 ГБ, а файл всё равно останется 1 ГБ, пока вы его не сожмёте. 👉 @Cpportal

Аллокатор памяти в NGINX по сути представляет собой указатель, который движется только вперёд. В нём нет free list-ов, он избегает фрагментации и сохраняет минимальные накладные расходы на каждое выделение памяти. Память выделяется из одного большого блока по мере поступления запросов. Когда обработка запроса завершается, весь пул памяти освобождается целиком за один раз. Именно этот аллокатор используется в nginx/src/core/ngx_palloc.c 👉 @Cpportal

файловый организатор, который автоматически наводит порядок в захламлённой папке Downloads. Достаточно запустить его один раз, и он разложит файлы по категориям: изображения в Images/, документы в Documents/, видео в Videos/ и так далее. 👉 @Cpportal

Знаете ли вы, что в ядре Linux есть механизм, появившийся ещё в 1997 году, который сегодня позволяет Mac на Apple Silicon эффективно запускать x86-контейнеры? Он называется binfmt_misc и был добавлен в Linux 2.1.43 почти 30 лет назад. Принцип работы очень простой. Когда ядро Linux запускает бинарный файл, оно сначала читает magic number из заголовка файла. Если заранее зарегистрировать правило в /proc/sys/fs/binfmt_misc/ вида: «При встрече файла с таким magic number передавать его определённому интерпретатору», то ядро автоматически передаст выполнение этому интерпретатору. По сути, это тот же механизм, что и shebang #!/bin/bash, только сопоставление выполняется не по первой строке файла, а по сигнатуре бинарного заголовка. Изначально этот механизм использовался для того, чтобы Linux мог напрямую «запускать» Java class-файлы и Windows PE-исполняемые файлы. Позже QEMU использовал его для реализации пользовательской эмуляции между архитектурами: запуск x86 ELF-бинарников на ARM Linux, где ядро автоматически вызывало qemu-x86_64 для трансляции. Затем появился Apple Silicon. Когда на Mac с Apple Silicon вы запускаете Linux VM через Colima или Lima (использующие Virtualization.framework в macOS) и включаете rosetta: true, происходит следующее: macOS монтирует бинарник-транслятор Rosetta внутрь Linux VM по пути /mnt/lima-rosetta/rosetta через virtio-fs. Внутри VM регистрируется обычное правило binfmt_misc: при обнаружении x86_64 ELF-сигнатуры (7f454c46...02003e00) передавать выполнение /mnt/lima-rosetta/rosetta. После этого любой запуск x86_64-бинарников внутри VM автоматически перехватывается ядром и передаётся Rosetta для трансляции. Для контейнеров всё выглядит полностью прозрачно. Команда:

docker run --platform linux/amd64 nginx

-скачивает x86-образ, процессы внутри контейнера являются x86 ELF-бинарниками, а ядро Linux автоматически запускает трансляцию через Rosetta с помощью binfmt_misc. Сам контейнер даже не подозревает, что происходит за кулисами. Сравнение производительности:

Подход с Rosetta: около 70–90% от нативной производительности (JIT-трансляция и оптимизация на уровне инструкций). Подход с полной виртуализацией через QEMU: примерно 10–30% от нативной производительности (полная эмуляция x86-процессора).

Механизм ядра, созданный в 1997 году для запуска Java class-файлов, в 2024 году стал одним из ключевых элементов инфраструктуры для запуска x86-контейнеров на Apple Silicon. Иногда самые долговечные архитектурные решения оказываются самыми простыми и универсальными абстракциями.

$ colima ssh
$ cat /proc/sys/fs/binfmt_misc/rosetta

enabled
interpreter /mnt/lima-rosetta/rosetta
flags: OCF
magic 7f454c4602010100000000000000000002003e00

👉 @Cpportal

Явная инстанциация шаблонов в C++ — полезная возможность для борьбы с раздуванием кода из-за шаблонов. Однако ни в одном туториале не объясняют, что инстанциации стоит разносить по нескольким файлам. Может, предполагается, что все должны сами до этого додуматься? 👉 @Cpportal

Очередное напоминание, что если хочешь реально понять, как работает компьютер, рано или поздно придётся написать всё это самому: • мини-шелл (fork, exec, пайпы, сигналы) • свой malloc/free • монитор процессов через /proc • рекурсивный обход файловой системы • HTTP-сервер на сокетах • многопользовательский чат через TCP и select() • пакетный менеджер с распаковкой tar.gz Парень собрал весь этот набор с нуля, без сторонних библиотек. Самое интересное, что это не учебные проекты ради галочки. Всё идёт в EduOS — offline-first ОС с ИИ для школ в Африке. Нравится такой подход. Вместо бесконечных туториалов по очередному JS-фреймворку человек просто сел и начал разбирать фундаментальные вещи. Следующий этап у него — ассемблер. https://github.com/MonarchCorps 👉 @Cpportal

Каждому системному разработчику стоит это прочитать. Параллелизм перестанет казаться чёрным ящиком: от lock-free до wait-free синхронизации — эта насыщенная статья навсегда изменит твоё представление о конкурентности PDF: https://assets.bitbashing.io/papers/concurrency-primer.pdf 🥲 👉 @Cpportal

📎 Смотрите записи докладов с Backend Talks от Яндекс 360 На конференции обсуждали решение прикладных архитектурных задач и разбирали реальные инженерные кейсы. Будет полезно и интересно вне зависимости от стека.

➕ Направленный ациклический граф в PostgreSQL: как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей. Малик Минубаев, разработчик в B2B-платформе, рассказал, почему стандартные паттерны хранения иерархий не работают для ориентированного ациклического графа. А также сравнил несколько вариантов Closure Table с бенчмарками на реальной нагрузке

➕ Как Яндекс Диск выдерживает сотни гигабит входящего трафика: устройство балансировки загрузок. Илья Абрамов, разработчик в Диске, разобрал, почему нам не подошёл подход «как у всех», и показал эволюцию алгоритма балансировки загрузок: от наивного Round-Robin до разработки собственного алгоритма

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

➕ Зачем и как бэкендеру расти в карьере в 2026 году. Дмитрий Соломонов, руководитель группы B2B-разработки бэкенда Диска, рассказал, как развивать команду с помощью индивидуальных планов и выбора узкой специализации для разных уровней разработчиков. И поделился, как связать получение знаний с реальными задачами

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

🎤 Плейлист доступен на YouTube и в VK Видео

MIT преподаёт операционные системы, давая студентам рабочее Unix-подобное ядро и предлагая им его модифицировать. Оно называется xv6. Это переосмысление Unix Version 6 образца 1975 года, переписанное на современном C для многопроцессорных систем на архитектуре RISC-V. Всё ядро занимает всего около 6000 строк кода. Процессы, системные вызовы, виртуальная память, файловые дескрипторы, каналы (pipes) и планировщик задач здесь присутствуют в полном виде, так что их можно изучать и экспериментировать с ними. Именно такие вещи изучают, когда хотят понять, как операционная система работает на практике, а не только на уровне общих концепций. Это реализация чтения из канала (pipe) в xv6 из файла kernel/pipe.c. Когда канал пуст, процесс-читатель переводится в состояние сна и ждёт появления данных на стороне чтения. Как только процесс-писатель записывает данные в канал, он пробуждает читателя. Блокировка (lock), перевод процесса в сон (sleep) и его пробуждение (wakeup) здесь скоординированы всего примерно в 15 строках кода.

// xv6 kernel kernel/pipe.c piperead

int
piperead(struct pipe *pi, uint64 addr, int n)
{
    int i;
    struct proc *pr = myproc();

    acquire(&pi->lock);
    while(pi->nread == pi->nwrite && pi->writeopen){
        if(killed(pr)){
            release(&pi->lock);
            return -1;
        }
        sleep(&pi->nread, &pi->lock);   // wait until a writer adds data
    }

    for(i = 0; i < n; i++){
        if(pi->nread == pi->nwrite)
            break;

        pi->data[pi->nread++ % PIPESIZE]; // consume one byte from the ring buffer
    }

    wakeup(&pi->nwrite);   // writers may have space now
    release(&pi->lock);
    return i;
}

https://pdos.csail.mit.edu/6.828/2025/xv6/book-riscv-rev5.pdf 👉 @Cpportal

И ещё одна книга с открытым доступом для углублённого изучения встраиваемых систем. https://link.springer.com/book/10.1007/978-3-030-60910-8 👉 @Cpportal

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

В 2008 году Джеймс Моллой написал бесплатный туториал, который показал тысячам разработчиков, как собрать UNIX-подобную операционную систему с нуля на C и ассемблере. Он называется "Roll Your Own Toy UNIX Clone OS" и пошагово проводит через создание настоящего ядра. В руководстве разбираются: • загрузчик (bootloader) • GDT и IDT • обработка прерываний • страничная память (paging) • управление кучей (heap management) • файловые системы Глава про Interrupt Descriptor Table (IDT) показывает, как процессор прерывает текущее выполнение и передаёт управление вашему коду.

// isr.c - called straight from the assembly interrupt entry code
typedef struct registers {
    u32int ds;

    u32int edi, esi, ebp, esp;
    u32int ebx, edx, ecx, eax;

    u32int int_no, err_code;
    u32int eip, cs, eflags, useresp, ss;
} registers_t;

void isr_handler(registers_t regs) {
    monitor_write("received interrupt: ");
    monitor_write_dec(regs.int_no);
    monitor_put('\n');
}

// assembly stub saves CPU state into this struct first
// handler just gets a snapshot of the registers at interrupt time
// handy for debugging when you're bringing up the kernel.

В ней разбирается настоящий isr_handler из туториала. Именно эта функция вызывается каждый раз, когда срабатывает прерывание. Достаточно взглянуть на неё один раз, чтобы понять базовый механизм работы прерываний. Структура registers напрямую соответствует значениям, которые процессор сохраняет в стек при возникновении прерывания. На этом и строится вся схема: • процессор сохраняет текущее состояние • передаёт управление обработчику прерывания • обработчик анализирует сохранённые данные • после завершения управление возвращается к прерванному коду Всё просто. Процессор сохраняет контекст, вызывает ваш код и затем продолжает выполнение с того места, где остановился. • многозадачность • пользовательский режим (user mode) Каждая глава содержит рабочий код, который можно скомпилировать, запустить в QEMU и самостоятельно поэкспериментировать с внутренним устройством операционной системы. https://web.archive.org/web/20160412174753/http://www.jamesmolloy.co.uk/tutorial_html/index.html 👉 @Cpportal

Если тема кэш-памяти и производительности вам интересна, рекомендую главу Data Locality из книги Game Programming Patterns. https://gameprogrammingpatterns.com/data-locality.html Там очень простым языком объясняется вещь, которую многие разработчики начинают понимать только после профилирования реальных приложений.

We can process data faster than ever, but we can't get that data faster.

Процессоры становятся всё быстрее. Память тоже становится быстрее, но разрыв между скоростью CPU и скоростью доступа к данным продолжает оставаться огромным. Поэтому во многих случаях производительность упирается не в количество инструкций и не в сложность алгоритма. Она упирается в то, насколько эффективно ваша программа получает данные из памяти. После этой главы многие вещи вроде cache misses, data-oriented design, SoA vs AoS и производительности циклов начинают выглядеть намного понятнее. 👉 @Cpportal

Если ещё не читали, обязательно посмотрите книгу "Optimizing Software in C++" от Agner Fog. В контексте обсуждения этой темы особенно рекомендую главу 9 — "Optimizing Memory Access". Она хорошо показывает, насколько сильно производительность может зависеть не от алгоритма, а от того, как программа работает с памятью. Там много примеров про кэш-память, шаблоны доступа к данным, пропуски кэша, предвыборку данных и другие вещи, которые часто оказываются важнее микрооптимизаций в коде. Некоторые моменты из этой главы ломают представление о том, где на самом деле теряется производительность. PDF: https://agner.org/optimize/optimizing_cpp.pdf#page=92 👉 @Cpportal

Ключевое слово из стандарта C99 может заметно ускорить выполнение циклов, при этом не добавляя никаких накладных расходов во время выполнения. restrict Оно сообщает компилятору, что два указателя не алиасируют друг друга, то есть никогда не ссылаются на пересекающиеся области памяти. Эта дополнительная информация даёт оптимизатору больше свободы и часто позволяет применять SIMD-векторизацию. Без restrict компилятор вынужден предполагать, что запись через один указатель может повлиять на данные, которые читаются через другой указатель. С restrict он знает, что указатели независимы, и может генерировать инструкции AVX и SSE, которые в противном случае были бы небезопасны. Это одна из причин, почему memcpy() можно оптимизировать агрессивнее, чем memmove(). memcpy() объявлена с указателями, квалифицированными через restrict, тогда как memmove() обязана корректно работать с перекрывающимися областями памяти. restrict был добавлен в стандарт C99 в 1999 году. GCC поддерживает его уже много лет как через restrict, так и через __restrict__. Если вы точно знаете, что ваши указатели никогда не пересекаются, но не сообщаете об этом компилятору, то можете терять производительность SIMD-оптимизаций. 👉 @Cpportal

Если тебя прёт от low-level систем, тебе зайдёт этот блог Cloudflare про branch prediction. Cloudflare разбирает, как работает предсказание ветвлений в современных CPU, почему if-ы стоят дороже, чем кажется, как устроен Branch Predictor Unit (BPU), и что происходит на x86 и Apple M1 при большом количестве условных переходов. Блог: Branch predictor: How many "if"s are too many? 👉 @Cpportal