Большие языковые модели (LLM, Large Language Model), как подсказывает их название, часто отличаются значительными размерами и слишком велики для того, чтобы нормально работать на обычных компьютерах. Масштабы этих моделей могут измеряться миллиардами параметров. Обычно для обеспечений достойной скорости их работы необходимы GPU с серьёзными объёмами видеопамяти (VRAM).

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

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

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

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

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

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

В теории вероятностей имеется несколько известных задач, решение которых противоречит здравому смыслу. Одна из таких задач — «Парадокс сестёр». Сейчас я изложу условие задачи, дам вам возможность подумать над ответом, а потом расскажу о том, как её решать.

Я начал пользоваться платформой Linear пару месяцев назад. То, с чем я столкнулся, затянуло меня в кроличью нору деталей local-first-разработки (локально-ориентированной разработки), которые изменили мой взгляд на веб-приложения.

Можно ли применить известный трюк с операцией XOR, используемый для поиска в списках одного или двух пропущенных чисел, сделав так, чтобы он подошёл бы для поиска тысяч отсутствующих идентификаторов в таблицах, содержащих миллионы строк?

После того, как я опубликовал предыдущую статью, в которой рассказал о том, какие приёмы применяю, создавая Shell-скрипты, отличающиеся отличным UX, сообщество Hacker News поделилось со мной ценными откликами и предложениями. Я оформил то, что мне удалось узнать, в виде новой статьи, разобрав здесь ещё шесть приёмов, которые позволят всем желающим улучшить свои скрипты.

Обязательно посмотрите shell-скрипт в репозитории — он чудо как хорош. Раскрашивает выходные данные, надёжный как скала… настоящий мастер-класс по созданию shell-скриптов.

Спасибо Гуннару Морлингу за добрые слова!

В январе 2024 года меня, вместе с несколькими дюжинами других гиков, повёрнутых на производительности, что называется, «заснайпили», заинтересовав участием в конкурсе Гуннара One Billion Row Challenge (1BRC).

Гуннара, оценивающего результаты работы конкурсантов (бесплатно), очень быстро буквально завалил непрерывный поток решений. Я рискнул помочь ему автоматизировать оценку работ и написал Shell-скрипт, за что и получил от него вышеприведённый хвалебный отзыв. Он это сказал в выступлении на конференции JavaZone (# 1BRC‑Nerd Sniping the Java Community — Gunnar Morling). Посмотрите это выступление, если хотите узнать о подходах к повышению производительности кода, применённых на конкурсе.

Здесь я расскажу о 6 приёмах, которые я использовал в Shell-скрипте для конкурса. Эти приёмы позволили сделать скрипт надёжным, безопасным и приятным в использовании для Гуннара.

Компания Uber уже 8 лет применяет технологии машинного обучения (Machine Learning, ML). В 2016 году мы впервые начали использовать сложные ML-модели, основанные на правилах. Мы внедрили их в командах, которые занимались подбором водителей и пассажиров и ценообразованием. С тех пор мы многого добились. А именно, речь идёт о том, что сегодня модели глубокого обучения являются неотъемлемой частью большинства приложений, критически важных для деятельности компании. Мы, кроме того, активно исследуем возможности, предлагаемые генеративными ИИ-моделями (Artificial Intelligence, AI, искусственный интеллект). По мере того, как растут масштаб и сложность AI/ML-моделей, увеличивается и потребность в высокоэффективной инфраструктуре, которая способна достойно обеспечивать их работу. За последние несколько лет мы, руководствуясь стратегическими соображениями, внедрили целый ряд инфраструктурных решений, основанных как на CPU, так и на GPU. Эти решения ориентированы на динамическое масштабирование наших систем и на то, чтобы удовлетворять потребности всё новых и новых задач, возникающих в сфере машинного обучения. Развитие нашей инфраструктуры заключалось во внедрении уникальных конфигураций аппаратного обеспечения, в расширении программных библиотек, в интеграции различных фреймворков распределённого обучения и в непрерывном совершенствовании нашей платформы Michelangelo. Эта платформа обеспечивает полный цикл работы с моделями. Все эти постепенные улучшения происходили благодаря тем знаниям и опыту, которые мы получили в процессе работы, а так же благодаря тому, что мы, что-то меняя, постоянно сверялись с трендами индустрии и со стратегией развития Uber. В сущности, все эти улучшения нацелены на то, чтобы компания соответствовала бы постоянно меняющимся потребностям наших партнёров и пользователей.

Код AI Flame Graphs теперь открыт, этот проект поддерживает GPU Intel Battlemage. Это значит, что AI Flame Graphs теперь способен генерировать flame-графики (Flame Graph, граф пламени, диаграмма пламени), охватывающие полный стек GPU — это даёт пользователям новые аналитические данные о производительности игр. Особенно полезным AI Flame Graphs выглядит в связке с FlameScope (это — мой опенсорсный проект, созданный несколько лет назад). Вот — пример профилирования игры GZDoom. Тут показаны результаты визуализации использования CPU и GPU, проведённые с помощью FlameScope и снабжённые комментариями.

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

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

Современный видеоускоритель — это ещё и невероятно сложная система, которая постоянно становится всё сложнее. Новые возможности, вроде сеточных шейдеров (mesh shader) и графов задач (Work Graphs) хорошо описывает фраза «два шага вперёд, шаг назад». С каждой новой возможностью связана некая базовая задача, поддержка решения которой реализована не полностью.

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

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

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

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

Я решил использовать встроенный ассемблер gcc/clang и написать код, который сообщает системе: «Я могу создать 64-битное значение из 32-битного, не выполнив ни одной инструкции».

Компания Trail of Bits уже несколько лет сотрудничает с репозиторием PyPI, помогая добавлять в проект новые возможности и улучшать стандартные параметры безопасности в экосистеме управления пакетами Python.

Последнюю пару лет я переносил со службы домой и обратно «набор рабочих материалов» — видеофайлы и данные проектов, пользуясь внешним SSD-диском стандарта NVMe с интерфейсом Thunderbolt.

Но, когда я синхронизировал данные, это всегда происходило очень медленно. В обычный рабочий день я могу создать новую папку проекта, содержащую 500-1000 файлов. При этом среди них будут дюжины файлов размером 1-10 Гб.

Мой Thunderbolt-диск способен передавать данные со скоростью, значительно превышающей 5 Гб/с, а 10-гигабитное сетевое соединение, имеющееся в моём распоряжении, может выдать 1 Гб в секунду. Недавно я даже обновил диск до Thunderbolt 5, хотя его и нельзя назвать узким местом моей системы.

Я использовал команду rsync следующего вида для копирования файлов с общего сетевого ресурса, смонтированного на моём Mac, на диск, которому я дал имя Shuttle:

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

На прошлой неделе разработчики CPython выпустили CPython 3.14.0b1. А на этой неделе в Питтсбурге, штат Пенсильвания, начинается конференция PyCon 2025. Оба эти события знаменуют собой важную веху в делах, связанных с разработкой, выпуском и доведением до стабильного состояния релизов free-threaded Python (Python с поддержкой свободной многопоточности — с отключённым механизмом GIL).

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

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

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

«Мы все сделаны из звёздного вещества», — любил напоминать человечеству астроном Карл Саган. Взрывы сверхновых — акты катастрофического самоуничтожения «изношенных» звёзд определённого типа — тесно связаны с жизнью на Земле. Дело в том, что именно в них рождаются тяжёлые элементы, которые можно встретить во всей Вселенной. Большая часть железа в нашей крови, и серы в аминокислотах, возникла в звёздах, взорвавшихся миллиарды лет назад. Но обнаружена и ещё одна, совершенно неожиданная связь между сверхновыми и миром людей. Речь идёт о связи с технологиями, которые нужны для производства компьютерных микросхем, применяемых в современных смартфонах и в других электронных устройствах.

Эта связь проявилась несколько лет назад в череде бесед между мной, Джейсоном Стюартом и моим дедушкой Рудольфом Шульцем. Дедушка был страстным астрономом-любителем, который держал в прихожей, сразу у входа, большой телескоп-рефлектор, который он всегда готов был направить на небо. Когда я учился в старших классах, он подарил мне книгу Стивена Хокинга «Краткая история времени» (Bantam Books, 1988) и на всю жизнь зажёг во мне любовь к физике. Позднее астрономический взгляд на вещи моего дедушки оказался, по счастливой случайности, полезным в моей карьере, о чём я рассказал ему во время одного из наших астрономических вечеров у него дома, в предгорьях Тусона.

Настройка алиасов (alias, псевдоним команды) была одной из первых задач, которую я решал, редактируя конфигурационные файлы (dotfiles) в Unix-подобных ОС. Вот пример одного из моих очень ранних алиасов:

alias g=git

Благодаря этой конструкции я могу, когда мне это нужно, вызвать, вместо команды git, команду g. Это позволяет сэкономить немного времени при использовании тех команд, к которым я прибегаю десятки раз в день!

# Теперь эти две команды равноценны:
git status
g status

Раньше я задавал псевдонимы команд с помощью команды alias. В конце концов… я ведь создавал то, что называется «alias»!

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

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