Курсовая по информатике и вычислительной технике в МФТИ: системное программирование, архитектура и измеримый эксперимент

Курсовая по информатике и вычислительной технике в МФТИ имеет прямой образовательный контекст. В базовом наборе 2026 года направление 09.03.01 «Информатика и вычислительная техника» представлено несколькими конкурсными группами, включая компьютерные технологии, программную инженерию и компьютерные технологии, системное программирование и прикладную математику, естественные и компьютерные науки, математическое моделирование и теорию управления.

Это означает, что одинаковая поисковая фраза может вести к очень разным типам курсовых. Нужно ориентироваться на свою школу и дисциплину.

Официальный перечень:
https://pk.mipt.ru/bachelor/2026_places/

Системная тема

Подходящие задачи:

• allocator;
• scheduler;
• network stack;
• compiler;
• database engine;
• distributed service;
• embedded;
• HPC.

Не обязательно делать очередной CRUD-сервис.

Постановка

Например:

«Сравнение стратегий memory allocator при нагрузке с объектами разных размеров».

Или:

«Исследование задержки RPC при изменении batch size».

Есть метрика и эксперимент.

Baseline

Для системной работы baseline обязателен.

Это может быть:

• standard library;
• existing algorithm;
• naive implementation.

Без него непонятно, что улучшено.

Аппаратная среда

Зафиксируйте:

• CPU;
• cores;
• RAM;
• storage;
• OS.

Benchmark без hardware context трудно интерпретировать.

Версии

Сохраните:

• compiler;
• flags;
• library;
• kernel.

Оптимизация -O0 и -O3 может дать огромную разницу.

Не скрывайте настройки.

Compiler flags

Если сравниваете алгоритмы, используйте одинаковую конфигурацию.

Иначе вы сравниваете ещё и компилятор.

Warm-up

JIT, cache и lazy initialization могут делать первый запуск нетипичным.

Отделите warm-up от измерения.

Повторы

Один runtime недостаточен.

Сделайте, например, 20-100 повторов в зависимости от задачи.

Покажите:

• median;
• p95;
• variance.

Timer

Для короткой функции обычные часы могут иметь недостаточное разрешение.

Измеряйте batch операций.

Не выводите наносекунды с ложной точностью.

Cache

Кеш может полностью изменить результат.

Для memory benchmark задайте:

• working set;
• sequential/random;
• stride.

Покажите, где размер выходит за L1/L2/L3.

Memory bandwidth

Некоторые задачи ограничены не CPU, а memory.

Если увеличение числа cores перестаёт ускорять код, это возможная причина.

Используйте profiler или counters, если доступны.

Branch prediction

Для условного кода distribution input влияет на prediction.

Сравнивайте одинаковые данные.

Не делайте вывод на одном идеально предсказуемом наборе.

SIMD

Vectorization может ускорять численный код.

Проверьте:

• compiler report;
• alignment;
• data layout.

Не утверждайте SIMD по самому факту использования NumPy.

Многопоточность

Измерьте speedup:

T1 / Tp.

И efficiency:

speedup / p.

Не показывайте только время.

Amdahl

Если serial fraction остаётся большой, speedup ограничен.

Сопоставьте эксперимент с теоретическим пределом.

Synchronization

Mutex, atomic и barrier имеют overhead.

Профилируйте contention.

Не добавляйте lock вокруг всей функции.

False sharing

Два потока могут изменять разные переменные в одной cache line.

Производительность падает без логической race condition.

Это хороший системный кейс.

NUMA

На многосокетной системе память имеет разную локальность.

Если курс и hardware позволяют, можно исследовать pinning.

Но не добавляйте NUMA, если используется обычный ноутбук.

Сеть

Измеряйте:

• throughput;
• latency;
• jitter;
• packet loss.

Разделяйте localhost и реальную сеть.

Loopback не отражает физический канал.

RPC

На latency влияют:

• serialization;
• network;
• handler;
• queue.

Профиль помогает понять вклад.

Не приписывайте всё протоколу.

Serialization

Сравните:

• JSON;
• binary;
• custom.

Метрики:

• size;
• encode;
• decode.

Не выбирайте формат только по скорости. Важна совместимость.

Storage

Для диска различайте:

• cached;
• uncached;
• sequential;
• random.

OS cache может сделать «диск» скоростью RAM.

Понимайте, что измеряется.

Database

Для БД можно исследовать:

• index;
• transaction;
• isolation;
• cache.

Покажите query plan.

Не объявляйте индекс полезным без реального запроса.

Transaction isolation

Разные уровни дают компромисс:

• consistency;
• concurrency.

Создайте сценарий аномалии, если тема про транзакции.

Distributed system

Для распределённой темы определите:

• node;
• message;
• failure;
• consistency.

Не пишите «распределённая система» для frontend + backend на одном компьютере.

Failure

Проверьте:

• node down;
• timeout;
• duplicate message;
• network partition, если применимо.

Happy path недостаточен.

Retry

Retry может создать duplicate operation.

Для финансового или state-changing request нужна idempotency.

Покажите механизм.

Consensus

Если используете Raft/Paxos, не пытайтесь переписать теорию полностью.

Сфокусируйтесь на:

• leader election;
• replication;
• failure test.

Но такой проект требует достаточной глубины.

Embedded

Для микроконтроллера измеряйте:

• execution time;
• memory;
• interrupt latency;
• power.

Не переносите результаты PC на MCU.

Power

Для mobile/embedded системы performance per watt может быть важнее чистой скорости.

Если есть измеритель, это сильный эксперимент.

FPGA/GPU

Для ускорителя сравнивайте:

• same task;
• same precision;
• transfer overhead.

GPU может проигрывать на маленьком input из-за копирования данных.

Profiling

Используйте profiler до оптимизации.

Покажите:

• top functions;
• flame graph;
• counters.

Не оптимизируйте по интуиции.

Flame graph

Он помогает увидеть stack времени.

Выберите один bottleneck и разберите его.

Не вставляйте огромный граф без комментария.

Корректность до скорости

Fast wrong answer не является улучшением.

Сначала tests.

Потом benchmark.

Особенно при low-level optimization.

Differential testing

Если есть эталонная реализация, сравнивайте outputs на большом наборе случайных тестов.

Это полезно для оптимизированного алгоритма.

Fuzzing

Для parser или protocol handler можно использовать fuzzing.

Покажите:

• corpus;
• crashes;
• fixes.

Не запускайте fuzzing на чужой системе.

Reproducibility

Сохраните script benchmark.

Он должен автоматически:

• build;
• run;
• collect;
• output.

Ручное копирование времени из терминала увеличивает ошибку.

График

Хорошие варианты:

• input size -> time;
• threads -> speedup;
• load -> p95;
• memory -> throughput.

Не перегружайте пятью осями.

Практическая глава

Схема:

1. задача;
2. baseline;
3. architecture;
4. implementation;
5. correctness;
6. experiment;
7. profile;
8. optimization;
9. benchmark;
10. limits.

Что учитывать в МФТИ

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

Защита

Будьте готовы назвать hardware, compiler flags, baseline, способ измерения, p95, bottleneck и предел ускорения.

Сильная курсовая по ИВТ в МФТИ показывает воспроизводимый системный эксперимент и объясняет не только «что быстрее», но и почему.