Последние посты
about:performance
14 авг., 04:41изменён
about:performance pinned «»
12 июл., 12:56
about:performance
12 июл., 12:55
about:performance
11 июл., 12:18
about:performance
5 июл., 09:05
Про бенчмаркинг, часть 3 (части 1,2)Ранее обсудили, что борьба с шумом (noise) процесс бесконечный. И если поторопиться с выводами, то в шум легко записать сам bottleneck.Важно их различать.Шум это внешний фактор (случайный или систематический), который растягивает распределение задержек системы (см. часть 2). Лечим стабилизацией и изоляцией окружения.Bottleneck фактор скорее внутренний: то, что напрямую ограничивает производительность системы. Лечим сменой архитектуры, алгоритмов, добавлением ресурсов и подобным.———Практический (анти)паттерн.Частый способ борьбы с широким распределением (да и вообще подход на все случаи жизни): перебирать доступные параметры в надежде, что какой-то сработает. Б. Грегг поэтично назвал его "Drunk Man Anti-Method".В генерации таких списков особенно хорош AI, у него богатая фантазия. Туда же и множество статей в интернетах из разрядаabout:performance
21 июн., 08:43
Продублирую свой комментарий на вопрос:Стоит задача оценки достаточности мощности оборудования по CPU. Вот уже голову сломали с методикой. Когда смотреть на среднюю, когда на p99 и p90. Пробовали коэффициент вариации(не более 5%) и что-то никуда не пришли пока…🙁Я касался этой темы в посте о среднем (https://t.me/troubleperf/110). Основная мысль в том, что начинать нужно с постановки проблемы, и держа ее в голове, искать решение (подходящую метрику).«Достаточность CPU» редко бывает самоцелью, скорее нас больше интересует справляется ли система со своей прямой обязанностью:бекап данных заданного объема должен успеть за X (throughput) обработка транзакции должна уложиться в Y (latency)Отсюда и метрики, за которыми хотим следить: для первой задачи подойдет среднее над bytes/s (не над CPU!) для второй p95/p99 над длительностью обработки.И уже через их призму, мы можем смотретьTelegramabout:performanceПро среднее У avg сложилась не лучшая репутация: * чувствителен к выбросам * скрывает хвосты * врёт на мультимодальных распределениях и т.д. И всё это правда. Но с одной оговоркой: если производительность не одно число, а распределение, то любой показатель…about:performance
18 июн., 18:22
Давайте ещё разок, на этот раз чуть сложнее: count : 44500 mean : 871 us p50 : 1081 us p90 : 1289 us p99 : 5012 us max : 11275 us Задача всё та же: по статистике определить форму распределения. Возможные варианты: A) право-скошеннаяabout:performance
18 июн., 06:01
about:performance
17 июн., 06:16
Загадка про распределение. #1 Сервис отвечает на запросы. Сняли статистику по длительности ответа: count : 47350 mean : 1021 us p50 : 160 us p90 : 3046 us p99 : 3682 us max : 37807 us Среднее 1021 мкс, а половина запросов укладываетсяabout:performance
16 июн., 04:22
1,560Открыть в Telegramabout:performance
13 июн., 07:30
Про среднееУ avg сложилась не лучшая репутация: чувствителен к выбросам скрывает хвосты врёт на мультимодальных распределениях и т.д.И всё это правда.Но с одной оговоркой: если производительность не одно число, а распределение, то любой показатель неизбежно упрощает его, а значит может как откровенно врать, так и более-менее честно описывать действительность.То есть все зависит от задачи, которую требуется решить, от контекста.———Всем нам нравятся перцентили. Но попробуйте прикинуть с их помощью throughput системы или ёмкость очереди. Вряд ли выйдет (кстати, почему?).А вот среднее тут будет к месту.И наоборот: среднее ничего не скажет про то, как себя чувствует худший по latency 1% запросов.about:performance
10 июн., 04:48
В продолжение темы про AI.Хочу порекомендовать канал моего знакомого – Azalio_techМиша – топ по Kubernetes и активно интересуется применением AI, как в работе, так и в повседневной жизни.Про это и пишет в канал: наблюдения, полезные инструменты и опыт использования.Так что, если тема близка, подписывайтесь!Хороший контент стоит того, чтобы его поддерживать.TelegramAzalio_techРазные заметки о kubernetes, linux и AI https://www.linkedin.com/in/azalio/about:performance
6 июн., 14:00
LLM про корректность, не про производительностьпока чтоНедавние исследования (раз, два) подсвечивают "особенность" современных LLM:«... модели хорошо чинят баги и закрывают задачи, но это умение не переносится на оптимизацию производительности. Современные LLM заточены под корректный код, а не под быстрый.»Причина не в том, что модели "не могут" в перформанс, а в том, как их обучают и оценивают.Основные бенчмарки (HumanEval, MBPP, SWE-bench) делают упор на корректность генерируемого кода (pass@k). Метрики эффективности (eff@k) существуют, но пока не стали стандартом.То есть "перформанс" сейчас не входит в KPI моделей.———Первая работа проверяла, насколько модели способны ускорять код: найти узкое место, внести фикс, попутно ничего не сломав.За 1.0× брали результат человека-эксперта по кодовой базе:about:performance
1 июн., 04:25изменён
Упрощенно нарежем типичную функцию на две части:1. подготовительная/служебная работа: платим каждый вызов 2. полезная работа: то, ради чего тут собралисьМы хотим, чтобы первая часть была максимально дешёвой относительно второй (кэп).А вот что менее очевидно: объём полезной работы далеко не всегда линейно влияет на длительность функции.———Наглядный пример: системный вызов sendto, для отправки UDP-датаграмм.Зависимость длительности вызова от размера payload на скрине.Интересно, что при минимальном объеме данных в 1 байт (плюс заголовки), время работы внутри sendto ~1.8мкс.Но если увеличить payload до 512 байт, длительность вырастает всего в 1.25x. И дальше с ростом, почти не меняется.(цифры на других системах могут отличаться, перепроверяйте)
about:performance
31 мая, 10:49
Чего только не придумаешь в отпусках!Например, новое название канала: about:performanceТеперь так.Channel name was changed to «about:performance»
31 мая, 10:48
about:performance
28 мая, 10:01
О бенчмаркинге, часть 2(первая часть тут)Производительности в вакууме не бываетСостояние одной и той же системы от запуска к запуску бенчмарков всегда разное. Даже если зафиксированы все статические параметры (настройки OS и рантайма, CPU affinity, etc), то температура процессоров, состояние кешей, layout кода в памяти всё равно плавают. Что уж говорить про внешне схожие окружения - там различий может быть еще больше.Следовательно результаты на выходе всегда различаются.Так какой из них нам взять за основу?———Помогает формулировка от Ben Sigelman: «Performance is a shape, not a number».Производительность это всегда распределение, а не одно конкретное число. Не существует одного единственного, правильного значения.И каждый отдельный прогон бенчмарка это просто один сэмпл из всего распределения, полученный при конкретных условиях.Telegramabout:performanceО бенчмаркинге, часть 1 Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения. По сути, это способ оценить производительность системы под нагрузкой. Брендан Грегг в своё время ввёл наглядную…about:performance
28 мая, 09:22
Походил, подумал, не нужен в канале этот ранний доступ.Добавил себе геморроя на ровном месте. Лучше откатить раньше, чем позже.Поэтому реверт — возвращаюсь к исходному формату публикаций.about:performance
27 мая, 05:45изменён
Вышла вторая часть серии про бенчмаркинг (первую ищи тут).Ее центральная мысль: performance is a shape, not a number.Каждый отдельный замер это всего лишь один сэмпл из полного распределения.И чем лучше мы это распределение понимаем, тем полнее видим картину и следовательно сможем сделать более точные выводы.В этой части: почему производительность это распределение, а не число что такое шум, откуда он берётся и каких бывает типов как бороться с каждым из них и почему борьба с ним не имеет концаПолная версия появится здесь через 7 дней вот уже совсем скоро...
about:performance
25 мая, 05:39изменён
О бенчмаркинге, часть 1Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения.По сути, это способ оценить производительность системы под нагрузкой.Брендан Грегг в своё время ввёл наглядную терминологию: Passive Benchmarking Active Benchmarking———Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься.Но это как раз тот случай, когда «просто» не значит «лучше».Проблемы таких замеров: риск измерить не то, что планировалось изначально непонятно, что именно ограничивает производительность нельзя отличить систематическое отклонение от шума (об этом позже)
