UPC в HPC - опыт и предложения
В настоящее время я изучаю некоторые аспекты унифицированного параллельного C в качестве альтернативы стандартным подходам распараллеливания в HPC (например, подходы MPI, OpenMP или гидрид).
У меня вопрос: есть ли у кого-нибудь опыт работы с UPC в крупномасштабных приложениях (~>10.000 ядер)? В основном меня интересует скорость доступа к разделяемой памяти. Очевидно, это зависит от базового оборудования, сетевого подключения, операционной системы, компиляторов и т. Д. Но я, как правило, заинтересован в решении любых реальных проблем с помощью UPC.
Кроме того, каково ваше общее впечатление от UPC? Как вы думаете, у него есть потенциал для более широкого использования будущего, чем сейчас? Стоит ли переходить на него?
Любые комментарии приветствуются!
Большое спасибо, Марк
2 ответа
Есть плюсы и минусы в любом случае.
Преимущества UPC заключаются в том, что, вероятно, легче получить что-то работающее и с достойной производительностью, чем MPI или MPI+OpenMP. А поскольку (скажем) компилятор Berkeley UPC является открытым исходным кодом, вы сможете скомпилировать свою программу через 5 лет, независимо от этого. Вдобавок ко всему, поддержка таких языков, как UPC, была обязательным требованием для IBM, чтобы выиграть контракт Blue Waters, поэтому должен существовать профессионально поддерживаемый компилятор UPC, как минимум, для жизненного цикла этой системы, что должно помочь экосистеме UPC оставаться активной.,
Лично я не написал ничего действительно большого (с точки зрения размера кода или с точки зрения масштабирования до>1k процедур) в UPC, но в худшем случае вы могли бы запустить его с использованием среды выполнения MPI, и он должен масштабироваться как соответствующий Код MPI. Что касается более мелких проблем, существует множество дополнительных доказательств того, что производительность кодов, написанных на UPC (и других языках PGAS), безусловно, конкурирует, а иногда и лучше, чем с программой MPI, написанной аналогичным образом, и причины этого достаточно хороши. понят.
Недостатки в том, что, поскольку он новый, поддержка инструмента не так сильна. Существует множество довольно сложных инструментов, бесплатных и коммерческих, для настройки производительности крупномасштабного приложения MPI, в то время как инструменты PGAS/GASnet/UPC более плохие, чем исследовательские. IBM, вероятно, работает над вещами для Blue Waters, но если вы не работаете в системе P7, это может вам не особо помочь. Точно так же библиотеки / инструменты параллельного ввода / вывода, похоже, не существуют в UPC в какой-либо твердой форме.
Кроме того, с новым языком всегда есть беспокойство о том, насколько активным он будет оставаться N лет. Компиляторы должны работать, но будут ли продолжать разрабатываться и улучшаться новые среды выполнения для новых архитектур? Обратите внимание, что это всегда было главной новостью для новых научных языков программирования. Научные разработчики склонны быть очень консервативными, желая знать, что то, над чем они работают, будет продолжать (и работать хорошо) более 10 лет в будущем, поэтому они склонны скептически относиться к долговечности новых языков - и что превращается в самоисполняющееся пророчество, поскольку люди держатся подальше от новых языков, поэтому они томятся и становятся брошенными.
Я не думаю, что с UPC это вызывает серьезную обеспокоенность, потому что я думаю, что эти языки PGAS имеют достаточную институциональную поддержку, что они будут присутствовать некоторое время. Coarray Fortran является частью стандарта 2008 года, поэтому поставщикам компиляторов придется поддерживать PGAS-подобные среды выполнения независимо от того. DARPA и т. Д. Сильно отстают от языков PGAS-y или таких вещей, как X10/Chapel. Поэтому я думаю, что эти языки с большей вероятностью смогут добиться успеха, и я думаю, что через 5-10 лет ваш код все равно будет компилироваться и работать, по крайней мере, сносно хорошо.
Мне любопытно узнать о проблемах архитектуры программного обеспечения вокруг UPC; Я не знаю, будут ли новые общие массивы хорошими или плохими для разработки действительно больших программ. Что-то вроде coarray fortran, которое менее амбициозно, немного легче увидеть, как это разыгрывается в большой упаковке.
Так что после всех этих параграфов я боюсь, что ответ "это зависит", и, вероятно, все сводится к вашему личному стилю и терпимости к риску. Если вам нравится быть первопроходцем, обладать передовыми идеями, со всеми преимуществами (будьте первыми, кто воспользуется новыми, высокопроизводительными инструментами, обгоняет других, будучи экспертом в новых вещах) и недостатками (отсутствие сильная поддержка инструментов, более высокая степень риска, меньше книг, к которым можно обратиться и т. д.), что, по-моему, UPC, скорее всего, является довольно надежным выбором. Базовая модель программирования будет существовать довольно долго, и этот язык, в частности, имеет хорошую поддержку. С другой стороны, если вы предпочитаете "играть осторожно" и использовать подход MPI + OpenMP, это тоже будет вполне оправданным выбором. Но, в конце концов, нам нужно, чтобы некоторые разработчики попробовали эти новые языки для реальных проектов, или мы, как сообщество, навсегда застрянем с C/Fortran+MPI+OpenMP.
Сложно ответить на вопрос Джонатана Дурси, но я хотел бы добавить, что ваш выбор не должен быть ни / или. Вы можете иметь оба. Джим Динан в Аргоннской национальной лаборатории продемонстрировал хорошие результаты, используя MPI в качестве метода обмена сообщениями "вне узла" и UPC для частей на узле (совместно используемой памяти).
См. "Гибридное параллельное программирование с MPI и Unified Parallel C" Джеймс Динан, Паван Баладжи, Юинг Луск, П. Садайяппан, Раджив Тхакур. Proc. 7-я конференция ACM по вычислительным границам (CF). Бертиноро, Италия. 17-19 мая 2010 г.