Джон Хеннесси и архитектура ЭВМ: идеи масштабирования

Почему Хеннесси важен для разговоров о производительности

Джон Хеннесси — один из людей, которые помогли сформировать современный инженерный язык разговора о скорости компьютеров. Он не просто «придумывал процессоры»: его работы (и учебник, написанный вместе с Дэвидом Паттерсоном) научили индустрию измерять производительность, объяснять, откуда она берётся, и честно обсуждать компромиссы.

От «быстрее на гигагерцах» к системному мышлению

Долгое время казалось, что прогресс — это просто рост частоты и усложнение одного ядра. Затем рост стал упираться в энергопотребление, тепло и задержки памяти. На практике это привело к сдвигу фокуса:

• от одного «суперядра» — к многоядерности и параллельной работе;
• от универсальных решений — к ускорителям и специализации там, где это оправдано;
• от оптимизации одной инструкции — к оптимизации всей цепочки «железо + софт + данные».

Хеннесси важен потому, что его идеи и формулировки помогают не спорить на уровне лозунгов («надо больше ядер», «надо быстрее память»), а задавать правильные вопросы: что именно ограничивает систему, где узкое место, и какие последствия у выбранного решения.

Что вы получите из этой статьи

Дальше мы будем использовать подход, который популяризировал Хеннесси: сначала определить метрику и цель, затем найти ограничители, и только потом выбирать технику ускорения.

В итоге у вас появится понятный словарь для рабочих обсуждений производительности: чем отличается параллелизм инструкций от параллелизма задач, почему память часто важнее «сырых FLOPS», и почему ускорение почти всегда связано с компромиссами.

Производительность как свойство всей системы

Когда говорят «сделаем быстрее», часто подразумевают процессор. Но в реальности производительность — это результат работы всей системы: процессора, памяти, диска, сети, ОС, библиотек и логики приложения.

Это полезно помнить не только инженерам «железа», но и тем, кто строит продукты и сервисы: узкое место часто лежит на стыке слоёв. Например, в TakProsto.AI, где приложения собираются через чат (React на фронтенде, Go + PostgreSQL на бэкенде), ускорение почти всегда начинается не с «магии CPU», а с выбора правильной метрики, сценария нагрузки и дисциплины экспериментов — ровно в той логике, которую продвигают Хеннесси и классическая школа архитектуры.

Два разных смысла скорости: latency и throughput

Задержка (latency) — это время выполнения одной операции или запроса: например, сколько миллисекунд занимает открыть страницу или обработать платёж.

Пропускная способность (throughput) — это сколько операций система успевает выполнить за единицу времени: например, запросов в секунду или обработанных задач в минуту.

Улучшения могут влиять на эти метрики по-разному. Очереди, кэширование или батчинг часто увеличивают throughput, но иногда ухудшают latency для отдельного пользователя. И наоборот: оптимизация «быстрого ответа» может снизить общую пропускную способность, если система начинает тратить ресурсы на приоритизацию единичных запросов.

Где искать узкое место

«Узкое место» меняется в зависимости от нагрузки и сценария. Типовые ограничители:

• CPU: тяжёлые вычисления, неэффективные алгоритмы, лишняя сериализация.
• Память: промахи кэша, частые обращения к ОЗУ, плохая локальность данных.
• Ввод-вывод: диск, файловая система, внешние сервисы.
• Сеть: задержки, потери пакетов, ограничение по полосе.
• Блокировки и ожидания: мьютексы, очереди, транзакции, «stop-the-world» паузы.

Главная мысль: измерять нужно не «что медленно вообще», а что ограничивает целевую метрику прямо сейчас.

Почему ускорить CPU ≠ ускорить систему

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

Это дисциплина: сначала профилирование и эксперименты, затем решения — от изменения алгоритма и схемы данных до переразбиения задач и оптимизации I/O.

RISC и ставка на простоту: стратегическое решение

Идея RISC (Reduced Instruction Set Computer) у Хеннесси — это не «упрощение ради упрощения», а осознанная ставка на предсказуемость и масштабируемость. Вместо того чтобы делать процессор «умнее» за счёт сложных инструкций, RISC предлагает минимальный набор простых операций, которые выполняются быстро и одинаково.

Простые инструкции — предсказуемый конвейер

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

Важная деталь: часть «сложности» переносится в компилятор. Компилятор лучше видит программу целиком, может упорядочивать операции, подбирать регистры и планировать вычисления так, чтобы конвейер простаивал как можно меньше.

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

Как RISC повлиял на стоимость, энергию и рост производительности

Ставка на простоту обычно означает:

• меньше «логики управления» и декодирования → меньше транзисторов под нерегулярные сценарии;
• ниже энергопотребление на одну операцию за счёт более прямых путей данных;
• легче верификация и быстрее вывод новых дизайнов, а значит ниже инженерная стоимость и риск.

Это особенно важно, когда рост частот перестал быть «бесплатным»: выигрывать приходится дисциплиной проектирования и эффективностью на ватт.

Наследие RISC в современных ядрах

Даже там, где набор команд исторически сложнее, внутри современных процессоров часто живёт RISC‑подобная философия: сложные инструкции разбиваются на более простые микрооперации, а дальше работают те же принципы — конвейеры, планирование, кэши и предсказуемые пути выполнения.

В этом смысле вклад Хеннесси — не только в конкретной ISA, а в мышлении: простота как стратегия, которая облегчает дальнейшее масштабирование.

Пределы параллелизма на уровне инструкций (ILP)

ILP (instruction-level parallelism) — это способность одного ядра выполнять несколько машинных инструкций одновременно или «перекрывая» их по времени. Идея кажется простой: если внутри программы есть независимые операции, процессор может делать их параллельно и тем самым ускорять выполнение без участия программиста.

Что такое ILP: конвейер, суперскалярность, переупорядочивание

Базовый механизм ILP — конвейер: выполнение инструкции разбивается на стадии (выборка, декодирование, выполнение и т. д.), и пока одна инструкция исполняется, следующая уже декодируется. Это даёт прирост, но в основном за счёт лучшего «наполнения» ядра работой.

Дальше начинается более агрессивный ILP:

• Суперскалярность: несколько исполнительных блоков позволяют выдавать и выполнять более одной инструкции за такт.
• Переупорядочивание (out-of-order execution): ядро переставляет инструкции местами, чтобы не простаивать на зависимостях и ожиданиях.
• Спекуляция и предсказание ветвлений: процессор пытается угадать, куда пойдёт выполнение, и заранее готовит работу.

Почему ILP перестал давать прежний прирост

У ILP есть потолок: реальные программы содержат зависимости, ветвления и обращения к памяти, которые невозможно распараллелить «внутри одного потока» бесконечно.

Кроме того, дальнейшее наращивание ILP быстро упирается в три проблемы:

1. Сложность: чтобы находить больше независимых инструкций, нужны более широкие блоки, большие буферы, сложная логика планирования. Это ухудшает масштабирование и усложняет верификацию.
2. Задержки: даже идеально организованное ядро не спасает, если поток часто ждёт данные из кэша/памяти или ошибается в ветвлениях.
3. Энергия: логика переупорядочивания, большие структуры и спекуляция стоят дорого по потреблению — прирост производительности начинает «покупаться» непропорционально высокой мощностью.

Практический вывод: когда оптимизация «внутри ядра» окупается

ILP-оптимизации оправданы, когда у вас плотный вычислительный код (мало ветвлений, хорошие данные в кэше, много арифметики) — например, в численных ядрах, обработке сигналов, части ML-инференса. Там улучшения компилятора, векторизация и грамотная работа с зависимостями реально дают выигрыш.

Если же узкое место — память, ветвления или ожидание I/O, то попытки «выжать ILP» часто дают крошечный эффект. В таких случаях выгоднее думать не о глубине оптимизации одного потока, а о параллелизме на уровне задач/потоков, локальности данных и структуре системы в целом.

Закон Амдала: почему параллелизм не бесконечен

Закон Амдала — это простое напоминание: ускоряя только часть программы, вы неизбежно упираетесь в то, что осталось «медленным». Поэтому обещания «добавим ядра и получим X раз быстрее» почти всегда оказываются завышенными.

Простыми словами

Любая задача состоит из двух частей: та, что можно распараллелить, и та, что по природе последовательная (или плохо параллелится). Если последовательная доля равна, скажем, 10%, то даже при бесконечном числе потоков ускорение ограничено примерно 10 раз.

Часто это записывают так:

Speedup(N) = 1 / (S + (1 - S)/N)

где S — доля работы, которая остаётся последовательной, а N — число параллельных исполнителей (ядер/потоков).

Что обычно «не ускоряется»

На практике «последовательность» — это не только один явно последовательный цикл. Типичные источники:

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

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

Как применять закон Амдала перед инвестициями

Перед тем как покупать железо, переписывать систему под многопоточность или добавлять ускорители, оцените долю ускоряемого кода:

1. Профилированием найдите, где реально уходит время (а не где «кажется»).
2. Отделите «чистые вычисления» от ожиданий (I/O, блокировки, очереди).
3. Посчитайте верхнюю границу ускорения по Амдалу и сравните с целевым SLA.

Если расчёт показывает потолок в 2–3 раза, а вы планируете бюджет ради 10x, проблема не в количестве ядер — проблема в доле S и в архитектуре процесса.

Параллелизм на уровне потоков и задач (TLP)

Когда рост частоты и «выжимание» параллелизма внутри одного потока (ILP) дают всё меньше, производительность всё чаще масштабируют за счёт Thread-Level Parallelism — параллелизма на уровне потоков и задач. Идея простая: вместо того чтобы ускорять одну нитку исполнения, запускаем несколько независимых работ одновременно и увеличиваем общую пропускную способность системы.

Что реально масштабируется: потоки, задачи, акторы, очереди

На практике TLP работает лучше всего там, где можно нарезать работу на относительно независимые единицы:

• Потоки (threads) подходят для длительных задач и сервисов, но требуют дисциплины с общими данными.
• Задачи (tasks / futures) удобны для мелких работ: планировщик сам распределяет их по ядрам.
• Акторы снижают потребность в блокировках: состояние изолируется, взаимодействие идёт сообщениями.
• Очереди работ (work queues) и пул воркеров дают предсказуемый throughput, если операции примерно одинаковой «тяжести».

Ключевой критерий масштабируемости — доля кода, которая действительно может выполняться параллельно, и цена координации (синхронизация, обмен данными, переключения контекста).

Многоядерность: рост throughput, но не всегда снижение latency

Многоядерные процессоры чаще всего улучшают throughput: больше запросов в секунду, больше обработанных задач, больше параллельных пользователей.

Но latency (время ответа одной операции) может почти не улучшиться — или даже ухудшиться — из‑за очередей, конкуренции за кэш/память и накладных расходов синхронизации. Поэтому важно заранее понимать цель: «быстрее один запрос» или «больше запросов одновременно».

Типовые ошибки: блокировки и false sharing

Две частые причины, почему TLP «не взлетает»:

1. Чрезмерные блокировки: один мьютекс на всё превращает многоядерность в имитацию. Хорошие симптомы — рост времени ожидания lock’ов и падение ускорения после 2–4 ядер.

2. Ложное совместное использование (false sharing): потоки пишут в разные переменные, но они лежат в одной кеш‑линии. Ядра постоянно «перетягивают» кэш, и производительность падает без очевидной причины.

Практический вывод: TLP требует не только «распараллелить код», но и спроектировать границы данных и коммуникаций так, чтобы ядра как можно реже мешали друг другу.

Память как главный ограничитель: задержки и локальность

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

«Стена памяти»: почему задержки не поспевают за аппетитом к данным

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

Проблема не только в «медленной DRAM», а в разрыве между скоростью выполнения инструкций и задержкой получения нужного байта. Чем агрессивнее процессор, тем дороже простой.

Кэши, предвыборка и локальность — и их ограничения

Кэши помогают, когда у данных есть локальность:

• временная (данные используются повторно скоро),
• пространственная (рядом лежащие данные используются вместе).

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

Кроме того, если пропускная способность памяти исчерпана, «угадать» мало — данные всё равно не успевают приезжать.

Практические паттерны: как уменьшать промахи кэша

На уровне инженерных решений часто выигрывают не «хитрые инструкции», а дисциплина работы с данными:

• Реорганизовать структуры данных под доступ: хранить вместе то, что читается вместе (часто это переход от «структуры с кучей указателей» к более плотным массивам).
• Сокращать лишние копии: избегать промежуточных буферов, лишней сериализации и конкатенаций, которые раздувают трафик памяти.
• Уменьшать рабочий набор: обрабатывать данные батчами, выносить редко используемые поля, применять более компактные форматы.

Идея в духе Хеннесси проста: производительность — это не только «быстрее считать», но и «быстрее и экономнее доставлять данные к месту вычислений».

Метрики и эксперименты: дисциплина, а не интуиция

Одна из самых практичных идей, которую часто связывают с традицией Хеннесси, — производительность нельзя «почувствовать», её нужно измерять. Интуиция подсказывает, куда смотреть, но решения о том, что оптимизировать и какой компромисс принять, должны опираться на цифры.

Что измерять: не только «стало быстрее»

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

Для низкоуровневой оптимизации полезны CPI/IPC: они показывают, сколько тактов уходит на инструкцию и насколько эффективно загружены вычислительные блоки. Но даже идеальный IPC может ничего не дать, если узкое место — память или ввод‑вывод.

Для сервисов и приложений часто важнее пропускная способность (сколько запросов/операций в секунду) и хвостовые задержки — p95/p99. Среднее время ответа может улучшиться, а p99 ухудшиться из‑за очередей, блокировок или «шумных соседей» — и пользователь почувствует именно это.

Методика: профилирование → гипотеза → измерение → повтор

Дисциплина экспериментов обычно выглядит так:

1. Профилирование: где реально тратится время/энергия, какие ожидания доминируют (CPU, память, I/O, синхронизация).

2. Гипотеза: конкретное утверждение вида «если уменьшить X, то улучшится Y, потому что Z». Без «потому что» это не гипотеза, а желание.

3. Измерение: фиксируем окружение, прогоняем до статистической устойчивости, сравниваем с базовой линией.

4. Повтор: результат либо подтверждает гипотезу, либо уточняет модель системы.

В продуктовой разработке полезно иметь и «технические» механизмы отката. Например, в TakProsto.AI можно опираться на снимки (snapshots) и rollback, чтобы безопаснее проверять гипотезы производительности в развёртываниях и быстро возвращаться к базовой линии, если метрики ухудшились.

Риск «оптимизации на глаз»

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

Хорошее правило: прежде чем что‑то «ускорять», убедитесь, что это влияет на выбранную метрику и воспроизводимо в эксперименте. Если нужно, зафиксируйте подход в инженерных соглашениях и чек‑листах команды (например, в /blog/performance-process).

Энергоэффективность и «конец бесплатного ускорения»

Долгое время производительность росла почти «сама»: транзисторы становились меньше, частоты — выше, а программам доставалось ускорение без переписывания. Этот период закончился, когда уперлись в ограничения по мощности и теплу.

Для современных систем ключевой ресурс — не только миллисекунды, но и ватты: сколько ускорения вы получаете на каждый дополнительный ватт потребления.

Почему энергия стала ключевой валютой производительности

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

Для инженера это означает простую мысль в духе Хеннесси: производительность нельзя обсуждать отдельно от стоимости её достижения. «Бесплатного» ускорения больше нет — любое ускорение оплачивается энергией.

Компромиссы: частота vs напряжение, параллелизм vs накладные расходы

Увеличение частоты обычно требует повышать напряжение, а это резко увеличивает потребление. Поэтому индустрия сместилась к многопоточности и многоядерности, но и здесь есть цена: синхронизация, конкуренция за память и накладные расходы планирования могут «съесть» часть выигрыша.

Параллелизм помогает, когда работа хорошо дробится и данные локальны. Если же узкое место — память или обмен между потоками, то дополнительные ядра превращаются в дополнительные ватты без сопоставимого ускорения.

Практический взгляд для продукта: цена производительности в ваттах и в бюджете инфраструктуры

На уровне продукта важно измерять не только latency/throughput, но и производительность на ватт. В дата‑центре это превращается в деньги дважды: за электричество и за охлаждение.

Иногда выгоднее снизить пиковую частоту, улучшить локальность данных или ограничить «раздувание» параллелизма — и получить почти ту же скорость при заметно меньшей стоимости владения.

Итог: стратегия масштабирования сегодня — это управление энергией так же тщательно, как управление временем выполнения.

Специализация и ускорители: когда стоит отходить от универсальности

Универсальный процессор хорош тем, что «умеет всё», но платит за это лишней сложностью и энергопотреблением. Идея, которую Хеннесси продвигал особенно активно в последние годы, проста: если часть работы повторяется постоянно и хорошо формализуется, выгоднее выполнять её на специализированном ускорителе.

Что дают ускорители — и где их границы

Ускоритель выигрывает не магией, а тем, что делает меньше «лишних» операций: проще контроль, короче путь данных, меньше обращений к памяти, точнее под конкретный тип вычислений.

Но ускорители не бесплатны. Они обычно:

• сильны в узком классе задач (и слабы вне его);
• требуют отдельного стека инструментов и навыков;
• чувствительны к тому, насколько данные «подходят» под ожидаемые формы и размеры.

Если алгоритм часто меняется, специализация быстро теряет смысл: железо не перепишешь так же легко, как код.

Риски: переносимость, цена и эксплуатация

Главные риски — организационные. Переносимость падает: решение привязано к конкретной платформе и библиотекам. Стоимость разработки растёт: нужно не только сделать ускоритель (или интеграцию), но и построить тестирование, мониторинг, воспроизводимость, обновления драйверов/рантайма.

Эксплуатация усложняется: появляются разные пути исполнения (CPU/ускоритель), больше сценариев деградации и больше вопросов к наблюдаемости.

Как понять, что «пора»

Полезный фильтр из трёх вопросов:

1. Частота использования: эта операция выполняется постоянно или эпизодически?
2. Доля времени: занимает ли она заметную часть общего времени/стоимости (иначе закон Амдала съест выигрыш)?
3. Стабильность алгоритма: будет ли он таким же через год, или требования ещё «плавают»?

Если ответы «часто», «много» и «стабильно», специализация обычно оправдана — особенно когда упираетесь не в программирование, а в энергию, задержки или цену вычислений.

Совместное проектирование железа и софта

Идея Хеннесси «железо + софт вместе» — это не про «оптимизировать пару циклов», а про согласование интерфейсов и ожиданий по всей цепочке: от инструкций и памяти до компилятора, рантайма и прикладной архитектуры.

Когда эти слои проектируются независимо, система часто теряет производительность на стыках — из‑за лишних копирований, неудачных форматов данных, неподходящей модели параллелизма или слишком дорогих синхронизаций.

Интерфейсы важнее отдельных оптимизаций

Хороший интерфейс — тот, который делает быстрый путь естественным. Это может быть набор примитивов для параллельного выполнения, понятные гарантии по памяти, удобные атомарные операции, предсказуемый ввод‑вывод.

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

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

Как модель параллелизма меняет систему

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

Примеры компромиссов: batch vs stream, sync vs async

Пакетная обработка проще для предсказуемого планирования и даёт высокий «средний» throughput, но может ухудшить время ответа.

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

Поэтому со‑проектирование — это ещё и про измеримость: аппаратные счётчики + профилировщики + трейсинг в рантайме должны говорить на одном языке.

Практические выводы для инженеров и руководителей

Идеи Хеннесси полезны тем, что возвращают разговор о производительности из зоны «кажется, надо ускорить» в зону управляемых решений и компромиссов.

Для команды это означает: сначала договориться, что именно вы оптимизируете, затем измерить, где теряется время/энергия/деньги, и только после этого выбирать архитектурные и продуктовые шаги.

Мини‑чек‑лист перед любыми оптимизациями

1. Определите цель: latency (время ответа), throughput (пропускная способность), стоимость (серверы/лицензии), энергоэффективность.

2. Найдите узкое место: CPU, память, I/O, сеть, блокировки, ожидание внешних сервисов. Обязательно подтвердите данными: профилировщиком, трассировками, нагрузочными тестами.

3. Зафиксируйте базовую линию: набор метрик и сценариев, чтобы «стало лучше» было проверяемым, а не субъективным. Полезные шаблоны — в /blog/performance-metrics и /blog/benchmarking-guide.

Как выбрать «рычаг» ускорения

• ILP (параллелизм инструкций): чаще уже «выжат» современными CPU; в прикладных командах обычно окупается меньше, чем работа с данными.
• TLP (параллелизм потоков/задач): масштабируется лучше, но упирается в синхронизацию и долю непараллелимого кода (закон Амдала).
• Оптимизация данных: локальность, форматы, кэширование, уменьшение аллокаций — часто самый быстрый путь к улучшению latency.
• I/O и внешние зависимости: батчинг, очереди, таймауты, ретраи, уменьшение «чата» по сети.
• Специализация: ускорители/векторизация имеют смысл, когда профиль стабилен, и выгода перекрывает сложность поддержки.

Для руководителей: управляемые решения

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

Если команда делает сервис «под ключ» и важно быстро проходить цикл «гипотеза → изменение → проверка метрик», полезны инструменты, которые сокращают время итерации. В этом смысле TakProsto.AI (vibe-coding через чат, развёртывание и хостинг, экспорт исходников, planning mode, снимки и откат) может быть практичным дополнением к инженерной дисциплине: быстрее доводить изменения до теста под нагрузкой — и так же быстро возвращаться назад, если цифры не подтвердили ожидания.