UPC в HPC - опыт и предложения

В настоящее время я изучаю некоторые аспекты унифицированного параллельного C в качестве альтернативы к стандартным подходам к распараллеливанию в HPC (например, подходам MPI, OpenMP или гидратам).

Мой вопрос: У кого-нибудь есть опыт работы с UPC в широкомасштабных приложениях (~ > 10.000 ядер)? Меня в основном интересует скорость доступа к общей памяти. Очевидно, это зависит на базовом оборудовании, сетевом подключении, операционной системе, компиляторах и т.д. Но я меня вообще интересует любое решение "реального мира" с UPC.

Кроме того, каково ваше общее впечатление от UPC? Как вы думаете, у него есть потенциал для будущего будет более широко использоваться, чем сейчас? Стоит ли переходить на него?

Любые комментарии приветствуются!

Большое спасибо, Марк

Ответ 1

Есть плюсы и минусы в любом случае.

Преимущества UPC заключаются в том, что, вероятно, легче получить что-то работающее и с достойной производительностью, чем MPI или MPI + OpenMP. И поскольку (скажем) компилятор Berkeley UPC является открытым исходным кодом, вы сможете скомпилировать свою программу через 5 лет. Кроме того, поддерживающие языки, такие как UPC, требовали от IBM выиграть контракт с Blue Waters, поэтому должен существовать профессиональный компилятор UPC, который, по крайней мере, на протяжении всей жизни этой системы, что должно помочь экосистеме UPC оставаться активными.

Я лично не написал ничего действительно большого (с точки зрения размера кода или с точки зрения масштабирования до > 1k procs) в UPC, но в худшем случае вы можете запустить его с использованием среды выполнения MPI, и она должна масштабироваться как соответствующий MPI-код. Что касается меньших проблем, существует множество доказательств того, что производительность кодов, написанных на UPC (и других языках PGAS), безусловно, конкурентоспособна, а иногда и лучше, чем программа MPI, написанная аналогичным образом, и причины этого достаточно хороши понимать.

Недостатки в том, что, поскольку он новый, поддержка инструмента не такая сильная. Существует множество довольно сложных инструментов, свободных и коммерческих, для настройки производительности приложения с большим масштабом MPI, тогда как инструменты PGAS/GASnet/UPC являются более научно-исследовательскими, и это плохо. IBM, вероятно, работает над материалом для Blue Waters, но если вы не работаете в системе P7, это может не помочь вам в частности. Аналогично, параллельные библиотеки/инструменты ввода-вывода, по-видимому, не существуют в UPC в любой твердой форме.

Кроме того, с новым lanaguage всегда возникает беспокойство о том, насколько он будет продолжаться через N лет. Компиляторы должны работать, но будут ли новые рабочие среды продолжать разрабатываться и улучшаться для новых архитектур? Обратите внимание, что это всегда было уловкой-22 для новых языков научного программирования. Научные разработчики, как правило, очень консервативны, желая знать, что то, над чем они работают, будет продолжать работать (и работать хорошо) на 10+ лет в будущем, поэтому они склонны скептически относиться к долговечности новых языков, и что превращается в самопровозглашение пророчества, так как люди держатся подальше от новых языков, поэтому они томятся и становятся отказавшимися.

Я не думаю, что огромное беспокойство с UPC, потому что я думаю, что существует достаточная институциональная поддержка этих языков PGAS, что они будут вокруг какое-то время. Coarray Fortran является частью стандарта 2008 года, поэтому поставщикам компиляторов придется поддерживать поддержку, зависящую от PGAS. DARPA и т.д., Сильно отстает от языков PGAS-y или таких вещей, как X10/Chapel. Поэтому я думаю, что эти языки будут с большей вероятностью получить справедливый шанс на успех, и я думаю, что 5-10 лет ваш код все равно будет компилироваться и работать как минимум с неплохим успехом.

Мне интересны проблемы с архитектурой программного обеспечения вокруг UPC; Я не знаю, становятся ли новые общие массивы хорошими или плохими для разработки действительно больших частей программного обеспечения. Что-то вроде coarray fortran, который менее амбициозен, немного легче понять, как это происходит в большом пакете.

Итак, после всех этих абзацев, я боюсь, что ответ "зависит", и это, вероятно, будет доведено до вашего личного стиля и терпимости к риску. Если вам нравится быть на первом усыновителе, передовом, со всеми преимуществами (будь первым, кто воспользуется новыми, высокопроизводительными инструментами, перескакивая другими, будучи экспертом в новых материалах) и недостатками (недостаток сильная поддержка инструмента, повышенная степень риска, меньшее количество книг для перевода и т.д.), что подразумевает, я думаю, что UPC, вероятно, довольно солидный выбор. Базовая модель программирования будет работать хорошо, и этот язык, в частности, имеет хорошую поддержку. С другой стороны, если вы предпочитаете "играть в нее безопасно" и придерживаться подхода MPI + OpenMP, это тоже будет довольно оправданным выбором. Но, в конце концов, нам нужны некоторые разработчики, чтобы попробовать эти новые языки для реальных проектов, или мы, как сообщество, будем навсегда застрять с C/Fortran + MPI + OpenMP.

Ответ 2

Трудно ответить Джонатан Дурси, но я хотел добавить, что ваш выбор не обязательно должен быть/или. У вас могут быть оба. Джим Динан в Аргоннской национальной лаборатории продемонстрировал хорошие результаты с использованием MPI в качестве метода обмена сообщениями "off-w630" и UPC для частей node (разделяемой памяти).

См. "Гибридное параллельное программирование с помощью MPI и Unified Parallel C" Джеймс Динан, Паван Баладжи, Юинг Ласк, П. Садаяппан, Раджев Тхакур. Proc. 7-й ACM Conf. на вычислительных границах (CF). Бертиноро, Италия. 17-19 мая 2010 года.