Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё?

Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp.

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

Два варианта абстрактного синтаксического дерева (AST) для выражения a * b + c.

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

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

Чтобы изучить выравнивание, мы дважды напишем простейший интерпретатор: сначала как обычно, а затем с применением выравнивания. Логика поста прослеживается по коду из этого репозитория, где можно сравнить две ветки. Здесь важнее всего отметить, что изменения минимальны, но при этом микробенчмарки показывают, что после выравнивания код работает в 2,4 раза быстрее. Благодаря выравниванию не только повышается производительность, но и сам код становится эргономичнее, на чём я также остановлюсь.

В этом посте описана одна из причин, по которой растёт расход памяти и возникают утечки, что при работе под Windows может приводить к исключениям OutOfMemoryException. Проблема может возникать после того, как приложение обновится с версии .NET 6 или ниже до .NET 7 или выше, но также встречается и в новых или необновлённых приложениях.

Мне не раз приходилось сталкиваться с данной конкретной проблемой, когда я работал в техподдержке. Поскольку я отвечаю, в основном, за веб-составляющую приложений, мне такие вещи встречались только в приложениях ASP.NET. Однако, эта проблема характерна не только для ASP.NET Core и может произойти в любом приложении под .NET.

Она может возникать в .NET 6 и ниже, но чётче проявляется и лучше просматривается в .NET 7 и выше. Дело в том, что в этих версиях .NET иначе, чем прежде, обращается с блоками памяти, отводимыми под кучи для сборщиков мусора. Разница такова: в .NET 6 и ниже (а также в .NET Framework) используются сравнительно крупные сегменты, для каждой кучи — свои. А в .NET 7+ для этой цели применятся более мелкие регионы, доступные для повторного использования. Если вы хотите подробнее почитать о сегментах и регионах, посмотрите пост от Маони Стивенс, которая занимается архитектурой сборщика мусора в .NET: https://devblogs.microsoft.com/dotnet/put-a-dpad-on-that-gc/

Кроме того, по-видимому, именно такие утечки возникают только в Windows. Я прихожу к такому выводу, изучив релевантный исходный код .NET. Правда, не поленитесь пролистать эту статью даже в случае, если ваше приложение хостится на какой-нибудь другой платформе.

Недавно мне попался следующий твит от OneHappyFellow:

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

— One Happy Fellow (@onehappyfellow) 5 мая 2025

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

В прошлом году, просматривая пул-реквесты по поводу компилятора Rust, я обратил внимание на #126013. В нём к некоторым пакетам компилятора добавлялась проверка unreachable_pub. Естественно, меня это заинтересовало, так как на тот момент я о такой проверке не знал. Но, разобравшись с её описанием, я тем более удивился, так как эта проверка показалась мне абсолютным нонсенсом! Поговорив об этом с авторами пул-реквеста, я осознал, что, пожалуй, достаточно странно представляю себе, как устроена видимость в Rust. Как минимум, я воспринимал её не «так, как она была задумана».

Эта тема показалась мне достаточно интересной, чтобы раскрыть её в блоге. В этой статье я коротко объясню, как именно работает видимость в Rust, а потом опишу два достаточно разных способа её использовать. Если вы знаете, как в Rust устроена видимость, можете смело пропускать введение и переходить к главной теме. Оговорюсь, что в этом посте я просто вывалил различные мысли на данную тему, скопившиеся у меня, так что не ожидайте найти здесь каких-либо супер-откровений :).

Odin — это универсальный язык для системного программирования, придуманный Биллом Холлом aka «gingerBill». Odin задумывался как современная альтернатива C, и в нём делается акцент на простоте, производительности и удобочитаемости, но при этом не упускается контроль над низкоуровневыми деталями.

На сайте об этом языке Odin охарактеризован как «ориентированный на данные», именно поэтому в нём присутствуют, например, структуры массивов (SOA) и неявная инициализация значения в ноль. Удивительно, что, несмотря на такие приоритеты, в языке есть динамические словари и массивы, встроенные в сам язык. Притом, что памятью всё-таки приходится управлять вручную, такие встроенные вещи встречаются нечасто.

Возможно, вот те самые черты, придающие Odin собственный облик: язык задуман как эргономичный, такой, на котором удобно писать, и поэтому многое предоставляет «из коробки». Также в Odin предусмотрен «вендор», в котором содержатся привязки к разнообразным популярным библиотекам. Поэтому вкатываться в язык очень просто.

Вот вам маленькая задачка на программирование: реализуйте такой макрос, который принимает в качестве аргумента числовое выражение (числа могут быть целыми или с плавающей точкой) и:

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86.

На первый взгляд, это абсурд В сущности, так и есть. Однако есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода. Так и задумано, что писать код с очень высоким показателем IPC непросто. Следовательно, челлендж «Напиши медленный код» оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

Страшно вспомнить, сколько часов в день я проводил, работая в терминалах Unix и выполняя команды оболочки. По какой-то причине у разных людей сноровка при работе с оболочкой разительно отличается. Я знаю тех, кто даст мне в этом сто очков вперёд. В то же время, попадался мне один профессионал на зарплате, не знавший, что достаточно нажать клавишу «вверх», чтобы выяснить предыдущую команду.

Я неслучайно привёл такой пример: те команды, которые нам, как правило, приходится выполнять в оболочке, то и дело повторяются. Мне обычно доводится иметь дело с 50-100 уникальными (т.e., синтаксически неидентичными) командами оболочки в типичный рабочий день. Но среди этих команд можно выделить и крошечную подгруппу (напр., cargo test) таких, которыми я пользуюсь сотни раз в день.

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

Наверное, я очень опоздал с изучением CUDA. До недавнего времени даже не знал, что CUDA — это просто C++ с небольшими добавками. Если бы я знал, что изучение её пойдёт как по маслу, я бы столько не медлил. Но, если у вас есть багаж привычек C++, то код на CUDA у вас будет получаться низкокачественным. Поэтому расскажу вам о некоторых уроках, изученных на практике — возможно, мой опыт поможет вам ускорить код.

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

Если да – то вам просто необходимо изучить chroot. Он станет для вас настоящей палочкой-выручалочкой.

Например, мне пару недель назад удалось таким методом восстановить устройство Nanopore GridION, после того, как мне совершенно не помог официальный метод переустановки через  .iso-файл образа. Поэтому я решил задокументировать проделанные шаги.

Этот метод я нащупал только после того, как Linux более десяти лет был моей рабочей лошадкой (спасибо, Мэтт !). Поэтому у меня есть основания полагать, что этот метод очень полезен и заслуживает вашего внимания. Надеюсь, этим постом мне удастся помочь тем, кому не доставало такого рассказа.

Пишу этот текст совершенно без намерения оскорбить авторов Excel. Это фантастически успешный софт, который по праву считается золотым стандартом среди табличных редакторов. Тем не менее, в этом году Excel уже стукнуло 40. В таком почтенном возрасте его семантика всерьёз страдает из-за костылей, которые накапливались не один десяток лет, обеспечивая обратную совместимость.

Одно из самых интересных дел, которыми мне приходится заниматься на работе — это обратная разработка Excel. Я выискиваю причуды в его поведении и решаю, как поступать с ними в нашем фирменном табличном редакторе. Благодаря моему повседневному труду, наши пользователи, возможно, и не подозревают, сколько недокументированных грехов совершила Microsoft ради совместимости. Приглашаю вас одним глазком взглянуть на те ужасы, с которыми мне приходится тягаться — и тогда вы тоже станете бояться Microsoft Excel — не потому, что чего-то не знаете, а наоборот, так как знаете слишком много.

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

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

Именно такие ожидания я связывал с Next.js — опенсорсным фреймворком для веб-разработки, созданным и управляемым компанией Vercel. Vercel — это облачный провайдер, предлагающий управляемый хостинг Next.js как услугу.

Я всё тщательно проверил и убедился, что мой сайт отлично (или хотя бы вполне неплохо) работает даже без JavaScript. Но, когда JavaScript недоступен, иногда бывает немного тяжеловато скрывать вещи, скрывать которые необходимо. Всего 7 строк кода (или даже однострочника, для самых душных) достаточно, чтобы скрывать на странице элементы, требующие JavaScript. Поэтому вам не придётся краснеть перед пользователи, которые без JavaScript заметили бы, как хромает функциональность вашего сайта.

Небольшой контекст: я сейчас разрабатываю небольшую кнопочку «Share», которую можно вставлять в посты и с лёгкостью делиться ими, если мне захочется. Взгляните, как она сейчас выглядит без JavaScript:  

В течение последнего полугода команда Discord по обслуживанию медиа-инфраструктуры модернизировала конвейер обработки изображений, добавив поддержку анимированных форматов WebP и AVIF. Теперь на платформе можно делиться анимированными картинками WebP и AVIF как в виде прикреплённых файлов, так и в виде вставок. При этом все эмодзи выдаются в виде анимированных WebP — и бесшовно отображаются на любой платформе Discord. Эти изменения были реализованы для того, чтобы повысить качество анимации и воспроизведения роликов на всех платформах. При этом одновременно резко уменьшается размер файлов, и поэтому их загрузка ускоряется!

То и дело, прожигая время за чтением reddit, я натыкаюсь на очередной пост, в котором упоминается метод S3 FIFO и говорится, что он лучше LRU (вытеснение реже всего используемых значений) — потому, что даёт более низкий процент промахов кэша. Видные компании, в частности, RedPandas, Rising Wave и Cloudflare уже внедрили S3 FIFO у себя на различных мощностях, что только подогрело мой интерес к нему. Кэши — чертовски интересная тема, а по работе мне приходится сильно полагаться на работу с кэшами при обслуживании нескольких сервисов. Так что я был уверен, что рано или поздно мне потребуется протестировать S3 FIFO или, как минимум, удостовериться, что я понимаю ключевые идеи, заложенные в этой технологии.

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

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

В этом посте будет разобрано, как написать приложение на Rust с применением самого минимального API, возможности которого искусственно ограничены (например, не применяется динамическое выделение памяти). Предполагается, что читатель немного знаком с языком Rust.

Чтобы показать, что это вообще возможно, пришлось взять в качестве отправной точки (универсальный) прикладной пример

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

Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

Эта статья заставила меня поразмыслить и о других настройках git config, вероятно, не известных широкому кругу пользователей. Возможно, для этих настроек стоит задать по умолчанию иные значения, чем действуют сейчас.

В этом посте я разберу некоторые (пожалуй, малопонятные) настройки Git, которые сам активировал во всех моих проектах. Я подробно расскажу о них, поясню, как они действуют, и почему их, пожалуй, стоит выставить по умолчанию.

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