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





Нет простого ответа, и во многих отношениях даже сложные ответы в настоящее время неадекватны или неполны. Вы получите лучший ответ, если будете более конкретны в том, какие ответы вам нужны: указатели на библиотеки и инструменты разработки, учебные материалы, указатели на текущие исследовательские проекты и проблемы в этой области или что-то еще?
Я думаю, что наиболее важным требованием является хороший язык, имеющий собственные конструкции, поддерживающие параллелизм, или язык, который может автоматически генерировать параллельный код. Есть довольно много языков, которые подходят под это описание, но ни один из них не является достаточно популярным, чтобы его можно было рассматривать для массового использования. Это, в свою очередь, вызвано несколькими причинами:
Конечно, если бы он был более популярным, больше людей захотели бы его изучить, и было бы больше поддержки, так что это своего рода цикл, из которого довольно сложно вырваться. Я думаю, все, что мы можем сделать, это надеяться. :)
Примером языка, разработанного с учетом сильного распараллеливания, является 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!) Это окажет вам большую помощь в извлечении параллелизма из кода !!
на мой взгляд, поскольку мы выполняем многие задачи параллельно, нам нужно преобразовать эти реальные решения (алгоритмы) в компьютерный язык. точно так же, как кодирование ООП сделало для процедурного кодирования. ООП - это более реальный стиль кодирования, чем процедурный. так что я надеюсь на такие решения.