Że aplikacje nie obsługują. Ale odpalam managera i wszystko lata. Gry to samo. Teksty w stylu “4 mocne rdzenie, bo i tak nie wykorzystasz” to już do lamusa?
Głupia Opera też:
Nie wiem jak radzi sobie z tym Opera, ale wiem jak działa to np. przy programach do projektowania np. Revit. Najpierw na dwóch rdzeniach liczy sobie projekt i przydziela operacje do wykonania dla innych rdzeni, czym więcej rdzeni, tym dłużej trwa ten etap, dopiero potem ruszało na wszystkich. I gdy projekt był mały, to można było trafić, że szybciej się wykonał na procesorze z mniejszą ilością rdzeni, ale jak był duży, to jednak wielordzeniowe procesory potrafiły niesamowicie dać przewagę.
Pewnie z innym softem jest podobnie, zależy jak jest napisany.
Po to są stacje graficzne z quadro. Napisane pod sprzęt. Ale mi chodzi o codzienne użytkowanie. Programista ustala jak to będzie latać, czy system?
Programista.
Są algorytmy których nie da się wykonywać równolegle na wielu wątkach, są takie które kochają wielowątkowość np. raytracing.
Łopatologicznie
Zdecydowanie, program musi być specjalne napisany tak aby potrafił wykonywać się na wielu rdzeniach. Jak pojawiły się procesory wielordzeniowe to programowanie skomplikowało się. Obrazowo, program musi podzielić zadanie na części, zapewnić synchronizację tych części, potem wynik łaczyć w całość w jeszcze innym zadaniu. W sumie to bardzo ciekawe, teraz lwią część robią gotowe biblioteki.
Przykładowo jak masz w programie pętle for n=1 to 10000 to system w żaden sposób nie będzie mógł jej rozdzielić pomiędzy rdzenie. Odpali ją na jednym a pozostałe będą się nudzić. Żeby wykorzystać np 10 rdzeni, program musi być na tyle sprytny aby odpalić 10 wątków, w jednym pętlę for n=1 to 1000 w drugim for n=1001 to 2000 itd… i ich wynik potem połączyć w całość. Łatwo stwierdzić, ze są zadania z którymi się tak łątwo nie da (jak wspomniał @anon42271672 ) inne znowu są na sztywno napisane np dla max 4 rdzeni.
Wcześniej było prosto, bo programista nic nie musiał robić, oczekiwał jedynie że pojawi się procesor z szybszym zegarem. Jak spopularyzowały się procesory wielordzeniowe to taki Adobe np musiał specjalnie przepisać wszystkie te swoje filtry z Photoshopa żeby wykonywały się na wielu rdzeniach.
Polecam zobaczyć to w praktyce wykorzystując Python
Skomplikowało się jak pojawiły się płyty z kilkoma procesorami fizycznymi 
Wielordzeniowe to było sporo później
Tak dokładnie zgadza się, ale uprościłem wypowiedź, żeby nie robić z niej referatu. Z drugiej strony oprogramowanie serwerowe często wtedy było tak zbudowane, że z procesu głównego ‘forkowało’ się po kilka procesów oczekujących na requesty i tym samym wykorzystywały kilka rdzeni.
Wg mnie środowisko serwerowe trochę z automatu zapewniało lepsze wykorzystanie wielu procesorów, choćby z racji na wielu użytkowników i oddzielne procesy ich obsługujące.
Nie da się rozrzucić na rdzenie zadań w programie, których nie zaprogramowano po kątem zrównoleglenia. I nie polega to tylko na dopisaniu #pragma omp w kodzie, tylko trzeba zadbać o algorytm.
I potrafi się to zmienić z wersji na wersję. Byle Discord raz zostanie wydany z Chromium który ma optymalizacje, a raz nie, bo wypadły na chwilę. Albo sam będzie wprowadzał nowy ficzer któy się nie zrównolegla itd.
No dobrze, ale chyba nic nie stoi na przeszkodzi żeby system do osobnych aplikacji przydzielał sobie inne rdzenie, czy się mylę? Bo ręcznie możemy sobie sami przydzielić do danego procesu rdzenie.
Tak, jeżeli uruchomionych jest wiele programów to już system rozłoży je między rdzenie. W tym celu same programy nie muszą nic potrafić;) . Z tym, że zazwyczaj zwłaszcza na desktopie jest taka sytuacja że jeden program potrzebuje mocy i powinien umieć wykorzystać wszystkie rdzenie a pozostałe programy się nudzą. Tak więc optymalizacja pod wykorzystane wielu rdzeni przez ten sam program dalej konieczna.
Nie mylisz się.
System może przerzucać wykonanie programu między rdzeniami podczas wznawiania wykonania danego wątku, ale czy jest to spowodowane prostotą (“wznów wątek na następnym rdzeniu” zamiast “odczytaj do którego rdzenia był przypisany wątek i uruchom go tam chyba że jest on przeciążony, wtedy uruchom go na innym”) czy może równowagą termiczną, czy jeszcze jakimś innym czynnikiem - tego niestety nie wiem. Obie możliwości brzmią prawdopodobnie, tym bardziej, że z logicznego (programowego) punktu widzenia nie ma to znaczenia. W bardzo specyficznych zastosowaniach “przyklejenie” wątku do rdzenia może dać minimalnie lepszą wydajność, ale generalnie nie warto zaprzątać sobie tym głowy
A to ciekawe, tak na szybko nie przychodzi mi do głowy żaden pomysł do czego jest przydatne wznawianie na innym rdzeniu. Swoją drogą, nieźle postęp zruszył do przodu. Kiedyś serwer z 2 procesorami po 1 rdzeniu wyglądał tak https://www.facebook.com/pg/retrohw/photos/?tab=album&album_id=705205526557409 a dzis kilkanaście rdzeni i kilkadziesąt wątków wygląda tak https://www.dell.com/pl/firmiinstytucji/p/poweredge-r640/pd
Minęło jednak 20 lat.
Bardziej intrygujące jest jednak porównanie tego della ze znacznie wydajniejszym raspberry pi 
Wielki żelazny klocek przegrywa z malutką płytką zasilaną ładowarką do telefonu.
A czemu miałoby służyć przyspawanie procesu/wątku do tego samego rdzenia?
Sens migracji procesu między rdzeniami na pewno istnieje, bo tęgie głowy to projektowały. Po prostu się zastanawiam…
Prócz braku konieczności aktualizacji zawartości cache danego rdzenia (która zapewne i tak się w międzyczasie zdezaktualizowała) nie widzę żadnego uzasadnienia dla planisty systemowego, by takie przyspawanie realizować.
Z naszego ludzkiego punktu widzenia przypisanie pracownika do zadania (rdzenia do procesu) ma sens, lubimy czytelnie wykorzystywać zasoby. Ale nasza intuicja w tym wypadku zawodzi, bo niepotrzebnie utrudnia sprawę i optymalizuje bezsensowne działanie (pracownik robiący jedno zadanie może się na nim skoncentrować i w rezultacie zrobić je szybciej niż gdyby robił coś innego co 5 minut, ale w świecie procesorów jest to bez znaczenia)
Ale Ty mi zaimponowałeś tą grafiką. I chyba pomijając tych powyżej i poniżej. masz rację najbardziej.
Zagłębiłem się w temat , poczytałem…