Алгоритмы для жизни. Простые способы принимать верные решения - Том Гриффитс

На собственном примере мы поняли, что и программирование, и писательская деятельность требуют поддержания в голове целостной картины всей системы, что влечет за собой огромные издержки на контекстные переключения. Наш друг-разработчик утверждает, что стандартная рабочая неделя не очень подходит его привычному рабочему процессу, поскольку для него 16-часовой рабочий день в несколько раз продуктивнее, чем 8-часовой.

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

Он считает, что абсолютно бесполезно уделять подготовке материалов для книги меньше 90 минут, потому что первые полчаса уходят только на то, чтобы вспомнить, «на чем же я остановился». Эксперт в области планирования Кирк Прус из Питтсбургского университета поделился аналогичным личным опытом. «Если у меня есть только полчаса свободного времени, я лучше займусь простыми делами, поскольку первые 35 минут мне требуются, только чтобы осознать, что именно я хочу сделать, а потом у меня уже может и не остаться времени на это».

Знаменитое стихотворение Редьярда Киплинга «Если» заканчивается энергичным призывом к тайм-менеджменту: «Наполни смыслом каждое мгновенье, // Часов и дней неумолимый бег…»[21]

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

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

В 1960-е годы программисты задумались, как можно было бы автоматизировать процесс совместного использования ресурсов компьютера разными программами и пользователями. В воспоминаниях Питера Деннинга, ныне одного из ведущих экспертов в области компьютерной многозадачности (который тогда работал над своей докторской диссертацией в Массачусетском технологическом институте), это было удивительное время. Удивительное и полное неопределенности: «Как разделить основную память между множеством разных задач, когда одна из задач хочет расширить объем своей деятельности, другая, наоборот, – уменьшить, и они планируют взаимодействовать между собой, пытаясь украсть память, и тому подобное?.. Как управлять всем этим рядом взаимодействий? Никто понятия не имел».

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

Снова представим жонглера. Пока один мяч находится в воздухе, у жонглера есть достаточно времени, чтобы подбросить вверх остальные. Но если жонглер берет еще один лишний мяч, с которым он уже не успевает справиться? Он уронит не этот мяч, он уронит все. Вся система в буквальном смысле слова рушится. Как комментировал такую ситуацию Деннинг, «присутствие одной лишней программы привело к полному краху работы системы… Очевидная разница между этими двумя случаями вначале заставляет игнорировать интуитивное ощущение, что по мере добавления новых программ в перегруженную основную память начинается постепенная деградация деятельности компьютера». А вместо этого происходит катастрофа.

И если в случае с жонглером мы понимаем, что он просто не рассчитал силы и не справился, что может стать причиной такого финала для машины?

Здесь теория планирования пересекается с теорией кеширования. Вся суть кеша заключается в том, чтобы держать рабочий набор необходимых элементов в свободном доступе. Один из способов – хранить информацию, которую в данный момент использует компьютер, в быстрой памяти, а не на медленном винчестере. Но, если задаче требуется держать в поле зрения так много нюансов, что эта информация уже не помещается в объеме быстрой памяти, компьютеру приходится постоянно подкачивать данные в память и отправлять обратно на винчестер, вместо того чтобы выполнять реальную работу. Более того, когда вы переключаетесь между задачами, новое активное задание может пытаться освободить место для своего рабочего набора, вытесняя сегменты других рабочих наборов из памяти. Следующее задание, активированное вновь, будет снова возвращать части своего рабочего набора с жесткого диска и заталкивать их обратно в память, занимая места других наборов. Такая ситуация – когда задачи крадут место друг у друга – может и дальше усугубляться в системах, где существует иерархия кеша между процессором и памятью. По словам Питера Зилистра, одного из разработчиков диспетчера операционной системы Linux, «кеши уже достаточно разогреты для текущей загрузки, и, когда вы переключаетесь с задачи на задачу, вы в значительной мере лишаете сил все кеши. И это больно». В крайнем случае программа может работать ровно столько, сколько нужно, чтобы закачать необходимые элементы в память, прежде чем уступить место другой программе, которая будет активна до тех пор, пока не перепишет все эти элементы.

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

Пробуксовка – типичное состояние и для человека. Вы когда-нибудь испытывали желание немедленно прекратить делать все, чтобы просто получить возможность записать все, что вам необходимо сделать, но у вас не было на это времени? В этот момент вы начинали буксовать. Причина здесь та же, что и у компьютеров: каждая задача – это привлечение наших ограниченных когнитивных ресурсов. Когда необходимость помнить обо всем, что необходимо сделать, занимает все наше внимание или выстраивание очередности всех заданий занимает все время, которое мы должны потратить на их решение, или же ход наших мыслей постоянно прерывается, не позволяя нам обратить их в действия, наступает что-то вроде паники или паралича от гиперактивности. Это пробуксовка, и компьютеры о ней наслышаны.