Влияет ли появление архитектуры MultiCore на меня как на разработчика программного обеспечения?

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

Существуют ситуации, где Вы нуждаетесь в нескольких потоках в том же адресном пространстве, но остерегаетесь, который распараллеливает, действительно тверды разобраться. Условия состязания, особенно на небезопасных языках, иногда занимают недели для отладки; часто, просто добавление трассировки или выполнения под отладчиком изменит синхронизации достаточно для сокрытия проблемы. Просто помещение блокировок везде часто означает, что Вы получаете большую блокировку служебного и иногда такая конкуренция за блокировку, что Вы действительно не получаете преимущество параллелизма, на которое Вы надеялись. Даже когда у Вас есть право блокировки, затем необходимо представить для настройки для когерентности кэш-памяти. В конечном счете, если Вы захотите действительно настроить некоторый очень параллельный код, то Вы, вероятно, закончите тем, что смотрели на свободные от блокировок конструкции и более сложные схемы блокировки, чем те, которые в текущих библиотеках многопоточности.

Изучите преимущества параллелизма и пределы (например, закон Amdahl).

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

Бесплатный ланч закончен, но это не означает, что нет ничего для использования.

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

Если Вы действительно работаете с.NET, посмотрите на Параллельные Расширения. Они позволяют Вам легко выполнять много задач параллельного программирования.

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

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

• Изучите инструменты для параллелизма на Вашем языке (например, java.util.concurrent, JCIP).

• Выучите функциональный язык (например, Haskell).

Изучите Erlang/F# (в зависимости от Вашей платформы)

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

Некоторые приложения приносят пользу большему количеству того, что они выполняются на mutli-ядре-процессора затем другие. Если Ваше приложение может извлечь выгоду из многоядерного факта, то необходимо быть готовы пойти параллель. Бесплатный ланч закончен; это: в прошлом Ваше приложение стало быстрее, когда новый CPU был выпущен, и Вы не должны были прикладывать усилия к своему приложению для получения той дополнительной скорости. Теперь, для использования в своих интересах возможностей многоядерный CPU предлагает, необходимо удостовериться, что приложение может использовать в своих интересах его. Это: необходимо видеть, какие задачи могут быть выполнены многопоточные / одновременно, и это приносит некоторые проблемы к таблице...

Меня задали тот же вопрос, и ответ, "он зависит". Если Ваш Joe Winforms, возможно, не так. Если Ваше написание кода, которое должно быть производительно, да. Одна из самой большой проблемы I видит с параллельным программированием, это: если что-то не может быть parallized, и Вы лежите и говорите времени выполнения делать параллельно так или иначе, это не собирается отказывать, это просто собирается сделать вещи неправильно, и Вы получите загаженные результаты и обвините платформу.

Изучите OpenMP и MPI для кода C++ и C.

OpenMP также относится к другим языкам также как Фортран, который я предполагаю.

Запишите меньшие программы.

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

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

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