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