Jeśli pytasz tylko o to, czy da się - tak, dostałeś już nawet link do pojęcia, sam też coś znalazłeś. Generalnie dać się da, zarówno dla procesów jak i wątków.
Czy gra warta świeczki i czy jest sens to robić... Obawiam się że bardzo mocno to zależy - od różnych czynników
- architektury sprzętu - np. tego czy masz jeden CPU wielordzeniowy, czy kilka w UMA / NUMA / ccNUMA / rozproszonych w sieci, choćby i lokalnej, a jeśli masz na myśli kawałek kodu który dałoby się np. przenieść na GPGPU to tam zrównolegla się zupełnie inaczej, niż na procesorach (inny model wykonania, inny dostęp do pamięci przez jednostki obliczeniowe czy jak tam je zwał), no i znów będzie się liczyła komunikacja CPU/GPU - magistrala może być poważnym wąskim gardłem.
- Czasu życia tych procesów (dla bardzo krótko żyjących procesów znaczną część zasobów i czasu zajmie... Ich tworzenie)
- Liczby procesów i CPU/rdzeni - więcej nie zawsze znaczy lepiej, im więcej tym mniejszy zysk dla zadania tej samej wielkości, no i tym większy narzut na ewentualną komunikację. Jeśli procesów jest dużo więcej niż rdzeni to i tak nie unikniesz przełączania kontekstu (pomijając to, że nawet mając pinning nie wykluczasz że scheduler odbierze procesowi CPU)
- Tego co tak naprawdę jest wąskim gardłem aplikacji tudzież fragmentu aplikacji - jeśli procesy są głównie bezczynne bo czekają na dostępy do pamięci, to zrównoleglanie niewiele da, podobnie gdy głównym blokerem są operacje I/O np. sieć. Potencjalnie możesz nawet zaszkodzić dorzucając więcej procesów.
- Sposobu rozdzielania zadań między procesy tzn dzielenie na więcej mniejszych zadań lub kilka dużych, rozdzielanie stałej liczby zadań do każdego procesu lub balansowanie obciążenia, tworzenie osobnego procesu dla każdego zadania lub ponowne wykorzystanie np w ramach puli procesów itd
Generalnie jednoznacznej odpowiedzi raczej nie da się udzielić, więc najrozsądniej zrobić parę podstawowych rzeczy, w miarę możliwości
- Sprofilować aplikację i zobaczyć, co tak naprawdę jest najbardziej czasochłonne i jakie zasoby są najbardziej zżerane
- Zrobić benchmark na konkretnym sprzęcie, zastosować kilka rozwiązań i zmierzyć jakie są różnice
- Potencjalnie przyjrzeć się temu, jak zadanie jest zdefiniowane i czy będzie się ładnie zrównoleglać tzn nie ma zbyt dużo synchronizacji / komunikacji. Najlepiej żeby nie było wcale, wtedy zrównoleglanie jest trywialne i przy okazji bardziej bezpieczne, niż gdy trzeba się komunikować. Być może ma dobrą złożoność, ale przez narzut komunikacji będzie się źle skalować i zrównoleglać ;)
Właściwie, to wiedząc jaka jest złożoność obliczeniowa zadania w wersji jedno-procesowej, pod-zadania w wersji zrównoleglonej i jakie są narzuty na komunikację w relacji do liczby procesów / rozmiaru zadania i tak dalej jesteś w stanie określić analitycznie, czy zadanie będzie się dobrze zrównoleglać lub czy/jak będzie się skalować ze wzrostem rozmiaru zadania, i tym podobne.