На пути к многопроцессорности

Путь разработчиков к новым возможностям весьма тернист

Разработчикам приложений и покупателям персональных компьютеров стоит обратить внимание на планы Intel, представленные широкой общественности в начале июля. Речь идет о намерении корпорации включить в перспективные мобильные версии процессора Pentium 4 поддержку гиперпотоковости.

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

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

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

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

Таким образом, перед создателем процессора возникает дилемма: скомпоновать ядра процессора по схеме "2ґ2", выделив каждому из них определенное время работы или занять всю рабочую площадь одним-единственным, но более сложным процессором, у которого будет вчетверо больше фундаментальных ресурсов, но и сигналы будут пересылаться в два раза медленнее. С учетом того, что можно добиться параллелизма задач, преимущество остается на стороне многопроцессорной схемы, так как она способна вести обработку в два раза быстрее.

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

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

Побочные эффекты возникают из-за того, что в процессе вычислений значения переменных постоянно меняются, что делает просто невозможным параллельное ведение расчетов: выходные данные перекрещиваются и начинают зависеть друг от друга. Остроумные решения этой проблемы можно найти в экзотических языках программирования - Butterfly LISP, например, предлагает специальную структуру данных под названием future. В ней используются метки - заполнители данных, которые могут передаваться для обработки на следующий этап даже в том случае, если значение еще не определено.

Вторая проблема - узости последовательного обмена - проявляется, когда наступает черед объединения результатов параллельной обработки. Если 20% всех вычислительных операций производится на последовательных этапах, любое распараллеливание на других этапах, даже при бесконечно большом количестве процессоров, не в состоянии дать более пятикратного прироста общей производительности. Единственный выход - менять весь алгоритм обработки.

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

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

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

     С технологическим редактором Питером Коффи можно связаться по адресу peter_ coffee@ziffdavis.com.