Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного
времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно
живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и
именно из-за академических корней BSD изначально большое внимание уделялось проработке
алгоритмов. Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости
кода, который может быть достаточно легко изменен, расширен или с течением времени
заменен. Хотя некоторые считают BSD ``старой'' операционной системой, те их нас, кто
работает над ней, видят ее скорее системой со ``зрелым'' кодом с различными компонентами,
которые были заменены, расширены или изменены современным кодом. Он развивается, и
FreeBSD остается передовой системой, вне зависимости от того, насколько старой может быть
часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой
ошибкой, которую может допустить программист, является игнорирование истории, и это
именно та ошибка, которую сделали многие другие современные операционные системы. Самым
ярки примером здесь является Windows NT®, и
последствия ужасны. Linux также в некоторой степени совершил эту ошибку--достаточно,
чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема
Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема,
которая легко и быстро решается сообществом Linux точно так же, как она решается в
сообществе BSD--постоянной работой над кодом. Разработчики Windows NT, с другой стороны, постоянно совершают те же
самые ошибки, что были решены в UNIX® десятки лет
назад, а затем тратят годы на их устранение. Снова и снова. Есть несколько случаев
``проработка архитектуры отсутствует'' и ``мы всегда правы, потому что так говорит наш
отдел продаж''. Я плохо переношу тех, кого не учит история.
Большинство очевидной сложности архитектуры FreeBSD, особенно в подсистеме VM/Swap,
является прямым следствием того, что она решает серьезные проблемы с производительностью,
которые проявляются при различных условиях. Эти проблемы вызваны не плохой проработкой
алгоритмов, а возникают из окружающих факторов. В любом прямом сравнении между
платформами эти проблемы проявляются, когда системные ресурсы начинают истощаться. Так
как я описываю подсистему VM/Swap во FreeBSD, то читатель должен всегда иметь в виду два
обстоятельства. Во-первых, самым важным аспектом при проектировании производительности
является то, что называется ``оптимизацией критического маршрута''. Часто случается, что
оптимизация производительности дает прирост объема кода ради того, чтобы критический
маршрут работал быстрее. Во-вторых, четкость общей архитектуры оказывается лучше сильно
оптимизированной архитектуры с течением времени. Когда как обобщенная архитектура может
быть медленнее, чем оптимизированная архитектура, при первой реализации, при обобщенной
архитектуре легче подстраиваться под изменяющиеся условия и чрезмерно оптимизированная
архитектура оказывается непригодной. Любой код, который должен выжить и поддаваться
поддержке годы, должен поэтому быть тщательно продуман с самого начала, даже если это
стоит потери производительности. Двадцать лет назад были те, кто отстаивал преимущество
программирования на языке ассемблера перед программированием на языке высокого уровня,
потому что первый генерировал в десять раз более быстрый код. В наши дни ошибочность
этого аргумента очевидна--можно провести параллели с построением алгоритмов и обобщением
кода.
