Сложного и быстрого ответа нет, но большую часть времени вы не увидите никаких преимуществ для систем, в которых рабочий процесс / расчет последовательный. Однако, если проблема может быть разбита на задачи, которые могут выполняться параллельно (или сама проблема является массивно параллельной [как некоторые математические или аналитические задачи]), вы можете увидеть значительные улучшения.
Если ваше целевое оборудование одноядерное / ядро, вы вряд ли увидите какие-либо улучшения с многопоточными решениями (так как в любом случае выполняется только один поток!)
Написание многопоточного кода часто сложнее, поскольку вам, возможно, придется потратить время на создание логики управления потоками.
Некоторые примеры
- Обработка изображения часто может выполняться параллельно (например, разделить изображение на 4 и выполнить работу в 1/4 времени), но это зависит от того, какой алгоритм запускается, чтобы увидеть, имеет ли это смысл .
- Рендеринг анимации (из 3DMax и т. Д.) Массивно параллелен, поскольку каждый кадр может быть представлен независимо друг от друга - это означает, что 10 или 100 компьютеров могут быть объединены в цепочку, чтобы выручить.
- GUI программирование часто помогает иметь по крайней мере два потока при выполнении чего-то медленного, например обработка большого количества файлов - это позволяет интерфейсу оставаться отзывчивым, в то время как работник выполняет тяжелую работу (в качестве примера можно привести BackgroundWorker)
Графические интерфейсы являются интересной областью, поскольку «отзывчивость» интерфейса может поддерживаться без многопоточности, если рабочий алгоритм поддерживает основной графический интерфейс «живым», предоставляя ему время в терминах Windows API (до .NET и т. Д.) это может быть достигнуто примитивным циклом и не требует многопоточности:
MSG msg;
while(GetMessage(&msg, hwnd, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
// do some stuff here and then release, the loop will come back
// almost immediately (unless the user has quit)
}