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