Какой язык программирования наиболее часто используется в высокопроизводительных вычислениях? И почему? [закрыто]

25

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

Закрыто 6 лет назад .

Я полагаю, что много Фортрана используется в HPC, но не уверен, что это только по старым причинам.

Функции современных языков программирования, такие как сборка мусора или полиморфизм во время выполнения, не подходят для HPC, так как скорость имеет значение, поэтому не уверен, куда приходят C #, Java или C ++.

Есть предположения?

programming-languages

— Fanatic23
источник

9

C ++ не имеет сборщика мусора и не требует использования полиморфизма во время выполнения.

— Джейсон Бейкер

@Jason Мое намерение состоит в том, чтобы выяснить, какие возможности C ++ делают его убедительным аргументом в пользу HPC.

— Fanatic23

@ Fanatic23 - я понимаю. Просто хотел это отметить. :-)

— Джейсон Бейкер

1

@Fanatic Хотел бы я сказать «да», но у меня не так уж много ... У меня есть несколько ссылок, касающихся некоторых проблем производительности в .NET / функциональных языках. Возможно, вам удастся собрать воедино эти концепции, чтобы понять некоторые ограничения производительности: msdn.microsoft.com/en-us/library/0xy59wtx.aspx stackoverflow.com/questions/2909282/… msdn.microsoft.com/en -us / magazine / cc163329.aspx en.wikipedia.org/wiki/Just-in-time_compilation

— Рей Миясака

1

Я думаю, что если вам нужно действительно хорошее время отклика, вам нужна ОС реального времени, такая как QNX: en.wikipedia.org/wiki/QNX

— Рей Миясака,

11

Я видел много Java, используемого для HPC в областях, где (1) мало унаследованного кода и (2) время разработки и качество кода имеют значение. Типичные области применения - финансы, интеллектуальный анализ данных или биоинформатика.

Это действительно зависит от приложения (существует жизнь за пределами линейной алгебры), но производительность последних JVM часто находится на одном уровне с C-кодом. Иногда быстрее, когда JVM способна выполнять во время выполнения умные оптимизации, которые статические компиляторы (C, Fortran) не могут сделать. И определенно быстрее, когда много символических вычислений.

При фиксированном количестве времени на разработку программы полученный Java-код всегда быстрее, чем C-код. HPC в Java определенно имеет смысл, когда код разрабатывается или изменяется часто. Еще одной важной особенностью является мобильность кода на другом оборудовании.

Вы найдете ссылки в http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Что касается предположения Фортрана, что два адреса являются уникальными, мы работаем над инструментом статического анализа, который позволит проводить аналогичные оптимизации для кода на языках высокого уровня, но без бита «Плохие вещи могут случиться». Свяжитесь со мной, если интересно.

14

Nitpick: JIT-оптимизации доступны для статических компиляторов, если вы готовы немного поработать. И GCC, и MS Visual Studio поддерживают профилированную оптимизацию, которая оптимизируется с использованием сохраненных данных времени выполнения. Это немного вводит в заблуждение, предполагая, что существуют оптимизации, "которые статические компиляторы (...) не могут сделать".

— Корбин Март

4

Я не знаю, почему это принятый ответ, в этом посте нет ничего подобного правде. Языки на основе C всегда будут превосходить Java, так как Java - это виртуальная машина, которая по своей природе основана на другом языке. Кроме того, все, что вы можете достичь в Java, вы можете достичь в C с меньшими затратами. Языки на основе Си никогда не перестанут быть языком «исполнителей».

— Майк

31

В моем многолетнем опыте, до 5 лет назад, это всегда были Fortran и C. В основном это зависело от того, пришли ли люди больше из инженерии или больше из школы мысли CS (я не знаю, как это лучше сказать) окей? :-)

В том, что мы делали, Фортран использовался почти исключительно.

Из того, что я читал сегодня, с новыми обновлениями к стандарту F2003 / 08 и с появлением Co-массивов, кажется, что он снова набирает обороты.

Кроме того, одна, если не несколько предвзятая статья - Идеальный язык программирования HPC

— ладья
источник

16

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

Кроме того, выравнивание массивов, строки кэша и границы SSE / AVX важны для генерации и выполнения эффективных циклов. Если массивы передаются через общие блоки, компилятор / загрузчик может гарантировать, что все массивы начинаются с одинаковых границ выравнивания адресов, и можно использовать более эффективные загрузки и сохранения SSE / AVX. Более новое оборудование может обрабатывать невыровненные обращения к памяти, но поскольку доступ к памяти не выровнен должным образом, частичное использование строк кэша приводит к снижению производительности. Даже если программист C правильно выровняет все свои массивы, существует ли механизм для передачи этого компилятору?

Подводя итог, можно сказать, что двумя наиболее важными вопросами являются независимость адресов памяти и признание компилятором того, что структуры данных, к которым осуществляется доступ, имеют такое же «естественное» выравнивание, которое требуется аппаратному обеспечению. Пока что Фортран лучше всех справляется с этими двумя задачами.

— Омега Центавра
источник

2

Недавно я провел небольшой эксперимент, чтобы найти число всплывающих строк в 64000 бит, представленных в виде длинного массива без знака. Я использовал точно такой же алгоритм, используя множество интересных логических и упакованных арифметических вещей. В C с -O3 это заняло 10 часов в длину, тогда как у Fortran Intel Fortran 10.1 с оптимизацией по умолчанию это было 6,5! И каждый программист думает, что C лучше всего подходит для битов! Допущения Fortran по умолчанию позволяют безопасно генерировать более эффективное кодирование команд низкого уровня.

— Омега Центавра

4

Это должно гласить: «Правила де-факто в Фортране позволяют компилятору предполагать, что два адреса уникальны ...». Все руководства говорят вам, что компилятор может это допустить, и предупреждают вас В ДЕТАЛЯХ, что плохие вещи могут случиться, если вы нарушите это предположение.

— Джон Р. Штром

15

Просто какая-то анекдотическая заметка. Я сам не делал высокопроизводительных вычислений.

Для вычислений (подсчет чисел), Fortran и C. Да, это по старым причинам:

Широкая доступность исходного кода и рецептов общественного достояния.
Оба поддерживают MPI .
Оба языка скомпилированы.
Компиляторы для обоих языков предоставляются всеми операционными системами и поставщиками HPC.
Векторизованные компиляторы доступны.
И то, и другое требует сумасшедшего уровня настройки для достижения высокой производительности при портировании на другой кластер (другой объем памяти, количество процессоров и т. Д.)
- Это фактически объясняет, почему открытый исходный код важен: необходима настройка, поэтому оригинальный рецепт должен быть написан на языке, который подходит для ручной настройки.

Современная тенденция к сокращению чисел заключается в написании программных генераторов, которые автоматизируют настройку исходного кода для оптимизации производительности с учетом характеристик кластера. Эти генераторы часто выводятся в C.

Вторая тенденция - написать на каком-то специализированном диалекте C для конкретных графических процессоров или Cell BE.

Для нечисловой работы, такой как программы, которые обрабатывают данные из базы данных (но не самой базы данных), гораздо дешевле работать на кластерах «обычных» машин без дорогостоящего специализированного сетевого оборудования. Обычно это называется «высокопроизводительные вычисления». И Python является языком № 1 здесь (используя знаменитую Map Reduce). До Python проекты пакетной обработки могли быть написаны на любом языке и обычно отправлялись Condor .

— rwong
источник

1

Не могли бы вы немного рассказать о «сумасшедшем уровне настройки»?

— Ладья

Вычислительный центр нанимает аспирантов для перестановки вызовов MPI, чтобы он работал быстрее.

— rwong

(?) Первое слово здесь, но я думаю, что методы отличаются.

— Ладья

Это был исследовательский центр по моделированию климата.

— rwong

4

Я работал над ОЧЕНЬ интенсивным кодом на C #.

Я строю реализацию FDTD для оптического моделирования в GPGPU . На небольшом кластере (128 процессоров) многим нашим симуляциям требуются недели. Реализации GPU, однако, имеют тенденцию работать примерно в 50 раз быстрее - и это на плате NVidia потребительского уровня. Теперь у нас есть сервер с двумя двухпроцессорными картами GTX295 (несколько сотен ядер), и мы скоро получим немного Teslas.

Какое это имеет отношение к вашему языку? Так же, как код FDTD C ++, который мы использовали ранее, был привязан к процессору, он привязан к графическому процессору, поэтому ( очень небольшая) разница в лошадиных силах управляемого и нативного кода никогда не вступает в игру. Приложение C # действует как проводник - загружая ядра OpenCL, передавая данные в и из графических процессоров, обеспечивая пользовательский интерфейс, отчеты и т. Д. - все задачи, которые являются проблемой в C ++.

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

Кроме того, большая часть различий в производительности будет зависеть не от выбора языка, а от мастерства вашего разработчика. Несколько недель назад я переместил одну операцию деления изнутри цикла с тройным вложением (обход трехмерного массива), что сократило время выполнения для данной вычислительной области на 15%. Это результат архитектуры процессора: медленное деление, которое является одним из тех лиц, которые вам просто нужно где-то заметить.

— 3Dave
источник

1

С ++ имеет объектную модель? Но, похоже, вам следовало бы использовать язык сценариев для написания своих контроллеров - если C # лучше, чем C ++ из-за скорости разработки, то python (или lua и т. Д.) Также лучше, чем C #.

— gbjbaanb

3

@gbjbaanb Не обязательно. Эта реализация привязана к GPU, но переход на язык сценариев может очень легко это изменить. C # скомпилирован и имеет очень хороший оптимизатор. Скомпилированные, строго типизированные языки - ваши друзья! Менее строгие скриптовые языки приводят к увеличению времени разработки любого достаточно сложного проекта.

— 3Dave

1

Прошло семь лет. Я многому научился. C ++ - это круто, C # - тоже круто, мне действительно нравится python и: CPU все еще имеет значение.

— 3Dave

3

Фортран является наиболее распространенным, прежде всего из-за унаследованного (люди все еще используют старый код) и фамильярности (большинство людей, которые используют HPC, не знакомы с другими типами языков).

Функции современных языков программирования, такие как сборка мусора или полиморфизм во время выполнения, не подходят для HPC, так как скорость имеет значение, поэтому не уверен, куда приходят C #, Java или C ++.

Это не так в целом. Классическая HPC в основном делала линейную алгебру с числами машинной точности. Однако современные HPC все чаще используют суперкомпьютеры для более широкого спектра задач, таких как символьные вычисления с произвольными математическими выражениями вместо чисел точности машин. Это накладывает совершенно разные характеристики на инструменты, которые вы используете, и нередко использовать языки программирования, отличные от Fortran, потому что символические вычисления могут быть непомерно трудными без GC и других видов оптимизирующего компилятора, таких как OCaml, оптимизирующий компилятор сопоставления с образцом.

Например, прочитайте эту статью Fischbacher et al. в котором говорится, что «у авторов есть веские основания полагать, что это, возможно, самый большой символический расчет, выполненный до сих пор».

— Джон Харроп
источник

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

— Sharpie

3

Фортран, по некоторым хорошим и не очень хорошим причинам. Для сложного математического анализа хорошая причина в том, что существуют обширные библиотеки (BLAS, LAPACK) проверенных и проверенных подпрограмм, все они написаны на Fortran (хотя их можно вызывать из C и C ++).

Не очень хорошая причина - предполагаемое преимущество производительности Fortran над C / C ++. Оптимизаторы очень хороши, и мало кто понимает, что выгода от оптимизации фрагмента кода пропорциональна проценту времени, которое он занят, что почти во всем коде практически равно нулю.

Другая не очень хорошая причина - культурный разрыв между программистами CS и не CS. Научных программистов, как правило, учат вредным привычкам на Фортране, и они смотрят свысока на программистов CS и на вредные привычки, которым их учили, и которые смотрят свысока на первое.

— Майк Данлавей
источник

«Культурный разрыв между программистами CS и не CS. Научных программистов, как правило, учат вредным привычкам на Фортране, и они смотрят свысока на программистов CS и на вредные привычки, которым их учили, и которые смотрят свысока на первых». Отчасти это только потому, что они концентрируются на разных аспектах проблемы. Фортран означает FORmula TRANslation, и он довольно эффективен для перевода математических формул в код. Для видов программирования, которые обычно делают типы CS, лучше использовать другие языки.

— Омега Центавра

1

@ Омега: Ты прав. Преподаваемые на Фортране люди, как правило, не имеют понятия о форматировании, ненавидят «неявное нет» и собирают код вместе, потому что они все еще имеют дело с 72-символьными строками и думают, что создание понятного кода - для слабаков. Люди, обученные CS, создают монстра-пирамиды классов, в которые входят полиморфизмы, уведомления и абстракции, когда что-то простое сделает эту работу. Таким образом, они заслуживают друг друга :)

— Майк Данлавей

7

Раньше цитата заключалась в том, что «физики решают проблемы завтрашнего дня на оборудовании вчерашнего дня - в то время как ребята из CS решают проблемы вчерашнего дня на оборудовании завтрашнего дня»

— Мартин Беккет,

@Martin: я думаю, может быть, я где-то слышал. Это конечно звучит правдоподобно.

— Майк Данлавей

Мартин: Итак, ребята из аппаратного обеспечения самые эффективные :)

— Дайват Пандья

2

По сути, все программы, которые выполняют фактическую обработку чисел, по-прежнему являются Фортраном (старые бла, лапак, арнольди и т. Д. Все еще используются) ... Однако, когда речь идет о структуре более высокого уровня ... люди все чаще используют C ++.

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

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

1

Существует два вида проблем, которые необходимо решать в приложениях HPC: одна - это само вычисление числа, а другая - управление вычислениями. К первому обычно подходит код, написанный на Fortran, C или C ++, из-за скорости и из-за того, что на этих языках уже написано много научных алгоритмов. Управление вычислениями более удобно реализовано на языках более высокого уровня. Python является предпочтительным языком для обработки логики приложения и вызова расширений, реализованных на скомпилированных языках. Java часто используется проектами, в которых управление сетью и распределенными вычислениями имеет важное значение.

— J ..
источник