Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

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

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

Доступ к файлам через отображение-в-память (mmap) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает.

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

Покуда разработчики по прежнему пытаются использовать mmap в новых СУБД, мы написали эту статью, чтобы предупредить остальных, что mmap это не подходящая замена привычному буферу. Далее мы обсудим основные недостатки mmap, а также покажем явные ограничения производительности, которые мы обнаружили в наших экспериментах. На основании этих находок мы поделимся рецептами, когда разработчикам СУБД следует избегать mmap для реализации файлового ввода/вывода.

Добрый день, дорогие читатели Хабра!

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

Революция в области искусственного интеллекта переформатирует все отрасли нашей жизни, с одной стороны обещая невероятные инновации, а с другой ー сталкивая нас с новыми вызовами. В безумном потоке изменений эффективная обработка данных становится приоритетом для приложений, на основе больших языковых моделей, генеративного ИИ и семантического поиска. В основе этих технологий лежат векторные представления (embeddings, дальше будем называть их Эмбеддинги), сложные представления данных, пронизанные критической семантической информацией.

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

В далёком 2002-ом комитет по стандартизации C++ посетил пропозал, предлагавший ввести шаблонный класс, некий обобщенный «указатель на функцию», способный работать как с простыми указателями на функции, указателями на методы классов, так и с произвольными функциональными объектами [1].

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

Кто же знал, что его окажется недостаточно, а один из его юзкейсов — вовсе не его юзкейс?

C++ последний десяток с лишним лет стремительно развивается. Тем не менее в наших кодовых базах все еще присутствуют многочисленные helper-файлы и классы, которые помогают восполнить пробелы в стандартной библиотеке языка. Как же так вышло, что там в этих ваших helper-файлах, и когда это закончится?

Что такое память и какие они бывают в Linux? Как с ней взаимодействовать? Каковы её особенности?

Как реализована память в ядре Linux? Как с ней работать?

Что такое кластеры, откуда в ядре Linux грязные и чистые страницы - читайте в этой статье!

Сравнительно недавно в stdlib плюсов появилось форматирование строк «как в питоне», а точнее, как в библиотеке fmt. И я, как смелый и отчаянный, решил этим воспользоваться. Возможно, аксакалы и настоящие разработчики скажут, что я всё делаю не так, и вообще не то, но я буду рад такой критике, если она поможет легче жить ;)

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

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

Технологическая платформа 1С:Предприятие – это большой программный продукт (только на С++ - более 10 миллионов строк кода, а есть ещё Java и JavaScript). Подробнее про устройство платформы можно прочитать тут.

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

О том, какие инструменты мы пробовали использовать, почему они нам не подошли и как мы в итоге решили задачу анализа использования памяти – под катом.

В 2016 году меня пригласили помочь с разработкой экшн-очков "ORBI", это такие водонепроницаемые очки с несколькими камерами, которые могут стримить 360видео сразу на смартфон, ну а если с ними поплавать, тоже ничего сломаться не должно. (https://www.indiegogo.com/projects/orbi-prime-the-first-360-video-recording-eyewear#/). Собственно моей задачей было написать алгоритм склейки видео потока с четырех камер в одно большое 360* видео, на тот момент задача не очень сложная, но требующая немного специфичных знаний opencv и окружения. Но статья не об этом, потому что теперь это все оберегаемое IP, а про то как мы легальными и не очень средствами языка С++ писали тестовое окружение для используемых классов и соответственно алгоритмов. Да вы скажете, что там такого - сделал гетеры да тестируй себе на здоровье. А если гетера нет или переменная класса спрятана в private секцию и возможность изменить хедер отсутствует. Или вендор либы забыл положить хедеры, и прислал только скан исходников (китайские друзья они такие), а тестировать это надо? Помножив желание написать тесты на утренний кофф и приплюсовав дикий энтузиазм, можно получить очень много ошибок компиляции интересного опыта. Как говорил один мой знакомый лид: "Нет такого кода, который мы не сможем порефакторить, особенно за утренним кофф".

1. Компиляторы умны! Они автоматически векторизуют весь код!
2. Компиляторы тупы, автоматическая векторизация хрупка, ее очень легко нарушить несвязанными изменениями в коде. Всегда лучше вручную написать конкретные инструкции SIMD.
3. Написать SIMD вручную действительно сложно — для каждой архитектуры процессора придется писать разный код. Кроме того, вы, вероятно, понимаете, что компилятор напишет на ассемблере скалярный код лучше вас. Что заставляет вас думать, что вы превзойдете компилятор в SIMD, где еще больше странных инструкций и запретов? Компиляторы — это инструменты. Они могут надежно векторизовать код, если он написан в форме, поддающейся векторизации.

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

В этом году на C++ Russia я рассказывал про API дизайн. Эта статья — пересказ и переосмысление моего доклада.

То, что я здесь расскажу, основано на моем личном опыте — про API дизайн я думаю уже лет 15, с того момента как в 2008м начал читать ревью библиотек на входе в boost (кстати, всем рекомендую).

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

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

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

С прошлой осени Нивен проходит стажировку, разрабатывая новую модель псевдонимов для Rust: древовидные заимствования (tree borrows). Секундочку, уже слышу, как вы вопрошаете: а разве в Rust ещё нет своей псевдонимной модели? Разве вы, автор, не рассказываете повсюду о «стековых заимствованиях»? Действительно, так и есть, но стековые заимствования — всего лишь один из возможных вариантов реализации для модели псевдонимов, и с этим вариантом есть свои проблемы. Древовидные заимствования призваны учесть опыт, усвоенный при работе со стековыми заимствованиями, и построить новую модель, не такую проблемную. Также при её проектировании принимаются немного иные решения, с учётом некоторых нужных компромиссов и той тонкой настройки, которая, возможно, должна быть привнесена в эти модели, и только потом настанет время решать, какую же из этих моделей принять в Rust в качестве официальной.

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

Для краткости я буду иногда называть стековые заимствования «СЗ», а древовидные заимствования — «ДЗ».

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

Наверное, многие слышали, что неопределённое поведение (undefined behavior, UB) -- постоянный источник разнообразных багов, иногда очень забавных, иногда довольно жутких. Тема также неоднократно освещалась и на Хабре, навскидку раз, два, три (и даже целый тег есть). Однако чаще всего статьи по данной теме посвящены тому, как можно отстрелить себе ногу, голову или случайно сжечь свой жёсткий диск, исполнив какой-нибудь опасный код. Я же намерен сделать акцент на том, зачем авторы языков программирования надобавляли всей этой красоты, и как оптимизатор может её эксплуатировать. Всё будет проиллюстрировано наглядными примерами из LLVM и присыпано байками из собственного опыта, так что наливайте себе чай, располагайтесь поудобнее, и погнали.