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

Joel on Software - О вреде многозадачности применительно к людям

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

Автор: Джоэл Сполски

Переводчик: Дмитрий Майоров

12 февраля 2001 г.

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

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

Предположим, что у вас есть две отдельных вычислительных задачи (A и B), которые нужно выполнить. Каждая задача требует для полного выполнения 10 секунд процессорного времени. В вашем распоряжении есть один процессор, и для упрощения будем считать, что других задач в очереди нет.

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

Последовательная обработка

Computation A	Computation B
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20

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

Многозадачность

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

В обоих случаях от момента начала вычислений до получения результата B (синий цвет) пройдёт 20 секунд.
Но посмотрите на задачу A. При использовании многозадачности с момента начала вычислений до получения её результата прошло 19 секунд... тогда как при последовательной обработке результат был готов через 10.

Иными словами, в этом удачно притянутом за уши примере среднее время меньше (15 секунд вместо 19.5) при последовательной обработке, чем при многозадачности. (Вообще-то этот пример не так уж сильно притянут -- он основан на реальной проблеме, которую Джареду пришлось решать на работе).

Метод	Задача A занимает	Задача B занимает	В среднем
Последовательно	10 seconds	20 seconds	15
Параллельно	19 seconds	20 seconds	19.5

Я сказал, что "время переключения пренебрежимо мало." Вообще-то на настоящем процессоре это какое-то время всё же отнимает... столько, сколько нужно для того, чтобы сохранить состояние регистров процессора одной задачи и загрузить значения для другой. На практике этим действительно можно пренебречь. Но чтобы усложнить себе немного жизнь, вообразим, что переключение между задачами занимает полсекунды. Теперь стало совем плохо:

Метод	Задача A занимает	Задача B занимает	В среднем
Последовательно	10 секунд	20 + 1 переключение = 20.5 секунд	15.25
Параллельно	19 + 18 переключений = 28 секунд	20 + 19 переключений = 29.5 секунд	28.75

Теперь... ладно, не смейтесь, я знаю, что это глупость ... что если переключения занимают целую минуту?

Метод	Задача A занимает	Задача B занимает	В среднем
Последовательно	10 секунд	20 + 1 переключениe = 80 секунд	45 секунд
Параллельно	19 + 18 переключений = 1099 секунд	20 + 19 переключений = 1160 секунд	почти 19 минут!

Чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Само по себе это не слишком революционная мысль, не правда ли? Скоро я стану получить злые письма от деятелей, обвиняющих меня в том, что я "против" многозадачности. Будут ехидно спрашивать "что, хочется обратно во времена DOS, чтобы обязательно выходить из WordPerfect, прежде чем запустить Lotus 1-2-3?"

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

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

б) чем дольше переключение между задачами, тем больше потери времени от многозадачности.

Хорошо, возвращаемся к более интересной теме управления людьми, а не процессорами. Особенность тут в том, что у программистов переключение между задачами происходит очень, очень, очень долго. Потому что это такое занятие, при котором приходится держать в голове много всякой всячины одновременно. Чем больше, тем быстрее движется работа. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются, даже название подкаталога, где живут исходники. Если послать этого программиста на три недели в отпуск на остров Крит, то он всё это забудет. Человеческий мозг, похоже, при первой возможности высвобождает оперативную память, сбрасывая её содержимое на ленту, откуда всё это потом очень долго доставать.

Насколько долго? Например, моя компания недавно на три недели бросила всё (а именно разработку программного продукта под кодовым названием CityDesk), чтобы выручить клиента, которому внезапно потребовалось наша помощь. Когда мы вернулись в контору, потребовалась почти неделя, чтобы набрать обычную скорость работы над CityDesk.

Вы лично никогда не замечали, что даешь человеку задание, и он его отлично выполняет, но даёшь два задания одновременно, и результат гораздо хуже? Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что улитки обгоняют. Это потому, что переключение между программистскими задачами происходит медленно. Если у меня на столе два проекта одновременно, то переключение отнимает часов шесть. При восьмичасовом рабочем дне остаётся два часа производительного времени. Негусто.

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

В английском оригинале статья называется Human Task Switches Considered Harmful

Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.

Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky

Содержание раздела