Сэнди Петерсен, геймдизайнер и дизайнер уровней Doom и Quake:

«В связи с 30-летней годовщиной выпуска сейчас многие с теплотой вспоминают Quake, и это вполне оправдано. Quake — потрясающий проект, сочетающий в себе искусство, программирование и дизайн. Я работал над ним, и все мы выложились почти идеально. Мы создали безумный экшен с большой долей свободы, захватывающий воображение игроков. Вся команда проделала замечательную работу и качественно выполнила все задачи. Но расплата за это была печальной: мы трудились долго и упорно, и мне кажется, эта игра сломала нас морально...»

← Четвёртая и пятая части

Это самый длинный пост всей серии, потому что он посвящён главной части этого проекта — всё вращается вокруг CPU.

Почему бы просто не взять готовый CPU?

Кто-то может заявить: зачем заморачиваться проектированием собственного CPU? Есть куча маленьких хорошо задокументированных процессоров и дешёвых микроконтроллеров, способных исполнять прошивку калькулятора. Zilog Z80 не так сложно реализовать на FPGA, и я в этом уже убедился (проект A-Z80, находящийся у меня на GitHub). Подойдёт и 6502. Маленький встраиваемый RISC тоже прекрасно справится с этой работой.

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

Наш калькулятор построен на BCD (двоично-десятичном коде),в котором каждый десятичный разряд хранится в отдельном 4-битном полубайте (ниббле). Это правильный выбор для калькулятора, и он определяет всё дальнейшее. Z80 (и другие стандартные CPU) работает на уровне байтов. Для индексации регистра мантиссы из 16 нибблов с ориентированным на байты процессором пришлось бы постоянно жонглировать сдвигами, масками и двумя нибблами на байт. На каждом шаге режимы адресации вступают в конфликт со схемой данных.

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

Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.

В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.

Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.

Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!

В этой главе мы поговорим о структуре очередей для драйверов устройств.

Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.

Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.

Задача загрузчика была простой:

1. Инициализировать оборудование (UART, SPI, DDR-контроллер)

2. Загрузить ядро из флэш-памяти

3. Спарсить дерево устройств

4. Перейти ко точке входа ядра

Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

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

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

Этот вопрос изменил всё. На самом деле, идеальная точность не требуется. Если мы случайно обработаем одну страницу дважды, то впустую потратим часть пропускной способности, но ничего не поломаем. Главным ограничением была память.

В 1994 году у меня появился первый компьютер: Intel i486 DX2-66 с 4 МБ ОЗУ и жёстким диском на 512 МБ. На нём были установлены IBM OS/2 и Microsoft Windows 3.11. Следующие четыре года я апгрейдил эту машину каждые несколько месяцев, добавляя больше ОЗУ (до 16 МБ), привод CD-ROM и карту SoundBlaster. Так я научился апгрейдить эту машину, устанавливать новое ПО, а потом и писать ПО на BASIC. Но я ни разу не касался процесса запуска и тонкостей MS-DOS.

В 2026 году, 32 года спустя, я узнал из скриншотов DDX3216, что в Behringer использовался настоящий процессор 386. В моём мозгу сразу же активировались какие-то нейроны и я начал размышлять о том, можно ли запускать на этом устройстве ПО или даже полнофункциональную операционную систему. Для этого мне нужно было разобраться, как запускается система x86, когда управление перехватывает DOS и что необходимо для попадания в оболочку.

Я приступил к основанию своей второй компании в Германии в конце января. Сейчас конец июня.

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

Для создания компании я потратил более 9600 евро: чуть больше 7600 на сборы и счета плюс 2000 евро уставного капитала заморожено на счету, трогать который я не имею права. И спустя пять месяцев я могу сказать о компании только одно:

У меня так и не появилось возможности отправить собственный счёт на оплату клиенту.

Работа ведётся. Клиенты реальны. Единственное, для чего нужно государство — позволять мне без проблем брать с них оплату — это единственное, что мне по-прежнему недоступно.

Не так давно я читал о протоколе Wayland и мне врезалась в память эта фраза:

Заявленная цель Wayland — «каждый кадр идеален».

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

Эмпирическое правило таково:

Если сделать скриншот приложения в любой момент времени, должно быть понятно, что на нём происходит

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

Почему нам важен каждый кадр? Потому что это нарабатывает доверие. Пользователи не могут увидеть код, поэтому судить о качестве приложения могут судить только по UI. Если UI хорош, значит, у разработчиков было время на его совершенствование, а значит, они, вероятно, потратили сравнимое количество времени на отладку кода. Это эвристика, но вполне разумная.

В течение двух десятков лет в компании Meta* существовал уникальный высокопроизводительный отдел разработки; всё закончилось в апреле этого года. На протяжении первых двух десятков лет работы компании в ней исповедовалась культура «двигайся быстро и ломай ненужное», в начале 2020-х сменившаяся на «двигайся быстро со стабильной инфраструктурой». Знакомые мне разработчики из этой компании говорили мне, что им представляли всё необходимое для качественной работы с упором на приносимую пользу, а интересы бизнеса находили баланс с надёжной разработкой.

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

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

В 1935 году Эрвин Шрёдингер решил, что с него хватит.

За десять лет до этого смелый венский физик своим «волновым уравнением» преобразовал новую теорию квантовой механики, описав в нём то, как квантовые частицы способны вести себя подобно волнам. После этого он стал свидетелем того, как некоторые исследователи выдумывали то, что он считал смехотворной интерпретацией квантовой теории, отрицавшей реальность таких квантовых объектов, как атомы и субатомные частицы, до наблюдения за ними.

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

Приведя пример квантового поведения, влияющего на объекты, которые мы можем увидеть (и даже погладить), Шрёдингер хотел показать абсурдность того, что наблюдения способны определять реальность.

Почти сотню лет его мысленный эксперимент порождал споры о том, что же именно подразумевается под измерением или наблюдением в квантовой теории. Это бросило вызов экспериментальной физике: насколько большими мы можем делать объекты, сохраняющие любопытные квантовые свойства (не находящиеся ни в том, ни в другом состоянии)? Можно ли создать если не для кота, то хотя бы для существенного объёма неживой материи (который некоторый называют котятами Шрёдингера) такие странные квантовые «суперпозиции»?

И это не просто академический вопрос. В прошлом году Нобелевскую премию вручили исследователям, показавшим в 1980-х, что суперпозиции можно создавать в петлях сверхпроводников: подобные компоненты используются в качестве квантовых битов в квантовых компьютерах, производимых такими компаниями, как Google и IBM; эти компьютеры достигают своей огромной вычислительной мощи благодаря обработке информации, представленной в виде суперпозиции двоичных нулей и единиц.

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

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

Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.

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

Мы рассмотрим множество пограничных случаев, споткнёмся об маленькие препятствия и обнаружим, что некоторые технически корректные детали не всегда поддерживаются даже в больших системах наподобие Gmail (и, честно говоря, на то есть веские причины).

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

Мы можем легко принять, казалось бы, здравое решение, которое неожиданно вызовет проблемы. Кроме того, многоопытные разработчики (и старые системы) могут иметь ожидания, ранее бывшие корректными, но больше не работающие. Итак, без лишних предисловий, перейдём к вымыслам…

Nintendo DSi

В большинстве случаев браузер был включён в пакет системного ПО DSi (2008 год), в противном случае его можно было бесплатно установить из DSi Shop. Для браузера не требовался Memory Expansion Pak благодаря тому, что в DSi имела встроенные 16 МБ ОЗУ. Браузер сильно улучшили по сравнению с версией для DS, это урезанная версия Opera 9.50¹.

Важным аспектом стало добавление поддержки HTML canvas: на различных сайтах наподобие DSiPaint, DSiCade, DSiPlaza и Social Neko, написанных специально под браузер DSi, использовалась эта поддержка и другие веб-технологии, упрощающие интерактивные действия. Браузер поддерживал только один шрифт и три его размера, а контент преобразовывался в соответствии с этим ограничением.

Авторы обзоров того времени критиковали отсутствие поддержки Adobe Flash и воспроизведения видео, а также достаточно частые сообщения о заканчивающейся памяти, но всё равно считали браузер серьёзным шагом вперёд по сравнению с ПО для DS. Он получил единственное обновление до версии 1.4 (август 2009 года), которое немного уменьшило занимаемый в памяти размер.

Несмотря на увеличившийся размер ОЗУ, DSi не была совместима с браузером DS из-за обязательной проверки на наличие Memory Expansion Pak, который невозможно было установить DSi из-за отсутствия Slot-2.

^{1. Несмотря на некоторые утверждения, браузер работал в самой DSi, не используя прокси рендеринга Opera Mini.}

Видеоигровые консоли и веб-браузеры имеют долгую совместную историю. Ещё с самого появления World Wide Web консоли пытались выйти онлайн. Браузеры в видеоигровых консолях изначально в основном были попытками предоставить дешёвое окно в веб для обычной аудитории без технического опыта, однако со временем они становились всё более масштабными и интегральными частями систем.

В этой статье мы подробно изучим браузеры консолей, однако рассмотрим только официальные веб-браузеры. Во многие консоли можно установить браузеры через специализированные прошивки и homebrew, но они не войдут в рамки нашей статьи, как и системы без веба наподобие Satellaview, а также онлайн-сервисы, не предоставляющие браузер, например, XBAND, Sega Meganet и Sega Channel.

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

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

Поэтому неожиданно, что порт Doom так и не появился на Neo Geo. В конце концов, в Neo Geo работает тот же CPU Motorola 68000, что и в Sega Genesis с Commodore Amiga, а для обеих этих платформ, несмотря на их слабые характеристики, есть версии Doom. Для Neo Geo же её найти невозможно. Многие разработчики, работавшие с Neo Geo, часто говорили, что на ней практически невозможно запустить Doom. Но почему? У этой консоли есть видеодисплей, CPU, ОЗУ и всё необходимое для запуска видеоигр. Давайте же разберёмся.

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.

В новом релизе Pizza Legacy v0.1.0 появилась возможность выиграть игру, как в оригинале.

Когда я играл в Pizza Tycoon (1994 год) в детстве, то не особо задавался вопросом, как победить. Мне просто нравилось открывать рестораны и придумывать пиццы, а также приторговывать оружием для финансирования роста моей империи пиццы. Но выигрыш? Я никогда до него не доходил и, вероятно, даже не задумывался о нём.

Когда я принялся за проект воссоздания этой игры, то начал изучать файлы данных Pizza Tycoon, обнаружив графический файл ENDE.VGA и текстовый файл ENDE.E, сообщающий нам, что происходит в случае выигрыша:

Первая строка ENDE.E:

Вы достигли немыслимого! Вы — король всего западного рынка фастфуда! Вы — тот самый, МАГНАТ ПИЦЦЫ.

Это даёт нам понять, что игру как-то можно выиграть, но не как именно.

Я просто забыл об этом вопросе, ведь мне предстояло реализовать столь многое до того, прежде чем задумываться о победе игрока, но однажды наткнулся на пост «Я "выиграл" в Pizza Tycoon? (Как это произошло?)». После нахождения этого поста мне стало любопытно, но не настолько любопытно, чтобы заниматься расследованием, поэтому я поискал условия конца игры в ассемблерном коде и попросил Claude проанализировать их. Он сказал следующее:

end_of_week_processing раз в неделю проверяет, есть ли у текущего игрока >= доля рынка 5% во ВСЕХ 10 городах.

Это соответствует моим представлениям: логично с точки зрения геймплея и текста, найденного в ENDE.E. Однако это не соответствовало написанному пользователем Reddit: он утверждал, что у него были рестораны только в Париже и Берлине; возможно, он опустил какие-то подробности или у него просто был повреждённый файл сохранения? Я написал ему, но не получил ответа...

Вы почти наверняка уже встречались с Conventional Commits. Их уродливые лица можно заметить в changelog опенсорсного проекта, которым вы пользовались. Возможно, это был обязательный формат коммитов опенсорсного проекта, в котором вы были контрибьютором. Многие люди безгранично им верят. Я им безгранично не верю.

Хоть он и применяется в большом количестве разных популярных опенсорсных проектов, Conventional Commits — это глубоко порочный стандарт, стимулирующий фокусироваться не на том и не оправдывающий свои ожидания.

В 2004 году я слишком много играл в RuneScape на модеме 56k, который разрывал соединение, когда мама поднимала трубку. 3D-мир, на сервере которого могло быть до тысячи игроков и десятки на экране одновременно... И всё это в браузере со скоростью 5 килобайт в секунду. Каким-то образом всё это работало. Давайте пошагово разберёмся, как же именно.

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

Методология

Подробности, приведённые в этом посте, взяты и декомпилированного клиента RuneScape 2 от 2004 года. Фрагменты кода — это приблизительная трансляция этого декомпилированного кода, местами подчищенная для удобочитаемости, но с сохранением логики.

Базовые принципы различаются между разными версиями, но большинство из них остаётся неизменным от самой RuneScape Classic (2001 год) до современной RuneScape 3 и, разумеется, до Old School RuneScape.

Если вы играли в RuneScape в начале 2000-х и у вас всё ещё есть жёсткие диски из той эпохи, то советую заглянуть в RuneScape Archive Project. Его авторы проделали отличную работу по каталогизации исторических версий RuneScape, которые в противном случае были бы утеряны, и им важен каждый вклад.

Примерно в 400 километрах над поверхностью Земли летает Международная космическая станция, окружённая своеобразной космической погодой.

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

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