Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

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

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

В обзоре рассмотрим самые ключевые вопросы при выборе Service Desk, оценим ключевые критерии выбора, задел которым дали иностранные решения и кратко пройдемся по основным вариантам на российском рынке.

За годы работы я подробно изучил, как центральные процессоры (CPU) выполняют код и как они устроены внутри. Дело в том, что я участвовал в разработке ядра Linux и ScyllaDB, а этот код очень близок к металлу. Я даже немного баловался с Verilog, безрезультатно попытавшись собрать моё собственное ядро RISC-V.

Графические процессоры (GPU) в отличие от обычных в основном оставались для меня чёрным ящиком, несмотря на то, что поработать с ними всё-таки довелось. Помню, что экспериментировал с NVIDIA RIVA 128 или чем-то подобным, проверяя, как там работает DirectX. Тогда такие процессоры ещё не выделялись на фоне ускорителей 3D-графики. Я также пытался идти в ногу со временем и немного упражнялся в программировании элементарных шейдеров на современных GPU. Но я никогда глубоко не вдавался в работу с GPU, и мои взгляды можно назвать CPU-центричными.

Однако, поскольку сегодня наблюдается всплеск рабочих нагрузок, связанных с ИИ, и, в частности, приходится работать с большими языковыми моделями (БЯМ), графические процессоры становятся незаменимыми для современных вычислений. К задачам, решаемым с применением ИИ, относятся масштабные прикладные тензорные операции, в том числе — сложение и перемножение матриц. А это уже работа для GPU. Но как современный GPU выполняет их, и насколько при этом возрастает эффективность по сравнению с выполнением таких же рабочих нагрузок на CPU?

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

Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.

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

Многие компании сталкиваются с вопросом эффективной автоматизации бизнес-процессов и часто рассматривают BPM-системы как очевидное решение. Однако стоит ли полагаться на стандартизованную нотацию или лучше выбрать более гибкий путь? 

Меня зовут Иван Жигалов, и в этой статье мы разберемся, почему движение в сторону low-code-платформ приобретает все большую популярность среди предприятий, стремящихся к комплексной автоматизации бизнес-процессов.

При вызовах функций на языке С активно используется стек, который также именуется «стек вызовов». По мере того, как мы вызываем функции, они формируют так называемый «стек кадров». При каждом вызове функции образуется кадр, и эти кадры укладываются в стеке, где под них выделяется место. Далее в кадре из стека выделяется память под переменные и промежуточные значения. В кадре стека также содержится указатель на предыдущий кадр и значение счётчика команд. Та команда, которой оно соответствует, должна быть выполнена, как только кадр будет вытолкнут из стека. Далее давайте дизассемблируем вызовы функций в C, чтобы понять, как устроен стек кадров в ассемблере для ARM.

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

Некоторое время назад я написал несколько статей о различных трюках, применявшихся в операционной системе DOS, чтобы вписаться в те жёсткие лимиты памяти, которые действовали в реальном режиме на архитектуре x86. Постоянно возникал и оставался без ответа один вопрос: а каковы были различные «модели», которые предлагались компиляторами тех времён? Взгляните, как выглядело меню для генерации кода в Borland Turbo C++.

Tiny (крошечный), small (маленький), medium (средний), compact (компактный), large (большой), huge (огромный)… Что означают эти опции? Каковы их эффекты? Ещё важнее… а так ли важен весь этот антиквариат сегодня, в мире 64-разрядных машин и гигабайтных ОЗУ? Чтобы ответить на этот вопрос, сделаем небольшой обзор архитектуры 8086 и тех двоичных форматов, которые поддерживались в DOS.

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

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

Именно на примере системных вызовов удобно продемонстрировать цепочную загрузку, и на то есть три причины...

В этой статье мы рассмотрим классический конкурентный кольцевой буфер и обсудим, как его можно оптимизировать для повышения производительности. Я покажу вам, как существенно улучшить этот показатель от 5,5 миллионов элементов в секунду до 112 миллионов элементов в секунду — и эти показатели выше, чем в реализациях Boost и Folly. Если вам требуется готовая реализация со всеми этими оптимизациями, посмотрите мою библиотеку SPSCQueue.h.

Кольцевой буфер также называется очередью «один производитель — один потребитель» (SPSC). В ней не бывает ожидания (и, соответственно, не бывает блокировок), это конкурентный примитив. Такая структура данных находит множество вариантов применения, и здесь я рассмотрю передачу сетевых пакетов между сетевым контроллером и драйверами операционной системы. Основная задача, решаемая при этом — выполнение событий ввода/вывода в относительно новом асинхронном API io_uring.

В настоящее время планировщик работы с ядрами ЦП, действующий в ядре Linux, предусматривает несколько режимов вытеснения. В этих режимах предлагается целый ряд компромиссов между временем отклика и пропускной способностью системы. Ещё в сентябре 2023 года развернулась дискуссия о работе планировщиков, в результате которой была выработана концепция «ленивого вытеснения». Данная концепция упрощает планирование задач в ядре, при этом улучшая результаты. Какое-то время эта работа протекала тихо, но затем ленивое вытеснение было заново реализовано Питером Зайлстрой в виде этой серии патчей. Притом, что сама концепция с виду работает хорошо, здесь ещё немало требуется доделывать.

Не кажется ли вам, что декларативная конфигурация и программирование инфраструктуры не так уж хороши, как их расхваливают?

Я достаточно долго занимался декларативной конфигурацией в Kubernetes: размышлял о ней, работал с kubectl apply, KRM, kustomize, Google Cloud Config Sync, kpt, porch, ... В то же время параллельно развивалась декларативная автоматизация — эта работа велась в Google, где на протяжении многих лет широко использовалась декларативная конфигурация. При этом вне Google появился Terraform, и на этом лоскутном одеяле также возникло множество других инструментов.

Что же такое декларативная конфигурация, в каких случаях она хороша, и как к ней подступиться?

GPU, также именуемый «видеокартой» или «графическим процессором» – это важнейший компонент компьютера, отвечающий за отображение картинок и видео. Графический процессор, в отличие от обычного ЦП (CPU), превосходно дробит задачи на подзадачи и распараллеливает их. В GPU всегда много ядер, поэтому вычисления на нём выполняются более эффективно. Поэтому GPU идеально подходит для многозадачности. В следующей таблице даётся упрощённое сравнение CPU и GPU.

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

В ходе такой работы нам исключительно пригодился подход под названием «дата-ориентированное проектирование». Это идея, согласно которой при структурировании кода требуется отталкиваться от специфики тех данных, с которыми приходится работать.

Дата-ориентированное проектирование часто используется при программировании игр, где именно от скорости среды выполнения зависит, что вы сможете и чего не сможете сделать. В последнее время эта парадигма стала активнее применяться и в других предметных областях, например, в разработке компиляторов для Zig и Rust, а также в других проектах, где акцент делается на ускорении среды выполнения, например, в  Mold и Bun.

Эндрю Келли, создатель Zig, выступил с отличной лекцией Practical Data-oriented design, которая служит введением в основные идеи, лежащие в основе DoD. В этой статье я покажу, как мы изменили компилятор roc, переработав его с учётом некоторых из этих идей.

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

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

На устройствах интернета вещей (IoT) зачастую слишком мало ресурсов, и их не хватает, чтобы подтягивать и использовать тяжеловесные образы Docker. В этой статье будет показано, как можно уменьшить образ Docker на 36-91% при помощи инструментов patchelf и strace, не перекомпилируя при этом контейнеризованные приложения. Также рассмотрим, как создавать минимальные образы для собственных приложений, написанных на Rust, Go, C/C++.

Подробно о том, что происходит под капотом в ядре Linux, когда вы выполняете очередной системный вызов при работе с сокетами.