Журнал Компьютерра - Журнал «Компьютерра» №46 от 15 декабря 2005 года Страница 17

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

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

И наконец, никуда не деться в GRID-сетях от недоброжелательных пользователей (не зря же сейчас очень много делается для защиты информации). Ведь нам нужно как-то распределять и планировать во всей сети задания от всех ее пользователей, - и мало ли чего какой-нибудь Василий Пупкин мог туда запустить? Сегодня и без того вирусы, заражающие подключенные к Интернету компьютеры специальными троянами («зомбирование») и создающие целые «зомби-сети» из зараженных машин, готовых делать все, что заблагорассудится автору вируса (проводить ли распределенные DDoS-атаки или рассылать спам - неважно), представляют собой серьезнейшую угрозу, а тут - у любого человека появляется возможность посредством штатной системы рассылки распространить любой код на сотни и тысячи персоналок. И хотя эта проблема в принципе решаема (например, путем создания для выполняемых задач виртуальных машин - благо вскоре технологии аппаратной виртуализации , которые позволят это сделать без особого труда, станут штатной принадлежностью большинства новых компьютеров), то как защититься от банальной «шалости» в виде запуска бессмысленного кода (скажем, бесконечного цикла) и замусоривания им GRID-сети?

На самом деле все не так грустно, и многое в GRID-направлении уже сделано. Запущены и функционируют десятки проектов, использующих распределенные вычисления для научных и околонаучных целей; запущены и GRID-сети для «внутриуниверситетского» научного использования - в частности, CrossGrid, DataGrid и EUROGRID.

А вот здесь все очевидно и просто: фактически на протяжении последних пяти лет для кластерных вычислений существует один-единственный стандарт - MPI (Message Passing Interface). Программы, написанные с использованием MPI, абсолютно переносимы - их можно запускать и на SMP-машине, и на NUMA, и на любой разновидности кластера, и на GRID-сети, причем из любой операционной системы. Конкретных реализаций MPI довольно много (к примеру, каждый поставщик «фирменного» быстрого интерконнекта может предлагать свой вариант MPI-библиотеки для его решения), однако благодаря совместимости выбирать из них можно любой, какой вам приглянется (например, быстродействием или удобством настройки). Очень часто используется такой OpenSource-проект, как MPICH, обеспечивающий работу на более чем двух десятках различных платформ, включая самые популярные - SMP (межпроцессное взаимодействие через разделяемую память) и кластеры с интерконнектом Ethernet (межпроцессное взаимодействие поверх протокола TCP/IP), - если доведется когда-нибудь настраивать кластер, то начать советую именно с него.

На «классических» SMP-системах и некоторых NUMA’х реализация параллельных вычислений с использованием MPI заметно уступает по производительности более «аппаратно ориентированным» многопоточным приложениям, поэтому наряду с «чистыми» MPI-решениями встречаются «гибриды», в которых на кластере «в целом» программа работает с использованием MPI, но на каждом конкретном узле сети (а каждый узел кластера - это зачастую SMP-система) работает MPI-процесс, распараллеленный вручную на несколько потоков. Как правило, это гораздо эффективнее, но и гораздо труднее в реализации, а потому на практике встречается нечасто.

Как уже говорилось, можно выбрать практически любую операционную систему. Традиционно для создания кластеров используется Linux (более 70% систем Top 500) или другие разновидности Unix (оставшиеся 30%), однако последнее время к этому престижному рынку HPC (High Perfomance Computing) присматривается и Microsoft, выпустившая бета-версию Windows Compute Claster Server 2003[Бесплатно скачать эту бету можно здесь ], в состав которой включена микрософтовская версия библиотеки MPI - MSMPI. Так что организация «кластера своими руками» вскоре может стать уделом не только юниксоидов, но и их менее знающих собратьев-администраторов, да и вообще - значительно упроститься.

Напоследок скажем, что кластерные вычисления годятся далеко не для всяких задач. Во-первых, программы под кластерные вычисления нужно «затачивать» вручную, самостоятельно планируя и маршрутизируя потоки данных между отдельными узлами. MPI, правда, сильно упрощает разработку параллельных приложений в том плане, что в нем при понимании сути происходящего соответствующий код очень нагляден и очевиден, и традиционные глюки параллельных программ типа дедлоков или параллельного использования ресурсов практически не возникают. Но вот заставить получающийся код быстро работать на MPI бывает довольно трудно - зачастую для этого приходится серьезно модифицировать сам программируемый алгоритм. В целом нераспараллеливающиеся и труднораспараллеливающиеся программы на MPI реализуются плохо; а все остальные - более или менее хорошо (в смысле - масштабируются до десятков, а в «хорошем» случае - и до тысяч процессоров). И чем больше степень связанности кластера, тем проще извлекать из него выгоду от параллельной обработки данных: на кластере, связанном сетью Myrinet, программа может работать быстро, а на аналогичном кластере, где интерконнектом выступает Fast Ethernet, - попросту не масштабироваться (не получать дополнительного прироста производительности) сверх десяти процессоров. Особенно трудно получить какой-либо выигрыш в GRID-сетях: там вообще, по большому счету, подходят только слабо связанные задачи с минимумом начальных данных и сильным параллелизмом - например, те, в которых приходится перебирать значительное количество вариантов.

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

Terralab.ru: 19-дюймовый квартет

Автор: Платон Жигарновский

Еще пару-тройку лет тому назад на вопрос, какую модель монитора выбрать для дома, я отвечал не задумываясь: электронно-лучевую «семнашку» или «девятнашку» на трубе Mitsubishi M2 или M3. По качеству картинки ЭЛТ тогда сильно опережали ЖК, да и цена не шла ни в какое сравнение. Год-полтора назад я уже советовал лучших представителей 17-дюймовых ЖК. И этому тоже было объяснение: качество повысилось, цена стала куда деликатнее, да и экономия пространства была не лишней. Но вот на дворе конец 2005 года: техника на высоте, цены из-за конкуренции если и кусаются, то не так сильно, к тому же в преддверии Нового года хочется сделать себе и близким какой-нибудь подарок. И если этим подарком суждено стать монитору, какой же выбрать? Наверное, уже 19-дюймовый ЖК. С этой мыслью я взял наугад четыре модели от разных производителей и решил их быстренько просмотреть.

Данная модель является комбайном монитор + телевизор. Дизайн всегда был коньком Sony. Вот и на сей раз японцы явно не пожалели денег на внешнее оформление MFM-HT95. Серебристый корпус, матрица убрана под стекло, а панель с динамиками отклоняется от плоскости монитора по дуге вперед - в сумме все это очень радует глаз. Но еще больше радует, что начинка монитора ничем не уступает дизайну. В аппарате использованы 19-дюймовая матрица MVA с разрешением 1280х1024/60 Гц с откликом 16 мс (технология Overdrive пока не добралась до этой линейки) и хороший ТВ-тюнер, который даже при не слишком уверенном приеме сигнала обеспечивает приличное качество картинки.