Ответ 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.