1. Грехопадение архитектуры Фон Неймана: от идеальных алгоритмов к суровой реальности

среда, февр. 4, 2026 | 4 минуты чтения

1. Грехопадение архитектуры Фон Неймана: от идеальных алгоритмов к суровой реальности

Существовали 4 принципа архитектуры Фон Неймана. Люди жили в раю. А потом состоялось грехопадение - нарушили принципы Фон Неймана. Ну и что, что он сказал, что так надо. Давайте не будем так делать. Голову вытянет, хвост увязнет.

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

Асимптотики алгосов это идеальность. В реальных боевых условиях процессор может дать процессорное время, а может не дать. Никто не даст алгоритму целое ядро. То же самое с доступом к диску, памяти, сети…

На этом курсе мы будем убирать мифы из головы.

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

Сохранение энергии работает везде. Если был опыт спортивного программирования (на codeforces, да и вообще сортми…), то вы знали что можно написать идеальную программу по памяти и идеальную по времени. Одновременно идеальную по времени и памяти нельзя. Нужно жертвовать чем-то.

ИИ не заберёт рабочие места. Он сместит точку принятия решения.

На защите дипломов задаётся вопрос: “а что, если упадёт это?”
Студент радостно отвечает: “а я это предосмотрел, у меня есть это”
Ему встречный вопрос. “А что если и это упадёт?”
И студент понимает что так можно и дальше задавать вопрос. Это филосовский вопрос который идёт в никуда

Противоречивости требований

С младших курсов, со школы, есть мнение что самое главное пройти авто тесты. Тесты на функциональность. Но есть и нефункциональные тесты. Если я резервирую, то мне нужно синхронизировать. Если синхронизирую, то теряется производительность. И т.д.
Проклятие инженера - если я что-то сделаю лучше, то другое получится хуже.

Главное противоречение справедливость и эффективность

В очереди кассы стоят люди с разным кол-вом товаров. Подходит бедный студент с 1 бутылкой воды. Для кассира “фиолетово” кто будет первым, кто последним. Так как он всех обслужит за одно время. Для магазина эффективнее чтобы первыми были обслужены люди с меньшим кол-вом товаров. Меньше очередь, если люди зайдут и увидят что она не большая, то они останутся. Можно поставить охранника или менеджера. Но что скажут люди в очереди? Это несправедливо.

Bash появился в 1978 году. Было масса попыток его заменить: php, perl, python. Но bash остался и кажется он никуда не делся


Организация курса

Организация лабы (50 баллов)
6 контрольных (30 баллов)
экзамен (20 баллов)


Эволюция Операционных Систем

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

Архитектура Фон-Неймана

Если зайти в диспетчер задач, то можно увидеть сотни процессов. И все эти процессы хотят пользоваться железом…

1 принцип - однородность памяти
2 принцип - интерпретация
3 принцип - имеем адресность
4 принцип - программное управление

Появление подпрограмм и диспетчера

На этом этапе появилась переиспользование кода (конец 40, начало 50ых, нет ни c++ нет ни асемблера даже, только инструкции написанные двоичными битами)

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

Я движусь по коду сверху вниз по инкременту. Но мне каким-то образом нужно перепрыгнуть с одной ячейки на ячейку начала подпрограммы. Помимо этого нужно передать аргумент и сохранить место откуда я прыгнул. Тогда нужно в память подпрограммы положить номер ячейки возврата и номер ячейки возврата. Но тогда эти адресы подпрограммы нельзя перезаписывать.

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

Появляется следующая идея - давайте сделаем таблицу динамической. Создадим диспетчер. У диспетчера будет табличка. Левая часть всегда неизменная. Фактически это просто индексация массива. Ключ - название подпрограммы, значение - адрес начала подпрограммы

Кроме того я могу этому диспетчеру передать стэк. Диспетчер становится универсальным управленцем

Диспетчер решал проблему линковки и автоматизации загрузки повторного использования кода

Появление контроллеров и прерываний

Появилась идеи предзагружать данные в ОЗУ. Так как ЦПУ мог либо только гнать данные либо их обрабатывать, то мы не можем ничего сделать по архитектуре Фон Неймана. А давайте создадим процессор поменьше и потупее, который умеет только гнать данные.

Контроллер это штучка Storage. Процессор может только давать ему инструкции перегнать данные. Но мы не знаем закончил ли контроллер перегонку данных. Это ведь физическая штука. Магнитная лента, перфокарта… Нужно прерывание. Контроллер сообщает процессору что закончил

Прерывание - обращение(сигнал), поступающий от внешнего устройства в центральный процессор, сообщающий о наступление некоторого события, преостанавливающий исполнение текущего потока команд и передающий управление обработчику этого прерывания