Il punto è che ci sono problemi proprio di ingegnieria del software per cui il multithreading non è quasi mai possibile.
Un software non è altro che una sequenza di istruzioni. Il multithread è essenzialmente lo svolgere le suddette istruzioni in parallelo, ognuna in un core diverso (o in una pipeline nel caso di i7).
Ma dove sta l'inghippo? Che la maggior parte delle istruzioni sono condizionate. Ossia per avviarsi hanno bisogno del risultato che gli fornisce l'istruzione precedente. Capisci anche tu che non è possibile eseguirla in parallelo, ne ora ne mai. Per quanto un programmatore sia bravo... proprio non si può.
Si può intervenire su piccole porzioni di codice, che si prestano bene allo scopo, ma capisci da te che in certe applicazioni (quasi tutte in realtà) questa percentuale è veramente molto limitata.
Il vero stacco prestazionale è stato fatto nel passaggio dal single al dual core ma non perché i programmi "usano due core", ne continuano ad usare uno solo in grossa parte, ma solo perché esiste un sacco di operazioni (task) che normalmente vengono gestiti anche quando il pc sembra fermo (se dai un occhiata al task manager di windows te ne accorgi). Ma avendo due core il sistema operativo ne può destinare uno ai vari tsr e a se stesso e l'altro lo può dare "completamente" a disposizione del gioco. Però se tra uno e due core la differenza è tanta, tra due e tre o quattro cambia di pochissimo.
Fanno ovviamente eccezione quei software che "di persé" scalano bene in multithreading, ma sono pochi e ben determinati (tipo compressioni, rendering raytracing, macchine virtuali, file server e pochissimo altro).
Capit?
