Мысли в слух

Я опять давно ничего не писал, поэтому вот вам поток сознания.

Попробовал тут этот ваш ChatGPT для работы. Что ж, очень неплохо пишет sql запросы, помогает в пятницу вечером провалидировать рефакторинг, если вы вдруг почему-то не написали тесты, которых по какой-то неведомой причине не было и до вашего вмешательства.
Но чтобы прям вот тикеты решать... По-моему пока ИИ до этого не дошёл. Всё-таки самая сложная часть по-прежнему: перевести из "хочу Х" в "надо переделать Y, чтобы он был Z", с учётом кучи ограничений: не уронить надёжность, перфоманс, читаемость, поддерживаемость; сделать легко отключаемым по рубильнику, легко расширяемым (но только там, где надо!), обратно совместимым; уложиться в код стиль, дизайн стиль, архитектуру приложения. Но это ладно, могу в теории представить огромный сложный промпт с этим всем. А вот сказать, что как просили, сделать нельзя, зато можно вот так и так; согласовать такое; синхронизироваться с соседями по api и срокам разработки; синхронизировать выкатки, найти способ проверить в условиях ограниченных прав доступа и неработающих кусков тестового окружения; попинать того чувака, который всё ещё не ответил, эскалировать в его руководителя — это всё че-то пока кажется сложным.
Особо умные уже подумали: так зачем это все нужно, если можно просто убрать людей из цепочки? А вот людей сложно убрать. Кто должен писать промпты, кто-то должен валидировать выхлоп. Целиком большую задачу LLM пока не может прожевать, по моему опыту (да и проверить никто не сможет), а если разбить на куски, то нужна синхронизация, а учитывая то, как часто модели выдумывают, ошибаются и откровенно врут, я не знаю, как они будут договариваться, ведь у них пока что garbage in -> garbage out, булшит фильтра в голове, как у человека, у них пока нет.

Ну или я не прав, переубедите в комментариях.

Для тех, кто приходит за чем-то полезным, у меня есть заготовка
Шикарное видео про феминитивы, с позицией, которую я разделяю
Наконец-то всё разъяснили настоящие филологи, а не троечник (ладно, у меня был хор по лингвистике, но откровенно слабенький)
https://youtu.be/7eC2GNCVDH8

Снова про ретроспективы

Основная мысль: нужно регулярно менять формат.

Подробнее. Я уже писал про наши ретро, ориентированные на каждого сотрудника в отдельности. Мы там крутили формулировки, фреймили, это помогло на время. Но дальше мы просто изменили формат радикально и стали проводить ретро в разрезе команды.
Раньше вопросы были про "что помешало [тебе] успеть", "что могло бы помочь [тебе]", "что нового узнал [ты] “. Хотя черно указания числа в вопросах нет, они фреймятся в юнит, в тебя.
Теперь вопросы стали про "что нам прекратить делать", "что начать", "что продолжить". Переключение сразу вытащило на свет кучу топиков. Сразу стало что обсудить.

Недавно я наконец почувствовал, что у нас начинается фаза storming. Есть мнение, что модель Такмана бесполезна, но я пока не уверен в этом. Так вот, мы поймали, как мне кажется, идеальный момент для ретроспективы в формате that guy, this guy. Обозначили границы, дали анонимную обратную связь друг другу, кое-где это помогло разанонимизироваться, потому что договорились и "помирились". Срезали сильно демотивирующие моменты, вызванные банально разным пониманием.
Команда очень довольна новым форматом. Опять 😊

И вот знаете, я недавно очень кстати поймал пост про ретро в канале Нестыдная фасилитация, там тоже рекомендуется регулярно менять форматы ретро. А кроме того, в посте есть ещё много форматов, которые мы ещё не пробовали. Кораблик точно будем пробовать. Но потом.

Весна

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

Но эта весна была другой. Я с удивлением обнаружил, что мне понравилось. В феврале в Белграде было серо и уныло. И много собачьих какашек на улице (как весной в России, только хуже!).
Но вот к середине марта/апрелю стало замечательно. Во-первых, солнце. Очень тепло. Во-вторых, сразу всё цветёт, всё зелёное, фиолетовое, красное, синее, розовое — очки красиво. Приятно погулять (чего не скажешь о привычной мне весне).

Теперь я видел красивую и приятную весну. Мне понравилось. Делаю вывод, что мне надо жить где-то не в Москве всё-таки.

Про результаты некоторых моих менеджерских потуг

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

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

Любопытную идею мне подкинул мой товарищ, один из С- в райфе (там их много, не возбуждаетесь). Можно просто включить зум и скинуть в чат команды — заходите, кто хочет поработать вместе. С одним из сотрудников совершенно случайно получилось такое попробовать несколько раз. Опять же, субъективно очень продуктивно: тут тебе и резиновая уточка, и умный собеседник, и обучение друг у друга, и тимбилдинг со смехуёчками. Рекомендую, короче. Но сложно, если у вас всё в митингах, да.

Кстати, про bus factor. Мы свою единичку пробили (ушёл от нас старожил). Но на удивление спокойно прошло. Мы сильно потеряли в производительности, как команда, но сакральные знания нас почти не тормозят. Здесь, конечно, заслуга и всех доков, и борьбы за оформление тикетов, но бо‌льшую часть лично я атрибутирую к парному программированию.

ДПДГ

Я как-то незаслуженно мимолётно упомянул об этом методе в посте про то, как я чуть не умер. Исправляю это недоразумение.

Метод позволяет справиться с ПТСР, некоторыми паническими атаками и некоторыми страхами. Я пробовал использовать только при втором.

Десенсибилизация и переработка движением глаз — это один из немногих доказано работающих (если ссылки на статьи не сгенерировала нейросеть, конечно) методов. В 2019 году в Nature даже публиковали статью, описывающую механизм работы этого метода, но я не читал.

Вообще рекомендуется делать практику с терапевтом. И практика эта в целом труднее, чем кажется. Но можно делать и самому.

В чём суть?
Нужно сконцентрироваться на травмирующем воспоминании (вспомнить и сидеть переживать его заново). Одновременно с этим надо медленно водить глазами. Можно влево-вправо, можно вверх-вниз, можно описывать окружность, бесконечность, геометрические фигуры. Я смотрю вот это видео и слежу за шариком.
Полезно фиксировать уровень тревоги во время воспоминания, по шкале от 0 до 10. Прекращать можно, когда уровень тревоги упал до 0-1. Это обычно несколько минут (я в 10 укладываюсь всегда). Всё. Вот так просто.

Википедия пишет, что три сеанса обычно хватает для проработки события уровня автомобильной аварии. Мне один сеанс помог с эпизодом гипертонического криза. Два сеанса с ТЭЛА и всей реанимацией. *У меня были панические атаки, особенно жесткая была в аппарате МРТ. Что любопытно, окружающие никогда не понимают, что я в ужасе.

А узнал я об этом методе от психологов, которых привлекал Райф (они были профессионалы по ПТСР), когда ковид согнал нас всех на удалёнку. Видать, с таким стрессом тоже помогает справиться.

Очень интересная небольшая серия постов в канале у Бориса. Речь о распределениях экстремальных величин (максимумов и минимумов). Идеи из этой области иногда применяют в оценках realized волатильности, но контекстов множество. Борис как раз рассматривает максимальную продолжительность жизни человека.
https://t.iss.one/BorisBurkov/686

Над чем я сейчас работаю?

Давайте расскажу, чем я занят на работе, а то всё опционы, опционы, у нас тут есть другой финтех!

Сейчас у меня две подгруппы: разработка платежного шлюза и разработка инфраструктуры безналичных платежей.

Платежный шлюз или PSP (payment system provider).
Несколько наших ребят интегрированы в большую и весёлую команду во главе с Антоном Курандой, которая делает платёжное сердце компании. Архитектура системы обкатана многократно и является эволюцией первого в мире опен сорс процессинга. Разрабатываем всё на golang, с использованием опен сорс базы данных YDB. За последние несколько месяцев мы уже увидели превосходство нового решения: тут и рост конверсии, и улучшение таймингов, и колоссальный рост скорости разработки. Проект перешел из экспериментальной фазы в целевое решение. Но работы ещё очень много! Здесь и многочисленные интеграции с процессингами, и интеграция новых методов оплат, и, конечно, развитие ядра системы.

Инфраструктура безналичных платежей
Здесь у нас экосистема сервисов, которые предоставляют упрощенный API для проведения платежей и дополнительные околоплатежные функции. Примерно половина усилий команды сосредоточена на разработке сервиса на python3. Он получает на вход счет, какой вы обычно получаете в ресторане, и желаемый способ оплаты (карта, СБП, ApplePay и т.п.). А дальше сервис сам понимает, сколько уже списано, сколько необходимо списать (или вернуть) и генерирует необходимые команды к процессингу PSP (про который написано выше). По дороге, можно воспользоваться функционалом по интеграции с антифродом, долгами и биллингом.
Ещё примерно половина усилий уходит на сервисы, написанные на C++ с использованием опен сорс фреймворка userver. Тут у нас сервис управления долгами, кэш методов оплат (это список привязанных карт и других доступных в регионе методов оплат), интегрированный в антифрод систему продуктов. Самый нагруженный сервис в этом сегменте это, пожалуй, кошелек баллов Плюса (ещё бы, баланс светится чуть ли не на каждой странице). Но самая активная разработка в данный момент сосредоточена в сервисе чеков. Это "невозможный" сервис, нацеленный на работу со всеми нашими сервисами во всех странах, позволяющий при том ограничивать влияние разных бизнесов на доступность друг друга.
Ближайшие цели направлены на создание единой точки входа для всех функций экосистемы. Будет еще удобнее! (и мы тоже начали внедрять golang)

А ещё мы нанимаем в обе подгруппы!
Податься можно на эту вакансию. Приходите, буду рад 🤗

Я не вижу ваших репостов! Поднимите ваши репосты выше! Давайте, давайте, оба ваших репоста!


Ладно, если серьёзно, покидайте, пожалуйста, друзьям go-шникам, плюсовикам и питонистам. Мы учим полиглотству. И космополитии немножко (международные офисы).

Как считать железо

У меня в очередной раз наступила пора подсчёта железа (пока я писал пост, она уже закончилась, но да ладно). Нужно прикинуть, сколько процессоров, памяти, дисков и сети понадобится сервисам и базам данных, за которые я отвечаю. Навык считать железо полезный, тем более требуется на собеседованиях продвинутого уровня. Решил вам поведать сие "тайное" знание.

Подготовка
Прежде, чем считать хоть что-то, нужно разработать API и подсчитать примерно количество запросов в это API (в запросах в секунду aka rps). Реализация не обязательна, но интерфейс — да. Нужно знать, какие будут точки входа в сервис, какие и какого размера данные они будут получать на вход и отдавать на выход.

Теперь думаем, сколько у нас примерно пользователей в день. Это примерно как считать количество настройщиков пианино в Чикаго. Думаем, сколько времени в день в среднем они будут пользоваться нашим сервисом. Из этих данных можно понять среднюю нагрузку (rps). Дальше правило большого пальца: в пиковый час будет нагрузка х2 от средней (или х2.5 по Бунину). Вы великолепны, у вас есть максимальный ожидаемый rps.

CPU
Начнём с самого сложного. И уже тут нужно примерно понимать, что будет в реализации: несколько random access в память или сплошные кэш хиты (походы по сети/в бд/на HDD или SSD считать нужно, как сисколы, потому что процессор вряд ли будет простаивать и ждать, пока ему ответят с внешних устройств). Очень примерно, очень грубо. Неправильно: 3 похода в память + чтение 137КБ с HDD. Правильно: ну там несколько сотен случайных походов в память, давай примерно 50мкс скажем.
Для каждой точки входа нужно понять, за сколько времени в среднем она будет отрабатывать.
Следим за руками: если наша функция отрабатывает в среднем за 10мс, то одно ядро за одну секунду (1000мс) может обработать максимум 100 запросов.
Теперь из подготовленных данных смотрим, сколько мы ожидаем rps в пиковой загрузке, делим в данном случае на 100 и получаем количество ядер. Ура!

RAM
Для баз данных или какого-нибудь машинного обучения стоит посмотреть на примерный размер юнита (датасет или средняя запись в базе) и умножить его на количество таких объектов. Потом надо заложить запаса на индексы, фрагментацию, кеши, копирования для промежуточной обработки, бэкапы. Здесь всё сильно зависит от вендора и реализации.
Если у вас не планируется in-memory кешей, масштабной мемоизации или каких-то особенных структур данных, то рост будет чаще всего суб-линейным. В типичном веб-сервисе данные очень активно переиспользуются между запросами, а потому не растут линейно с ростом rps. Довольно понятной, но грубой оценкой снизу можно считать rps*размер входящего сообщения (его надо десериализовать).
Но единственным более или менее надежным способом здесь является запуск приложения и замер (ну потому что очень уж много способов память отжать: mmap, IPC, частая аллокация и т.д.). И не забыть про RAM под нужды ОС!
Если вы знаете способ лучше — жду вас в комментариях! Я не нашёл.

Продолжаем считать железки. Теперь к переферии.

NETWORK
Тут всё несложно. У нас уже есть rps, размеры входящих и исходящих данных. Обычно, всякая мета типа хедеров сетевых протоколов пренебрежимо мала по сравнению с данными, поэтому можно дополнительно об этом не думать. Умножаем rps на размеры входящего и исходящего сообщений, получаем upload/download объёмы трафика. Дальше смотрим в таблицу красных резиновых мячей пропускных способностей сетевых карт и интерфейсов. Теперь мы можем понять, сколько нам нужно машин и с какими интерфейсами (10Gb Ethernet или 100Gb Ethernet или что-то ещё).

STORAGE
Если это не база данных или что-то подобное, то чаще всего здесь у нас будут только ОС, бинари приложения и логи. Зная rps и прикидывая, сколько примерно будем писать догов на один запрос, мы можем понять рейт записи логов (сколько байт в секунду). Тут можно уже выбрать железо (конкретные характеристики и количество), но обычно хватает самых простых конфигураций.
Дальше смотрим, как часто будем ротировать логи, понимаем, сколько максимально места нужно под это. Вот вам и число — объём диска. Если у вас там ещё всякие raid массивы, то нужно домножить на соответствующий мультипликатор.

А если база данных? То, во-первых, можно посмотреть в интернете, что там в вашей версии БД требуется, желательно и т.д. Базово вы отталкиваетесь от объёмов данных, которые планируете хранить, но нужно иметь в виду, что скорее всего вы захотите всякие индексы, а данные будут фрагментироваться — это всё тоже место, но зависит от конкретной базы.

Основная задача руководителя

Давайте так: как меряют успехи руководителя? По успехам его команды. Что считать успехом команды, какой там чей вклад — вопрос отдельный. Но понятно, что чем больше и качественнее сделано в заданный период времени — тем лучше.

Что же в таком случае нужно делать руководителю, чтобы было хорошо? Нужно делать так, чтобы за единицу времени делалось больше работы.
Как этого добиваться? Здесь есть две основные стратегии.

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

Стратегия номер два
Как перфоманс инженер может увеличить утилизацию устройств процессора, так и руководитель может оптимизировать рабочее время своих подчинённых. Если сотрудник простаивает — это плохо. Если сотрудник тратит много времени на рутину, которую можно было бы автоматизировать/ускорить/передать — есть куда расти.

Теперь к причинам простоя. Про процессор можете в книжках почитать, там в основном виноваты несвоевременные походы в память (то есть плохо спланированные запросы к памяти за данными и кодом: там не запрефетчил вовремя, тут бранч неверно предсказал). А вот у людей простой чаще всего связан с плохим планированием задач.

Какие-то примеры:
- у сотрудника только одна задача, он её сделал и ждёт новую
- у сотрудника задачи зависят друг от друга и их можно делать только последовательно, а текущая застряла (ждём кого-то или чего-то: ревью, ответов заказчика, компиляции и т.п.)
- реализовался риск, который не предусмотрел руководитель/менеджер, сотрудник не знает, что делать и ждёт реакции руководителя/менеджера
- сотрудник закопался с головой, заблудился в задаче, и никто не приходит его спасти, узнать как дела

Добавим сюда ещё стандартные замедляторы:
- переключения контекста от задачи к задаче
- потеря контекста из-за встреч, обеда, выходных, вопросов коллег
- откладывание и прокрастинация из-за непонятно поставленной задачи

И ещё куча разных факторов, которые тимлиды и руководители более высоких уровней постоянно мусолят на конференциях и в чатах.

По-существу, большая часть всех этих элементов включается в ёмкое понятие: планирование.

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

Поэтому основная задача руководителя: иметь план. Для команды и для себя. И чем дальше вперёд этот план есть, тем проще работать, проще что-то в нём менять, проще управлять рисками.

Алгоритмы мои, алгоритмики

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

Тем не менее! Скрести вилкой медленный код приходилось много, а с завистью читать о том, как скребут другие, ещё больше (у них, небось, тоже по полторы реальные истории, но всё равно завидно).

Так вот, я же тут погружаюсь в С++. Недавно прочитал супер интересную статью про бинарный поиск, решил с вами поделиться.

Какие проблемы у наивного бинарного поиска? Плохой бранч предикшен (потому что на каждом бранче вероятность угадать 50%) и плохой паттерн использования памяти (потому что опять же невозможно спрогнозировать, какую линию нужно префетчить).

Какие есть улучшения? Самое известное — galloping binary search. Это гибрид линейного с бинарным. Мы топаем вперёд по степеням двойки, пока не перепрыгнем, а там уже линейный. Здесь всего один бранч миспредикшен и довольно неплохой префетч.

Что ещё? Ещё довольно популярное решение — B-tree. Это дерево поиска, у которого не два дочерних узла, а k. Можно подобрать k таким, чтобы полностью его выбирать, например, с одного блока HDD или, что для нас сейчас интереснее, чтобы k полностью занимал кеш-линию. Здесь, кажется, что с бранчами не радужно: ведь мы снова в ситуации 50/50. К тому же на каждой итерации (в каждом узле) добавляется подпроцедура поиска внутри узла. Но зато количество кеш-промахов минимальное!

Однако, вот в этой статье от то ли 2015, то ли 2017 года авторы нашли решение ещё лучше.

Многие знают, что бинарная куча очень хорошо ложится в массив. Причём так, что для каждого элемента, находящегося по индексу j, можно найти его потомков по индексам 2*j и 2*j+1.
Но мало кто знает, что можно точно так же уложить и бинарное дерево поиска!
Вот так можно сложить отсортированный массив чисел от 1 до 7:
4261357

Такая укладка носит имя Eytzinger, в честь изобретателя.
Теперь следите за руками. Очень хитрый хак. Мы топаем по индексам (2*j, если число меньше либо равно искомого; 2*j+1 в противном случае), пока не вылезем за границы массива. Так как все походы в левое поддерево — удвоения индекса, то по сути весь путь зашифрован в двоичном представлении получившегося индекса. Поэтому, нам нужно отрезать все последние походы в правое поддерево и мы получим искомый индекс. Это всё делается битовыми операциями. Более того, можно совсем избавиться от бранчей, если скастить условие к int:

while (j <= n)
    j = 2 * j + (a[j] < x);

Скорее всего, нифига не понятно написал, поэтому любопытным предлагаю подсмотреть здесь. Там краткая выжимка конкретного алгоритма.

Почему хорошо работает? Потому что мы всё время движемся в одну сторону по массиву, хороший бранч предикшен (просто цикл while, причем еще и условие хорошее) и очень понятный паттерн префетча. Настолько понятный, что можно префетчить сразу много кэшлиний. И в этом ключ! Несмотря на то, что у B-tree количество кэш промахов меньше, для него мы должны префетчить линии последовательно, сложно угадать, какая будет следующая. Для укладки Eytzinger же мы можем не ждать, пока получим следующую линию, а тащить их в кэши сразу пачками. Таким образом B-tree ограничено латенси доступа в память, а укладка Eytzinger — фрупутом (простите).

Любопытное наблюдение. B-tree это алгоритм cache-aware, то есть требующий знания о размере кэш линии. А вот Eytzinger binary search как-будто бы cache-oblivious, то есть он учитывает, что кэши существуют, но ему не требуется знание об их размерах. ПЕРЕНОСИМОСТЬ.
Нахожу интересным то, что в данном случае дополнительная информация не помогает разогнать алгоритм.

Пятничного негатива минутка

Посмотрел я тут выпук(sic!) книжного клуба. Это шок контент для меня. Я даже и представить себе не мог, что можно _так_ прочесть биографию Фейнмана.
Книга буквально вся состоит из самоиронии. Читая её, понимаешь, что Нобелевские лауреаты тоже люди. Со своими странностями, глупыми поступками и ошибками.
Комики же почему-то решили, что
- это автобиография (да, там на обложке написано, что автор Фейнман, но по факту это не так, эта книга основана на рассказах Фейнмана, но это не автобиография)
- Фейнман постоянно рассказывает, какой он крутой (смотрит на взрыв атомной бомбы через стекло)
- Фейнман хвастается мудацкими и глупыми поступками (чаевые под окном воды, взломы сейфов)
- у Фейнмана нет друзей (про них якобы нет упоминаний)
- главное (и, видимо, единственное) достижение Фейнмана — создание атомной бомбы (любой физик знает, что это даже не близко к правде, его вклад в бомбу не такой большой, как нескольких других, более старших коллег)
- что свои причуды Фейнман принимает, как проблемы окружающих (я не понимаю, чем надо было читать, чтобы это так увидеть)

Короче, я прям хорошо отношусь к тому, что делают Квашонкин и Ловкачёв, в частности к книжному клубу. Но это просто какая-то феерия.

Короче, ставьте на мьют 😁, попробую писать сюда не такие большие стены текста, зато почаще.

Новый набор в ЦМФ

Уже идёт набор на осенний семестр центра математических финансов на программу количественного анализа. В этот раз произошли несколько серьезных изменений.
Во-первых, в этот раз обучение будет проходить на английском языке.
Во-вторых, группы будут международными, уже есть апликанты из-за пределов СНГ.
В-третьих, отбор в этот раз значительно строже, чем был в предыдущие годы. Там уже надо торговую стратегию запилить.
Изменится также и проектная работа. Вместо кучи проектов на миллион тем теперь будут: один проект HFT, один проект на medium/long term стратегии и один проект на выбор.

Фокус этого потока — трудоустройство квантом в серьезные зарубежные трейдинговые компании. Это довольно сложная задача, а значит и цель подготовить тех, кто способен пробиться — амбициозная.
Если вам интересно поучаствовать в организации, преподавании или иным образом помочь ЦМФ, то для вас тоже новость: идёт набор в команду ЦМФ. Увидимся :)

Недавно дочитал очень крутую книгу про перфоманс

Чтобы не томить, вот книжка. Денис Бахвалов, @Performance Analysis and Tuning on Modern CPUs". Серёга Мельников её рекомендовал еще году в 2019, но я тогда не увидел смысла джависту в таком материале, а зря! Книга кроме рецептов даёт методологии (некоторые для меня оказались новыми) и хорошо объясняет перфоманс CPU. Фронтенд и бэкенд процессора, бранч миспредикты, спекулятивные исполнения, анролы циклов и вот это вот всё, о чём все вокруг говорят. Но никто толком не понимает, почему это должно работать.
К книге есть курс на гитхабе. Который довольно сложно проходить без знаний из книги (trust me). А ещё Денис ведёт блог и иногда проводит соревновашки на оптимизации.

Для меня новыми методами поиска узких мест стали roofline анализ и TMA (Top-down Microarchitecture Analysis). Почему-то в мире java такими штуками пользоваться не принято. В отличие, например, perfomance counter'ов. Вероятно, это связано с архитектурными ограничениями (отсутствием векторизации и JIT'ом).

Ещё я стал гораздо лучше понимать принципы работы современных процессоров. Если помните, я когда-то расшаривал исторические документы про архитектуры супер-ЭВМ, но те материалы всё-таки не дают такого представления о _современных_ процессорах, как книга Дениса.

Короче, рекомендую. Книга хорошая, годная, 10/10.

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

https://t.iss.one/bminaiev_blog/13 — про победу микрооптимизаций над асимптотикой

https://t.iss.one/bminaiev_blog/34 — про эмпирическую оценку размера кэшей

https://t.iss.one/bminaiev_blog/37 — memory allocation profiler на bash 😁

Рекомендую.

Тут короче два года, как я работаю в Яндексе. И честно говоря, готов петь дифирамбы компании, настолько она для и про людей. Но эти ваши новости опять в карман срут, поэтому лучше поговорим о том, что я вот уже два года в роли руководителя группы разработчиков.

Опыт очень классный, невероятно интересный. Я каждый день хожу на работу с довольствием, хотя иногда и с плохим настроением. Это ощущение мне напоминает мои первые несколько лет в разработке. Настолько же всё прямо зудит, так же легко проглатываются книги и статьи (ладно, чуть сложнее), настолько же интересно обсуждать работу с коллегами.
Чего не хватает мне в этой работе, так это бесконечной череды успехов и заборотых задач — программировать было проще.
Что ещё есть такого особенного из минусов? Очень длинный цикл обратной связи. Просто невозможно попробовать разные идеи в какой-то сжатый промежуток времени. И неприятные беседы. Увольнения, замечания, плохие ревью и корректирующая обратная связь — это всё моя работа. За два года мне стало сильно легче этим заниматься, но всё равно это каждый раз требует усилий. Вот бы все сами по себе хорошо работали и получали высшие оценки на ревью (я б тогда был не нужен, получается).

Сражения с синдромом самозванца вообще не утихают, кстати. Вот как программист я за три-пять лет коммерческой разработки стал уверен в себе. А тут нет тренда. Зато, глядишь, больше книжек прочту, тоже полезно.

В общем, держите бесполезный пост для вас, но зато я высказался. Спасибо, если вдруг прочитали :)

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

Assumptions
- курс рубля к доллару будет ослабевать
- ЦБ будет защищать порог курса в 100 рублей за доллар интервенциями на рынок (по политическим причинам)

Скорее всего уже в предположениях ошибка, но представим, что нет.

Inefficiency
Потолок курса

Idea
Давайте будем покупать доллар за рубль, таким образом надавливая на курс в сторону 100. Покупаем дёшево (по 95, 97, 99). В это же время ставим заявку на продажу баксов по 99.75 (главное не торгануть с собой лол). ЦБ будет видеть, что КУРС ДВИЖЕТСЯ К ОПАСНОЙ ТОЧКЕ. Простите, не удержался. И продавать свои баксики нам по 99.75! Всё, продали дорого, заработали много денег, мы великолепны.
Подписываемся на платный канал с сигналами от квант валериан, платим комиссии бирже и брокеру, платим налоги, покупаем себе лавандовый раф на всю котлету.

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

ОЙ, ОШИБСЯ