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

56

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

— drjrm3
источник

12

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

— Фахим Митха

2

Ответы на этот вопрос будут почти чисто субъективными, и поэтому я не уверен, что этот вопрос уместен.

— Джефф

62

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

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

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

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

— khinsen
источник

17

«Всегда помните, что ваше время более ценно, чем процессорное время!» Как человек, который работает в HPC, я не согласен с этой частью; все остальное на месте.

— Леви Моррисон

19

«Всегда помните, что ваше время более ценно, чем процессорное время!» Как человек, занимающийся научными исследованиями, я не мог больше согласиться с этой частью.

— Decvalts

3

«Всегда помните, что ваше время более ценно, чем процессорное время!» - Я хотел бы добавить свои 2 цента - использование нескольких сотен узлов, каждый с 10+ ядрами, для запуска какой-либо программы в течение нескольких недель может быть истолковано как ужасная трата самого ценного ресурса, если еще пара недель может произвести код, который запускается всего за пару дней. Эти кластеры HPC являются редким и дорогим общим ресурсом.

— Dani_l

«Всегда помните, что ваше время более ценно, чем процессорное время!», Используйте код на неделю, но выполняйте на месяц, сэр!

— Fronthem

6

«Всегда помните, что ваше время более ценно, чем процессорное время!», Я бы предпочел писать код в течение месяца и запускать через неделю! - больше можно сделать после того, как код написан, и другие найдут код, который вы пишете, более полезным.

— Чарльз

37

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

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

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

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

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

— Ондржей Чертик
источник

1

Один за первый ответ, будучи сбалансированным. Я думаю, что C ++ и Fortran - далеко не единственные возможности в современном HPC. Я думаю, что хорошо знать сильные и слабые стороны, когда вы выбираете Fortran, C ++ или Python (или все, что вам нравится). Я видел 20 000 строк Фортрана в одном файле, органически выращенных за несколько десятилетий. Лично я бы не стал использовать ничего, кроме изолированных тяжелых массивов. Даже для всего, что связано с выходом. Пока что за предвзятый комментарий.

— Шухало

6

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

— Билл Барт

6

Билл, ты использовал современный Фортран (90 и более поздние дополнения?). Это очень важно (я должен был быть более ясным в своем ответе об этом). Конечно, "20.000 строк Фортрана", или f77, обычно не лучше, чем хорошо написанный C ++.

— Ондржей Чертик

1

@ OndřejČertík: Я думаю, что если вы считаете, что современные программы с конечными элементами используют «простые» структуры данных, то вы не рассматривали ни одну из них в последнее время. Попробуйте реализовать адаптивные конечные элементы, методы hp или мультисетки в неструктурированных сетках с использованием простых структур данных. С Биллом все в порядке, и я думаю, что могу сказать за него, сказав, что использование «современного Фортрана» имело бы чуть больше, чем небольшую разницу.

— Вольфганг Бангерт

6

@WolfgangBangerth, см., Например, Phaml ( math.nist.gov/phaml ) для реализации на Фортране почти всего, что вы упомянули.

— Ондржей Чертик

31

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

Обратите внимание, что я буду говорить о 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, потокам, сетям и т. Д.

— Pedro
источник

5

Хороший ответ. Однако я не думаю, что ваш последний комментарий обязательно верен. Я сам программист на Си, но вы получаете доступ к низкоуровневым вещам на Фортране благодаря хорошей практике программирования. Идеальный способ использовать такие вещи, как SIMD ops, - это написать код, который настоятельно рекомендует это (например, блокировать циклы), и позволить компилятору сделать это за вас. Для многопоточности просто используйте openMP (pthreads также можно использовать с дополнительной работой). У Fortran есть все, о чем вы упоминаете, но только на уровне, который важен для его обычного пользователя: числовой.

— Reid.Atcheson

@ Reid.Atcheson: Ну, если вы заблокируете все так, что компилятор его поймает, то он будет работать автоматически как в C, так и в Fortran. Проблема в том, насколько вы хотите доверять своему компилятору? И почему вы хотите доверять ему в тех случаях, когда вы точно знаете , что хотите сделать? OpenMP выполняет многопоточность, да, но по блокам. Вы можете обмануть его, заставляя разные пулы потоков выполнять разные задачи, но это просто неправильное использование OpenMP. Pthreads для Fortran - это просто оболочки для функций C. Я согласен, однако, что Фортран легче, если вы не в деталях.

— Педро

1

Конечно, вы не получите полноценной 99% пиковой эффективности, полагаясь на компилятор, но вы легко можете подойти довольно близко. Помимо этого вы должны либо использовать встроенные или встроенные ASM. Вы должны пойти на уступки где-то для общей эффективности программиста, поэтому языки программирования существуют в первую очередь. На той стадии, когда вы на самом деле достаточно безумны, чтобы вдаваться в подробности внутренней или ASM (я был несколько раз), Fortran не опора. Вы бы в любом случае знали, как связать ваш собранный вручную оптимизированный код.

— Reid.Atcheson

@ Reid.Atcheson: Ну, я бы сказал, что для параллельных приложений HPC вы можете оказаться намного ниже пиковой эффективности 99% ... А векторные типы gcc делают использование встроенных функций не проблемой :)

— Педро,

1

@Pedro, Блестящий пост. Абсолютно блестящий. Большое спасибо за публикацию. Просто нашел его, пока случайно перебирая интересные темы.

— Следствие

16

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

— Вольфганг Бангерт
источник

13

Мой подход состоял в том, чтобы использовать 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$ .

— Джек Полсон
источник

2

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

— Питер Брюн

1

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

— Джек Полсон

У меня такой же опыт с ключевым словом "restrict" (мой простой код на Fortran всегда был немного быстрее). Но мой опыт ограничен, и у меня просто нет времени вкладывать деньги в понимание сгенерированной сборки из gcc. Поэтому я просто использую Фортран, это просто и быстро.

— Ондржей Чертик

@JackPoulson: Аргумент компилятора - это то, что я немного слышу от сообщества Фортрана. К сожалению, большинство компиляторов, например, gcc или ifc / icc, используют разные языковые интерфейсы для одного и того же конца. Механизм, выполняющий оптимизацию и генерацию кода, идентичен, и поэтому различия в результатах, скорее всего, связаны с тем, что программист знаком с базовым языком ...

— Педро

1

Просто, чтобы дать некоторое представление о часто повторяемых, редко проверяемых утверждениях о том, что Fortran быстрее работает с числовыми ядрами: Некоторое время назад мы заметили, что умножение разреженных матриц-векторов в пакете Trilinos Epetra было на 30% медленнее, чем в deal.II. Первый был написан на прямом Fortran 77, последний на прямом C без использования «restrict». У обоих было около 10-15 строк кода. Сегодня Trilinos использует фрагмент кода, взятый из deal.II. Я уверен, что можно найти много случаев, когда F77 быстрее, чем C. Дело в том, что сегодня это не так универсально.

— Вольфганг Бангерт

8

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

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

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

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

— Джереми Коздон
источник

7

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

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

— МБк
источник

1

Обычно плохая идея применять низкоуровневые методы в языках высокого уровня. Например, STL предназначен для работы на очень абстрактном уровне. Нужно знать, для чего предназначен интерфейс, использовать его для этой задачи, а затем выходить из-под контроля компиляторов.

— Шухало

2

Я думаю, что баллы МБК и Мартина несправедливы. Да, есть способы выстрелить себе в ногу, если вы попытаетесь реализовать числовой вектор для целей линейной алгебры, используя std :: list <double>. Но это глупый аргумент: по крайней мере в C ++ есть класс связанного списка, который вы можете использовать, а в Fortran - нет. Это все равно что сказать: «Автомобили едут на такой высокой скорости, что вы можете врезаться в стену и получить травму; вместо этого вы должны использовать гужевые повозки». Это просто глупая идея громить язык высокого уровня , который также поддерживает материал низкого уровня (например , C ++) для имеющих функции высокого уровня.

— Вольфганг Бангерт

@WolfgangBangerth Нет, теперь вы наносите вред Фортрану - он настолько же «низкоуровневый», насколько бактерии «менее развиты», чем люди. Если вы хотите провести аналогию с автомобилем, это должно быть больше похоже на то, что «вы можете использовать как Jeep, так и Lexus, чтобы пересечь болотистое шоссе, но использование первого повредит меньше».

— Mbq

1

Я ценю ваше мнение, но я утверждаю, что Fortran не так развит, как C ++ :-)

— Вольфганг Бангерт

7

Три факта:

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

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

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

— Андреас Клёкнер
источник

Привет, Андреас! CnD интересно, я не знал об этом. Ах, ты написал это. :) (f90 также поддерживает нарезку, выделяемую для массивов и, самое главное, синтаксис массива для умножения, сложения и т. д.) Я использую CMake с Fortran, и он прекрасно работает с модулями. Что такое «список аргументов»? Я не думаю, что я использую их, поэтому только 3 места необходимо изменить. В C обычно требуется изменить реальный код, параметры и заголовочный файл, так что это также 3 места (наиболее определенно в C ++). Да, передача () не очень хорошая, но на практике она вам обычно не нужна.

— Ондржей Чертик

3

Рефакторинг современного фортрана тривиален с правильными IDE, такими как Photran в затмении.

2

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

— Владимир Ф

1

Просто хотел добавить к тому, что @ user389 сказал, что, хотя Photran великолепен и является единственной интегрированной средой разработки Fortran, которая допускает рефакторинг, его синтаксический анализатор все время терпит неудачу. С другой стороны, нет необходимости комментировать тот факт, что Eclipse требует много памяти.

— astrojuanlu

5

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

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

— Дэниэл Стендж
источник

Верно. Для разбора текста я также использую Python.

— Ондржей Чертик

Вы также можете реализовать часть скрипта Python на скомпилированном языке, например C ++, и подключить его. Например, Boost Python, Swig и т. Д.

— Faheem Mitha

4

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

— Tangurena
источник

4

Извините за то, что выкопал старую ветку, но кажется, что даже в 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, я подумал, что стоит упомянуть об этом.

— Stali
источник

3

Я не согласен, потому что мой опыт работы в национальных лабораториях, во всяком случае, был противоположным. Большинство новых проектов, которые я вижу в Лоуренсе Ливерморе, написаны на C ++, а большинство новых (или активно поддерживаемых) современных библиотек с открытым исходным кодом в решателях ODE, дискретизации FEM и универсальных научных вычислительных библиотеках. похоже на C или C ++. Fortran, кажется, в основном используется в проектах, которые используют существующие / унаследованные библиотеки; Я не вижу много больших новых проектов, использующих Фортран, независимо от того, что я думаю о языке.

— Джефф Оксберри

Некоторые коды теории функционала плотности, также написанные на Фортране, включают VASP и CASTEP , хотя, как указывает @GeoffOxberry, новые проекты, возможно, склоняются к C ++.

— dr.blochwave

@blochwave Как вы можете прочитать по ссылке, проекты предназначены для новой машины (с ускорителями и т. д.), которая появится в сети в 2018 году. Поэтому не то, чтобы они взяли 25-летний код и скомпилировали его, надеясь запустить его на хорошем уровне. представление. Я уверен, что большие части кодов в приведенном выше списке были или были переписаны, как в новом коде. Ряд «новых» климатических кодов также есть в Фортране и используется многими агентствами в ряде стран.

— Стали

0

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

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

— Роберт ван де Гейн
источник