Предположим, вы пишете многопоточное приложение для Linux, которое рассчитано на длительную работу. Может — это СУБД или какой-нибудь сервер. Представим ещё, что ваша программа не рассчитана на какую-нибудь среду выполнения кода (скажем — на JVM, Go или BEAM), которая берёт на себя управление низкоуровневыми вещами. Вы сами управляете порождением потоков (thread), прибегая к системному вызову clone. Когда пишут на C — потоки создают с помощью pthread_create, а в C++ применяется std::thread. (1)

Привет! Меня зовут Brent «Brentmeister» Randall (Брент Рэндалл). Я — инженер из команды Gameplay Integrity, которая занимается игрой VALORANT. В сферу нашей ответственности входит система сборки игры, фреймворки, используемые для автоматизации различных задач, производительность игрового клиента и серверов. Именно последнему пункту этого списка и посвящена данная статья. Я поделюсь с вами историей поиска подходов, позволивших вывести производительность наших серверов на оптимальный уровень.

На самых ранних этапах разработки проекта мы уже знали о том, что VALORANT отличается весьма жёсткими требования к производительности игровых серверов. Надеюсь, мне удастся дать вам некоторое представление о том, почему это так, и о том, как были достигнуты наши амбициозные цели. В самом начале серверный кадр (server frame, цикл обработки данных на сервере) длился 50 мс. А после завершения оптимизации нам удалось сократить это время до менее чем 2 мс. Всё это сделано благодаря анализу и оптимизации кода проекта, а так же — благодаря подстройке «железа» и тюнингу ОС.

Эпоха больших языковых моделей (LLM, Large Language Model) снова и снова ставит перед нами вопрос о том, что отличает великую прозу от просто хорошей.

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

Большинство современных LLM выдаёт хорошие тексты. Даже — грамотные. Но — тексты это стандартные. Стилистически безвкусные. И что — так будет всегда? Этот вопрос меня тревожит с тех самых пор, как я начал пользоваться LLM. Они созданы из слов, и при этом не могут как следует словами пользоваться. Почему мы не способны создать ИИ, который пишет хорошие тексты?

Тут совершенно естественным образом возникает такой вопрос: можем ли мы задать какие-то (или хоть какие-нибудь) количественно измеримые, эмпирические «сигнатуры» хороших текстов? Если это возможно — значит такие вот «характеристики» можно использовать для обучения моделей, которые смогут лучше писать. Так случилось, что этот вопрос завёл меня, так сказать, в кроличью нору, породив проект, который я называю Horace.

Я выдвинул гипотезу, в соответствии с которой, приближённо говоря, волшебство текстов, написанных людьми, уместно сравнивать не с понятием «статистическое среднее», а с понятием «дисперсия». Полагаю, эту мысль нельзя назвать строгим правилом, но она, как мне кажется, ближе к истине, чем альтернативные идеи. Магия человеческих текстов заключается в осознанном, целенаправленном отступлении от ожидаемого. Речь идёт о ритме (rhythm), о темпе (pace), о музыкальности (cadence) текста.

Привет, Хабр! Недавно мы запустили Wunder RNN Challenge — соревнование по машинному обучению, где нужно предсказывать следующее состояние рынка по последовательности предыдущих состояний.

В этом посте мы расскажем, что это за состояние рынка, и в чём вообще прикол.

📅 Решения принимаются до 1 декабря
💰 Призовой фонд $13,600

Большие языковые модели (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 с поддержкой свободной многопоточности. Применялись они в реальных продакшн-системах, поддерживая процессы, которые основаны на сложных наборах зависимостей.