С ++ против Фортрана для HPC

В моей программе PhD по вычислительной технике мы работаем почти исключительно на C ++ и Fortran. Кажется, некоторые профессора предпочитают одного другому. Мне интересно, какой из них «лучше» или один лучше другого в определенных обстоятельствах.

Как и часто, выбор зависит от (1) проблемы, которую вы пытаетесь решить, (2) ваших навыков и (3) людей, с которыми вы работаете (если это не сольный проект). Я пока оставлю (3) в стороне, потому что это зависит от индивидуальной ситуации каждого.

Зависимость проблемы: Fortran выделяется при обработке массива. Если ваша проблема может быть описана в терминах простых структур данных и, в частности, массивов, Fortran хорошо адаптирован. Программисты на Фортране используют массивы даже в неочевидных случаях (например, для представления графов). C ++ лучше подходит для сложных и высокодинамичных структур данных.

Зависимость от навыков: для написания хороших программ на C ++ требуется гораздо больше опыта программирования, чем для написания хороших программ на Fortran. Если вы начинаете с небольшим опытом программирования и имеете так много времени, чтобы изучить этот аспект своей работы, вы, вероятно, получите лучшую отдачу от инвестиций в изучение Fortran, чем изучение C ++. Предполагая, конечно, что ваша проблема подходит для Фортрана.

Однако в программировании есть нечто большее, чем просто Fortran и C ++. Я бы порекомендовал всем, кто занимается вычислительной техникой, начинать с динамического языка высокого уровня, такого как Python. Всегда помните, что ваше время более ценно, чем время процессора!

Я думаю, что и C ++, и Fortran достаточно хороши и работают хорошо.

Однако я думаю, что Fortran лучше подходит для числовых научных вычислений, для алгоритмов, которые могут быть выражены с использованием массивов и не нуждаются в других сложных структурах данных, поэтому в таких областях, как конечные различия / элементы, решатели PDE, вычисления электронных структур. Фортран - это предметно-ориентированный язык. В частности, я думаю, что ученый (не обязательно специалист по информатике) легче пишет быстрые программы на фортране, чем на C ++.

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

Можно также написать алгоритмы для массива на C ++, но, по моему опыту, это требует гораздо больших знаний в области компьютерных наук и в целом большей работы (т.е. нужно создавать или повторно использовать классы для манипулирования массивами, а также для управления памятью вручную или с помощью некоторых Библиотека, как Teuchos из Трилино). Неэксперты, как правило, пишут довольно хорошие программы на Фортране, но ужасные программы на С ++ (говорит по собственному опыту).

Отказ от ответственности: лично мне очень нравится Фортран, и я предпочитаю его C ++ для числовых вычислений. Я потратил более 2 лет на программирование на C ++ ежедневно и почти год на программирование на современном Fortran ежедневно (в области конечных элементов). Я тоже использую Python и Cython.

Я также выбрасываю свои два цента вроде как поздно, но я только что видел эту ветку и чувствую, что для потомков есть несколько моментов, которые нужно отчаянно сделать.

Обратите внимание, что я буду говорить о C, а не о C ++. Почему? Ну, в противном случае это яблоки и апельсины, чтобы сравнить полноценный динамически типизированный объектно-ориентированный язык с чем-то более статичным, чем Fortran. Да, некоторые современные реализации последних стандартов Фортрана могут сделать больше, чем просто, но на самом деле очень немногие используют их, и поэтому, когда мы говорим о Фортране, мы думаем о простом, статичном и императивном языке. Вот где C тоже, поэтому я заменил C на C ++ для следующего.

Прежде всего, любое обсуждение Fortran / C, имеющего лучшие компиляторы, является спорным. Выделенные компиляторы C / Fortran остались в прошлом. И gcc / gfortran, и icc / ifc - это просто разные интерфейсы для одного и того же бэкэнда, то есть ваша программа будет преобразована в абстрактное описание фронтэндом, а затем оптимизирована и собрана бэкэндом. Если вы пишете семантически один и тот же код на Fortran или на C, компилятор в обоих случаях создаст одну и ту же сборку, которая будет работать так же быстро.

Теперь это приводит ко второму пункту: почему мы все еще видим различия? Проблема в том, что большинство сравнений сделаны программистами на Фортране, которые пытаются что-то сделать на С или наоборот. Когда-нибудь замечали, как большинство авторов или поэтов предпочитают писать на своих родных языках? Хотите писать стихи на языке, на котором вы не чувствуете себя полностью уверенно или дома? Конечно нет ... Я сам считаю C своим "родным" языком программирования. Однако я также провел три года, работая в группе, в которой использовался только Фортран, в которой я достиг определенного уровня беглости. Я бы, однако, никогда ничего не писал сам по себе на Фортране, так как мне больше нравится C, и, как следствие, полученный код будет лучше , независимо от того, как вы это определяете.

Так что главное отличие в программисте, а не в языке. Так нет различий? Ну, не совсем. Вот несколько примеров:

• SIMD: будь то SSE, SSE3 или AltiVec, если вы хотите использовать их в Fortran, вам лучше надеяться и молиться, чтобы компилятор угадал именно то , что вы хотите, и сделает это. Удачи. В Си у вас обычно есть встроенные функции для каждой архитектуры или, в последнее время, общие SIMD векторные типы в gcc . Большинство компиляторов Фортрана будут использовать только SIMD-инструкции для развертывания циклов, но если у вас есть ядро, которое работает с короткими векторами данных неочевидным образом, компилятор, скорее всего, его не увидит.

• Различные аппаратные архитектуры: вся архитектура CUDA построена вокруг ядер на C. Да, у Portland Group теперь есть и Fortran-компилятор с поддержкой CUDA , но он коммерческий и, что самое важное, не от NVIDIA. То же самое касается OpenCL, для которого лучшее, что я смог найти, - это недавний проект, который поддерживает только несколько основных вызовов.

• Параллельное программирование: Да, и MPI, и OpenMP прекрасно работают как с C, так и с Fortran. Однако, если вам нужен реальный контроль над вашими потоками, т. Е. Если у вас есть полностью динамическое вычисление с разделяемой памятью, вы не сможете использовать Fortran. В C у вас есть стандартные pthreads, которые, хотя и не теплые и нечеткие, все равно проведут вас через шторм. В целом, большинство вычислений, которые полагаются на доступ к операционной системе, например потокам, процессам, файловой системе и т. Д., Лучше обслуживать с помощью C. О, и не пытайтесь создавать свои собственные сети с помощью Fortran.

• Удобство использования: Fortran ближе к Matlab, чем C. После того, как вы освоили все ключевые слова и способы объявления переменных, остальная часть кода выглядит как Matlab, что делает его более доступным для пользователей с ограниченным опытом программирования.

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

Это все немного странные вещи низкого уровня, но мы говорим об высокопроизводительных вычислениях, верно? Если вас не интересует, как наилучшим образом использовать базовые аппаратные парадигмы, то есть реализацию и / или разработку алгоритмов, которые лучше всего подходят для совместно используемой / распределенной памяти, потоков, векторизации SIMD, графических процессоров с использованием SIMT и т. Д., То вы просто занимаюсь математикой на компьютере.

Это длится намного дольше, чем все, что я задумал, поэтому вот краткое изложение - набор сообщений типа «забрать домой»:

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

Из моих 15 лет размышлений о научном программном обеспечении: если ваш код работает на 25% быстрее, потому что вы пишете его на Фортране, но на его написание у вас уходит в 4 раза больше времени (без STL, сложностей с реализацией сложных структур данных и т. Д.), Тогда Фортран выигрывает только в том случае, если вы тратите значительную часть своего дня на большие пальцы и ожидаете окончания вычислений. Учитывая, что почти для всех нас самое ценное - это наше время, вывод напрашивается так: используйте язык, который позволяет вам разрабатывать, отлаживать и тестировать ваш код быстрее, в разумных пределах, игнорируя, что он может быть медленнее, чем возможно, если Вы написали это на Фортране.

Мой подход состоял в том, чтобы использовать C ++ для всего, кроме вычислительных ядер, которые обычно лучше всего писать на ассемблере; это позволяет вам полностью оценить производительность традиционного подхода HPC, но позволяет упростить интерфейс, например, путем перегрузки вычислительных ядер, таких как SGEMM / DGEMM / CGEMM / ZGEMM, в одну подпрограмму, скажем Gemm. Ясно, что уровень абстракции можно поднять намного выше, избегая необработанных указателей и переключаясь на непрозрачные классы, но это хороший первый шаг.

Я считаю, что самым большим недостатком C ++ в подавляющем большинстве случаев является увеличение времени компиляции, но, по моему опыту, экономия времени на разработку более чем компенсирует это. Другим недостатком является то, что в компиляторах C ++ вендоров, как правило, больше ошибок, чем в компиляторах C и Fortran. В прошлом году, я думаю, я столкнулся с почти десятью ошибками в компиляторах C ++.

Учитывая все вышесказанное, я думаю, что отмена научных пакетов, написанных на языках низкого уровня (и Fortran), является нежеланием предоставлять удобные интерфейсы для сложных структур данных: большинство людей удовлетворены интерфейсом Fortran BLAS, так как он требует только указатели и ведущие измерения для описания матриц, но мало кто будет утверждать, что обычный 40-целочисленный интерфейс разреженного-прямого решателя Fortran является чем-то близким к удобному (ср. UHM, SuperLU, PETSc и Trilinos).

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

Обратите внимание, что этот пост привел к сравнению производительности C и Fortran на ядре$y := \alpha x + y$ .

Так как я здесь новичок, я просматривал старые вопросы и нашел этот. Надеюсь, это не табу, чтобы ответить на старые!

Поскольку никто другой не упомянул об этом, подумал я. Fortran 2003 почти полностью поддерживается большинством основных компиляторов (intel, ibm, cray, NAG, PCG), в том числе gcc с (в ближайшее время) новейшей версией 4.7. Fortran 2003 (и 2008) - объектно-ориентированный язык, хотя и немного более многословный, чем C ++. Одной из вещей, которая мне нравится в Fortran, является тот факт, что стандартный комитет рассматривает научные вычисления как основную аудиторию (я благодарю Дамиана Роусона за то, что он указал мне на это на днях).

Я говорю об этом не для того, чтобы программисты на С ++ стали программистами на Фортране, а для того, чтобы люди на Фортране знали, что теперь у них есть больше возможностей, кроме перехода на С ++ или эмуляции объектно-ориентированных концепций в Фортране 90/95.

Я хотел бы добавить еще одно предостережение о том, что стоит быть на переднем крае того, что реализовано в компиляторах. Если вы предпримете крупный проект в Fortran 2003 прямо сейчас, вы наткнетесь на ошибки и будете постоянно нуждаться в обновлении вашего компилятора (особенно если вы используете gcc), хотя это стало значительно лучше за последние несколько месяцев!

Проблема с C ++ заключается в том, что у вас есть множество шансов снизить производительность, например, слепо используя STL, исключения, классы (виртуальные издержки плюс проблемы с выравниванием), перегрузку операторов (избыточные новые / удаления) или шаблоны (нескончаемые компиляции и загадочные ошибки). кажется доброкачественным, но вы можете тратить часы таким образом).

Тем не менее, чем больше вы получаете лучший доступ к общим библиотекам и, возможно, лучшую видимость вашего кода (хотя это сильно зависит от области, и у вас все еще есть чистый C). И вы все еще можете компенсировать отсутствие гибкости Фортрана, оборачивая его код в язык сценариев, такой как R, Lush, Matlab / Scilab или даже Python, Ruby или Lua.

Три факта:

• N-мерные массивы в стиле F77 в C: нет проблем с использованием CnD (бесстыдный плагин, правда)

• Модульная система F90 плохо спроектирована и враждебна для создания среды. (Имя модуля не обязательно должно совпадать с именем файла, например)

• Fortran не поддерживает рефакторинг. Для извлечения некоторой функциональности из функции вам необходимо коснуться четырех мест: фактического кода, объявлений переменных, объявлений аргументов и списка аргументов. С обходится в двух местах. Это усугубляет эффект неспособности хорошо управлять данными (описано ниже): поскольку мелкомасштабная модульность очень болезненна, почти каждый пишет гигантские подпрограммы.

Одно личное впечатление:

• Фортран плохо работает для управления данными. Попробуйте вернуть указатель на непрозрачную для пользователя структуру данных в F77 или F90. ( transfer()вот и мы)

Fortran оптимизирован для вычислений массивов / матриц и является серьезной проблемой для работы с любым типом анализа текста. C и C ++ могут не совпадать с Fortran в числовых вычислениях (это близко), но я считаю, что гораздо проще обрабатывать текст и организовывать данные (т.е. пользовательские структуры данных) с C / C ++.

Как уже упоминали другие, не считайте динамически интерпретируемые языки (Python et al). Они могут не предлагать скорость фортана, но они позволяют вам больше сосредоточиться на решении вашей вычислительной задачи, чем на всех деталях реализации. Зачастую вы можете реализовать решение на Python, и, если производительность неприемлема, выполнить некоторое профилирование, определить проблемные области и либо оптимизировать этот код с помощью Cython, либо заново реализовать всю программу на скомпилированном языке. После того, как вы выработаете логику решения проблем, остальное - просто реализация, и при хорошем понимании основ вычислительной техники ее будет просто представить в любом разнообразии языков программирования.

В настоящее время я работаю в одной из национальных лабораторий. Большинство людей вокруг меня - инженеры-механики. Общаясь с некоторыми людьми из групп HPC, они в основном работают на Linux и в основном на C ++. Группа, в которой я сейчас работаю, в основном использует настольные приложения, и мы используем Windows в порядке убывания: C #, FORTRAN, Python, VBA и VB (6, а не .NET). Некоторые из используемых нами симуляторов были написаны в других национальных лабораториях на Фортране.

Извините за то, что выкопал старую ветку, но кажется, что даже в 2015 году Фортран часто используется.

Я только что наткнулся на этот (альтернативная ссылка ) список, который в основном представляет собой список из 13 кодов, утвержденных средством OCLF DOE для работы на машине 300-petaFLOPS Summit, которая будет доступна для исследователей в 2018 году. Я попытался найти основной используемый язык для кода (на основе быстрого поиска Google) и вот что я нашел:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Таким образом, из 13 кодов, по крайней мере, 10 (на основании моего быстрого поиска) написаны на фортране. Неплохо для 50-летнего языка.

ПРИМЕЧАНИЕ: я хорошо знаю, что сравнение языков бесполезно, но, учитывая количество людей (особенно пользователей C ++), которые плохо знают Fortran, я подумал, что стоит упомянуть об этом.

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

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