Высокая производительность *

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

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

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

В Сравни у нас много продуктов, включая сервисы подбора и покупки полиса ОСАГО, подбора кредита, образовательных курсов, онлайн-оформления ипотеки. Информация о пользователях хранится и обрабатывается в специальном центральном сервисе (Profile Service). На текущий момент сервис содержит миллионы объектов пользователей, а нагрузка в пиковые моменты там до 180 запросов в секунду.

Исходная реализация Profile Service была построена на микросервисах и, как казалось нам ранее, полностью покрывала наши потребности: в плане гибкости взаимодействия с продуктами и работы с существующей нагрузкой. Изменения назрели под конец прошлого года, когда продуктовые команды стали настойчиво обращаться в команду сервиса для решения срочных задач. Здесь им регулярно требовалась помощь разработчиков — и команда Profile Service около месяца занималась только обработкой продуктовых запросов.

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

Это третья и заключительная часть цикла статей по настройке памяти в PostgreSQL. Полагаю, она получилось уже не такой заумной, как предыдущие две, и представляет из себя некий сухой остаток с собирательным примером, в котором показано как выбирать параметры PostgreSQL по настройке оперативной памяти. Если же хочется погрузиться в руду, то милости просим в Часть 1 и Часть 2. Тем не менее, цепочка логических рассуждений сохранена – как делаем, зачем и почему.

Всем привет! 

Начну с предыстории.

Когда мы в Амазоне планировали переносить сервис с x86/64 на ARM, почему-то никто в нашей команде не поднял тему того, что надо уделить особое внимание работе с многопоточностью и синхронизацией, так как из-за того, что у этих двух архитектур разные модели памяти, могли случиться неожиданные проблемы.

Однако, на тот момент я тоже об этом не знал, и нам повезло, что мы изначально везде использовали модель памяти Sequential Consistency (что это – далее в статье), поэтому все прошло гладко. Теперь, зная про модели памяти и возможные последствия, боюсь представить, что было бы в противном случае.

Как родилась статья

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

Статья основана на материалах лекции Computer Science Center (CSC) с курса “Параллельные вычисления” преподавателя Калишенко Е.Л. Крайне рекомендую ознакомиться со всеми лекциями курса (более структурированного материала по теме я еще не встречал). Благо он в открытом доступе – ссылка.

Что такое барьеры памяти и зачем это все нужно?

Начнем с небольшого описания того, как устроена “условная” архитектура процессора. Почему условная? Потому что может отличаться в зависимости от конкретной реализации, но суть похожа. 

Часто в распределенных ИТ-ландшафтах компании используют несколько хранилищ данных под разные задачи. Это делает их важным компонентом любой системы Change Data Capture (CDC) — они помогают отслеживать изменения данных и связывать используемые хранилища. Но далеко не все CDC-инструменты способны ответить на актуальные запросы бизнеса.

Меня зовут Евгений Афанасьев. Я архитектор VK Tech в команде Tarantool. В этой статье я расскажу о том, с какими вызовами сталкиваются современные компании при работе с данными и как на них помогает отвечать Tarantool CDC.

Как загрузить GPU реальными инженерными вычислениями? Давайте я расскажу, как с помощью Julia наконец смог втащить высокопроизводительные вычисления в свою немудрёную инженерную работу. Это был долгий путь, но мне кажется, что Julia стала моим лучшим другом в мире GPU/HPC.

Привет! Меня зовут Михаил Мазанов, я отвечаю за технологический стек работы с медиаданными в Кинопоиске: от съёмок оригинальных проектов до доставки и просмотра видео на всех экранах. Для нашей пятой ежегодной конференции про стриминг PlayButton 2024 я готовил большой доклад про оптимизацию качества видео Кинопоиска, а для Хабра решил пересобрать его в виде статьи — для тех, кому текстовый формат предпочтительнее видео.

Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».

Привет, Хабр. Меня зовут Павел Преблагин, я работаю в команде инжиниринга производительности Positive Technologies. Мы анализируем разные продукты компании и пытаемся так или иначе оптимизировать их изнутри. Как уже можно понять, команда наша мультипроектная: у нас нет постоянной кодовой базы, кроме некоторых инструментов анализа и тестирования. Обычно коллеги из других отделов приносят нам для изучения свою, написанную преимущественно на C++, если у них есть подозрения, что что-то работает не так быстро, как должно было бы. Мы в ответ приносим им результаты замеров, патчи и рекомендации.

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

Привет, меня зовут Степан Золотухин, я разработчик в Битрикс24. Моя команда работает над такими продуктами, как Почта, Маркетинг, Структура компании, Подписание, CRM-Формы.

Мы делаем очень много клевых и интересных фич, но в этой статье я расскажу о том, как мы работаем с «деревьями» на примере нашего продукта «Структура компании».

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

В этой статье расскажу, как мы объединили несколько разных команд разработки Райффайзен Онлайн общим Observability и с помощью исключительно технических метрик отслеживаем здоровье бизнес-процессов. Как всё это помогает мгновенно находить первопричину сбоя. Как устроен OpenTelemetry и как с его помощью рассчитать доступность приложения в девятках, а также MTTR (Mean Time to Recovery).

В уже уходящем 2024 году мне удалось побывать на конференции JPoint, которая проходила в апреле. В числе прочего там активно обсуждалась тема обновления проектов на Spring Boot 3. Однако из тех, кого мне удалось послушать, и с кем пообщаться, ни у кого не было реального опыта такого обновления. Опасения в первую очередь были связаны с Hibernate 6, который сильно изменился по сравнению с предыдущей пятой версией.

Как я уже позже выяснил на собственном опыте, опасались не зря. Именно из-за изменений в поведении Hibernate мы получили аварию на проде: наша база начала грузить CPU под 100%. Это была самая серьёзная, но далеко не единственная проблема, с которой пришлось столкнуться. Далее опишу в деталях, что, как делали и какие проблемы поймали.

Привет, Хабр! Давайте продолжим изучать возможности Envoy, но уже в контексте динамической конфигурации. В первой статье мы рассматривали настройку статической конфигурации, однако она имеет свои особенности. Статическая конфигурация подходит, когда ваши upstream (серверы, к которым Envoy отправляет запросы) редко изменяются. Envoy работает как прокси, и каждый запрос проходит через него. Чтобы правильно обработать запрос, Envoy должен иметь актуальную информацию о бэкенд-серверах, такую как их IP-адреса и порты. Когда информация о бэкенде меняется, необходимо обновить конфигурацию в статическом файле и перезапустить Envoy, что не всегда удобно.

Дважды в год мир высокопроизводительных вычислений замирает в ожидании обновления TOP500 — главного индикатора технологического прогресса в области суперкомпьютеров. Это не просто список — это компас, указывающий направление развития всей компьютерной индустрии. Технологии, которые сегодня тестируются здесь, завтра придут в корпоративные дата-центры, а послезавтра — в наши рабочие станции и ноутбуки. Что же мы увидим в ноябрьском Топ-10, рассмотрим в посте ниже.

Архитектура RISC V (читается как «риск файв») существует и развивается более полутора десятилетий. Участие в развитии этой архитектуры принимают тысячи фирм по всему миру.

На очередном круглом столе российского Альянса RISC V мы — компания «Аквариус» — предложили свою идею по доработке. Выносим ее на суд сообщества.

Обычно компании‑основоположники архитектур закрывают свои системы команд (ISA — instruction set architecture — архитектура системы команд, проще — система команд) от сторонних разработчиков патентными ограничениями, а иногда и судебными преследованиями. Сами они, как правило, развивают свою архитектуру не очень охотно.

Стимулом для нововведений часто становится истечение срока лицензионной защиты. ISA дорабатывается, чтобы снова закрыть доступ со стороны к правкам или самостоятельному повторению всей архитектуры. Также толчок в этом направлении может дать требование увеличить разрядность обрабатываемых данных — со временем оно становится очевидным. Как ни странно, сюда же можно отнести и требование уменьшить разрядность. Классическим примером можно считать архитектуру MIPS. Первоначально 32-битная, в конце концов она стала 64-битной с поддержкой 16 ‑разрядной обработки данных.

Почти такой же танец мы увидели и в исполнении RISC V. Но тут есть важные особенности.

Если говорить о других архитектурах, их исходный вариант никак не подразумевал дальнейшее развитие — оно ничем не обеспечивалось. А вот RISC V разрабатывалась с учетом того, что она будет развиваться, в нее были заложены такие возможности. А главное — она изначально была открытой, то есть доступной для усовершенствования.

Клиент заказал разработку сайта.

Ожидание: все готово еще вчера.
Реальность: составление ТЗ, прототипирование, доработки, конфликты, снова доработки, и только потом результат.

Бонджорно, Хабр! Это Идар Табухов — скрам-мастер в МТС Диджитал и фанат компьютерных игр. Скоро Новый год, так что самое время подумать над подарками друзьям, близким и себе. Интересный вариант — игровая портативная консоль, чтобы было удобно играть в любом месте и любое время. Компании предлагают разные модели, о них сегодня и поговорим. И, конечно, рассказывайте в комментариях о своих вариантах.

Пул объектов (Object Pool) — это паттерн, который позволяет повторно использовать объекты вместо создания новых. Это может быть полезно в ситуациях, когда инициализация объектов затратна. Паттерн широко применяется в разработке игр и приложениях, где важно минимизировать использование памяти. В этой статье мы рассмотрим, как этот шаблон реализован в C#, и как он может улучшить производительность.