Перейти на параллельное кодирование

мы все пишем код для одного процессора. Интересно, когда мы все сможем писать код на многопроцессорных системах?

что нам нужно (программные средства, логика, алгоритмы) для этого переключения?

edit: на мой взгляд, поскольку мы выполняем многие задачи параллельно, так же, как нам нужно преобразовать эти реальные решения (алгоритмы) в компьютерный язык. точно так же, как кодирование ООП сделало для процедурного кодирования. ООП - это более реальный стиль кодирования, чем процедурный. так что я надеюсь на такие решения.

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
4
0
431
7

Ответы 7

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

на мой взгляд, поскольку мы выполняем многие задачи параллельно, нам нужно преобразовать эти реальные решения (алгоритмы) в компьютерный язык. точно так же, как кодирование ООП сделало для процедурного кодирования. ООП - это более реальный стиль кодирования, чем процедурный. так что я надеюсь на такие решения.

K. Santosh 18.09.2008 09:47

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

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

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

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

К сожалению, для массового параллельного программирования - если не будет прорыв в компиляторах, чтобы помочь, мы выбросим многое из того, что мы знаем об алгоритмах (я думаю, что Дон Кнут даже сказал это). Прочтите об Erlang, чтобы увидеть это возможное будущее.

Нам нужны естественные абстракции для алгоритмов с высокой степенью параллелизма. Актеры (подумайте: Erlang) прошли долгий путь в этом направлении, но они не являются универсальным решением. Некоторые более конкретные абстракции, такие как fork / join или map / reduce, еще проще применить к общим проблемам.

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

Кстати, что касается абстракций параллелизма, Clojure имеет несколько очень интересных особенностей в этом направлении. Он не только имеет своего рода акторов, но также определяет модель транзакционной памяти (думаю: базы данных) вместе с глобальным механизмом атомарных ссылок. Эти две функции позволяют параллельным операциям совместно использовать "изменяемое" состояние, не беспокоясь о блокировках или условиях гонки.

В конце концов, все сводится к образованию. Большая часть необходимой теоретической работы по абстракциям параллелизма уже проделана, нам просто нужно принять это. К сожалению, как доказывают Эрланг и Хаскелл, иногда лучшие идеи остаются отнесенными к крайне маргинальным слоям населения. Надеюсь, что такие усилия, как Scala и Clojure, позволят вывести более продвинутые абстракции в мейнстрим, внедрив их на существующую хорошо поддерживаемую платформу (JVM).

Самое важное требование - уметь разбить проблему на более мелкие, которые можно решить независимо друг от друга. Как только вы определитесь, как вы собираетесь это сделать, будет легче подумать обо всем остальном и задать дополнительные вопросы по реализации (например, «части моих расчетов зависят от других частей - как мне дождаться их завершения?» ) стать конкретными, конкретными вещами, о которых вы можете исследовать или спросить здесь.

Есть несколько популярных или набирающих популярность инструментов / языков. Если вы используете FORTRAN, C или C++, вы можете использовать библиотеки OpenMP (не слишком сложно реализовать) или библиотеки Интерфейс передачи сообщений (MPI) (мощный и самый высокий потенциал ускорения, но также сложный и трудный). OpenMP использует директивы препроцессора для обозначения областей, которые можно распараллелить, особенно циклов. MPI использует сообщения, которые передают данные между процессами, и самая большая трудность заключается в том, чтобы все было синхронизировано, не затрагивая узкие места и не заставляя процессы ждать. Однако я бы сказал, что MPI определенно выходит из строя. В научных кругах, занимающихся высокопроизводительными вычислениями, стало ясно, что ускорение редко стоит дополнительного времени на разработку.

Что касается новых языков, ознакомьтесь с Крепость. Он все еще разрабатывается, но цель состоит в том, чтобы создать язык, еще более простой для научных вычислений, чем FORTRAN. Программы будут указаны с использованием математического синтаксиса очень высокого уровня. Вдобавок параллелизм будет неявным; программисту придется работать, чтобы делать что-то последовательно. Кроме того, он поддерживается Sun и основан на java, поэтому он будет портативным.

для java теперь вы можете обратиться к Parallel Java Library или DPJ (детерминированная параллельная Java!) Это окажет вам большую помощь в извлечении параллелизма из кода !!

Другие вопросы по теме