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

CS 153: Frontier Systems | Stanford University
https://cs153.stanford.edu/

Прикольний тим, що це спроба пояснити, як виглядає вся АІ система загалом. Бо зазвичай ми бачимо тільки верхівку — ChatGPT, Copilot, Midjourney. А під цим — величезний стек: датацентри, GPU, distributed systems, тренування моделей, і тільки потім вже продукт.

І от весь цей стек вони проходять шар за шаром. Причому через людей, які це реально будують прямо зараз.

Типу:
Jensen Huang розповідає про залізо,
Andrej Karpathy — про моделі,
Sam Altman — про продукт і майбутнє,
Satya Nadella — як це все впливає на великі компанії.

По суті це такий system design для AI епохи. І головна думка AI — це вже давно не “модель”, це інфраструктура. Якщо ти бачиш тільки модель — ти бачиш десь 10% картини.

Перша лекція

Зранку трохи пустив сльозу.

Почав викладати в ліцеї інформатику, перша пара і раптом о 9:00 всі ліцеїсти просто встали, щоб вшанувати память загиблих. Причому, що жодного сигналу не було — оповіщувач зламався, то я спочатку навіть трохи розгубився і не одразу зрозумів, що відбувається.

А потім в ліцеї лунає гімн, а вони стоять, приклавши руку до серця.

У такі секунди просто відчуваєш, які хороші діти у нас ростуть.

4 роки тому одне інтерв’ю змінило моє життя.

Березень 2022-го. Війну я зустрів за кордоном. Постійно "на трубі" з друзями. Наш чат на трьох, де раніше були лише меми, перетворився на нескінченне "як ви?".

Одного вечора, коли «Азов» уже був у повному оточенні, у чат прилетіло посилання. Інтерв’ю з Денисом Прокопенком. Відкрив автоматично, щоб відволіктися. І залип. Він говорив чітко, виважено, предметно. Про цивільних, про ситуацію в місті, про полк, що стримує навалу ворога. Сказати, що я був вражений, — це нічого не сказати.

Я така людина, що завжди шукає коріння. Мені цікаво, як людина зростала, що на неї впливало. Тоді я ще не знав, хто такий Редіс. Тому почав вивчати. Ось просто сухі факти з мережі: ультрас «Динамо» та викладач англійської й німецької за освітою. 2014-й — доброволець, солдат. У 26 років — командир «Азову». Герой України. Сьогодні — бригадний генерал.

Але якщо подивитися інтерв'ю про нього від людей, що з ним перетиналися, то всі як один пишуть про фанатичну працездатність. Він — приклад того, як гострий розум множиться на трудоголізм. Один епізод, який пояснює все: Неділя. 04:00 ранку. Єдиний вихідний за тиждень. Дзвінок: «Вибач, що розбудив. Є термінова задача». Це і є Редіс. "Моє серце, моя душа, моє тіло належать Азову". Це і є Редіс.

До чого я це пишу? Після того інтерв’ю я невдовзі повернувся до Києва. Пройшло 4 роки. Сьогодні мені не соромно повідомити, що наша школа csosvita.com перетнула рубіж у 3 000 000 гривень допомоги Силам оборони. Безкоштовне навчання для військових. Понад 1 000 000 гривень ми спрямували саме на «Азов». І від сьогодні ми — їхні офіційні партнери.

Так, я не військовий. Але це мій спосіб бути корисним у цій війні, поки без зброї в руках. Просто робити максимум там, де я є. Просто робити якісну Computer Science освіту.

Дякую за приклад, командире.
"Без бою немає слави" (с) Редіс.

Branch Predictor: скільки if-ів — це забагато?

Нещодавно копався в hot path нашого коду і натрапив на класику:

if (debug) {
    log("...");
}

І задумався: ми ніколи не запускаємо з debug = true. Чи є якась ціна у цього if, який ніколи не спрацьовує? А якщо таких if-ів буде 10? 100? 1000? Старе правило каже: повністю передбачуваний branch — це ~0 тактів CPU. Але наскільки це правда? Почав розбиратися.

Чому взагалі існує branch prediction? Сучасний CPU — це конвеєр. Поки одна інструкція виконується, наступна вже декодується, а та, що після — вже завантажується з пам'яті. Все летить паралельно. Але що відбувається, коли CPU натикається на jmp або if?

    BR label_a;
    X1          ; <- CPU може завантажити цю інструкцію "про всяк"
    ...
label_a:
    Y1          ; <- а виконувати треба ось цю

CPU ще не знає, куди стрибати — інструкція ще навіть не декодована. Але fetch unit вже хоче наступну! Якщо він вгадає неправильно — марно витрачені такти. Це називається frontend bubble.

Саме тому існує Branch Predictor Unit (BPU) — спеціальний блок CPU, який намагається вгадати адресу наступної інструкції ще до того, як branch буде декодовано. У нього мінімум інформації: лише адреса поточної інструкції та історія попередніх переходів. І він вгадує з дуже високою точністю.

Ключова структура всередині BPU — Branch Target Buffer (BTB). Це, по суті, кеш, де CPU запам'ятовує: "минулого разу ця інструкція стрибнула ось сюди".

Далі вирішив провести експеримент: скільки branchів витримує BTB? І натрапив на такий блог пост від https://blog.cloudflare.com/branch-predictor/
Дуже раджу почитати.

Практичні поради (TL;DR)
1. Never-taken branch — безкоштовний. Той if (debug) нічого не коштує, якщо він ніколи не true. Можете сміливо залишати — BTB про нього навіть не знає.

2. Always-taken branch коштує BTB-слот. Кожен jmp, кожен taken if, кожен call + ret — це запис у BTB. На x86 у вас є бюджет ~4096 слотів.

3. Hot loop краще тримати < 4096 taken branches. Інакше BTB переповнюється, і кожен branch стає у 3–7 разів дорожчим.

4. Функцій у hot path — менше ніж 2000. Бо call + ret = 2 BTB-записи.

5. На x86 тримайте hot code < 16 KB. На M1 — ідеально < 4 KB.

6. На Intel не вирівнюйте branch-і по 64 байти. Associativity BTB зіграє проти вас.

Якщо пишете performance-critical код — рахуйте свої branch-і. CPU не всемогутній, навіть якщо дуже старається.

Midnight Code Cup 2026 — як AI змінив змагання

Пройшов кваліфікаційний раунд MCC https://midnightcodecup.org/. Задачі можна подивитись на Codeforces (на жаль, мають відношення до русні 🤮), і вони справді цікаві. Але найцікавіше — спостерігати за роллю AI у змаганнях.

Ще минулого літа на фіналі MCC команди вже використовували AI, але ближче до кінця контесту на топових місцях були ті, хто писав код руками — бо AI-код було складно підтримувати. Зараз ситуація кардинально змінилась: майже всі топові команди працювали через агентів, по суті кажучи їм, що робити, а не вирішуючи задачі самостійно. Ті, хто намагався все робити по-старому, витратили купу часу на бойлерплейт і не встигли реалізувати щось серйозне. Нагадує ситуацію в індустрії загалом: AI вже зараз дає величезне прискорення, але багато хто ігнорує це — і ризикує опинитися в програшній позиції.

Окремо цікаве спостереження про оптимізаційну задачу C: більшість топових рішень набрали приблизно 70k балів, але одна команда отримала 90k. Вони використали принципово інший підхід. І це добре ілюструє обмеження сучасних агентів — вони схильні мікрооптимізувати поточне рішення, але їм важко зробити крок назад і знайти глобально кращу стратегію.

Загалом, якщо ви ще не пробували розв'язувати задачі разом з AI-агентами — дуже раджу спробувати. Це незвичний процес, який потребує окремого навчання: треба розуміти, де агент допоможе, а де зашкодить, і як організувати роботу так, щоб легко знаходити баги, які він вносить у код.

Що питають на інтерв'ю у FAANG/HFT прямо зараз - дайджест за останні 2 місяці з реальних співбесід від випускників CS Osvita:

HFT (High-frequency trading) - багато задач з математики, є класична зелена книга (про яку писав вище) для повторення цього; кодінг задачі на перформенс оптимізацію можна потренувати ось тут, і дуже багато питають теорію - все що є на сайті варто пройти (від пейдж таблиць та віртуальної памяті до потоків і роботи cpu)

Стосовно кодінгу, то помітний тренд — розмиті умови, як новий стандарт: дають навмисно нечіткі задачі, щоб не можна було просто закинути в ai чи нагуглити. Під капотом це класичний алгоритм, але спочатку треба самому дійти до суті і саме так перевіряють, як ти уточнюєш, комунікуєш, думаєш вголос.

наприклад, були такі питання, що зводилися до
1. https://leetcode.com/problems/swap-adjacent-in-lr-string/description/

2. задизайнити snake game: які класи, структури даних, як би організував архітектуру

3. набір ренджів + запит "чи потрапляє число хоча б в один діапазон?", потім ускладнили - треба ще й вставку нових ренджів підтримувати. потім дійшли до цього: https://leetcode.com/problems/range-module/description/

4. є n ядер, кожне тягне одну задачу. нова задача → вибираєш вільне ядро з найменшим сумарним навантаженням. задача завершилась → оновлюєш навантаження, звільняєш ядро. треба зробити це ефективно (так, хіп 😄)

5. chemical formula decomposition — дано рядок formula та масив хімічних елементів. визначити, чи можна розбити formula на послідовність елементів з масиву. під капотом це word break: https://leetcode.com/problems/word-break/description/ — dp знизу вгору або dfs з мемоізацією по індексу

6. дві задачі в одній:
а) isValidId(str, alphabet, L, K) — перевірити, що рядок складається тільки з символів alphabet, має довжину рівно L, і жоден символ не повторюється більше K разів підряд.
б) generateStrings(alphabet, L, K) — згенерувати всі рядки довжиною L з alphabet, де жоден символ не йде підряд більше K разів.

Чому O(n) іноді програє O(n²)? Чому HashMap на мільйон записів може бути повільнішим за sorted array + binary search? Чому два потоки інколи працюють повільніше за один? Як працюють корутини? Як написати власний GC та malloc? І до чого тут ядро ОС?

Для middle/senior, без води. Cache, CPU pipeline, SIMD, branch predictor, memory layout, scheduling.

Завтра стартує курс Performance Engineering від CS Osvita — саме про це.
👉 csosvita.com/courses/performance-engineering

Класна штука — DeepWiki (https://deepwiki.com/)

Сайт, де лежить код популярних опенсорс-проєктів, і про нього можна питати AI. Наче чат з кодом, тільки він реально розуміє, що де лежить і як він працює.

Два режими:
— deep — показує конкретні шматки коду з поясненнями
— codemap — візуалізує структуру всього проєкту

Наприклад, можна подивитись як імплементований binary search у різних мовах і порівняти підходи:

chat → https://deepwiki.com/search/find-and-explain-binary-search_50038924-10a3-4609-a931-dfc83e469357?mode=deep

codemap → https://deepwiki.com/search/show-me-binarysearch-implement_e7948a6c-a72f-4748-a53f-a8c1b48135d3?mode=codemap

Або копнути як у LLVM зроблений Registry Pattern для реєстрації таргетів:
https://deepwiki.com/search/llvm-uses-a-registrar-the-targ_20014273-830e-4623-b832-24edd0fe6420?mode=fast

Рекомендую затестити не тільки для алгоритмів, а взагалі для вивчення дизайн-патернів, архітектури, будь-якого коду, який хочеться зрозуміти глибше.

MIT кілька годин тому виклав всі лекції нового курсу 6.566: Computer Systems Security, Spring 2026.
https://css.csail.mit.edu/6.566/2026/

Курс виглядає як крутий матеріал для тих, хто хоче глибше розібратися в computer systems security: як будуються захищені системи і де вони ламаються

Andrej Karpathy доєднується до Anthropic:
https://x.com/karpathy/status/2056753169888334312

А хто не знав: у Karpathy є легендарний курс CS231n: Deep Learning for Computer Vision від Stanford. Лекції доступні на YouTube, а на сайті Stanford можна знайти матеріали курсу та лабораторні роботи.