Attualmente sto provando a progettare un motore a livello centrale. Tuttavia, non riesco a decidere se il thread di input debba essere mescolato con un thread di rendering o qualsiasi altro thread. Lo renderebbe un thread in più con tutte le serrature che richiederà sarà più lento? Se è uguale o più veloce, sarebbe almeno marginalmente più veloce?
[Considera quanto sopra solo un esempio del concetto.]
Ci sono un paio di domande che devi rivolgere qui:
Se ci sono tonnellate di iterazioni e il processo di input richiede molto tempo, quindi eseguire il pipelining delle attività come due thread separati può velocizzare l'applicazione.
Se non c'è un enorme afflusso di dati da gestire, o se il processo di input non è molto oneroso, allora la divisione delle operazioni probabilmente non giustifica i costi di sincronizzazione.
Fondamentalmente, durante la parallelizzazione, il numero ottimale di thread == numero di core. Questo perché allora ogni core esegue esattamente un thread; tutti i core stanno lavorando, ma non è necessario cambiare i thread continuamente (pianificazione).
In pratica, si tratta ovviamente di una grossolana semplificazione eccessiva. Solo per iniziare con il fatto che il tuo programma non è solo; ci sono una serie di altri processi e thread in giro per condividere la CPU. Quindi, il tuo problema potrebbe non essere (almeno completamente) legato alla CPU. E come dividi il lavoro tra i fili farà enormi differenze. Quindi questo si riduce a misurazione. Rende il numero di thread regolabile, se possibile. Quindi provalo. Su diversi computer Sarà interessante: -)
In generale, i problemi con il blocco a grana fine richiedono molti thread (su molti core) per pareggiare, i problemi con il blocco a grana grossa si ridimensionano linearmente (fino a un punto).
Il blocco è l'overhead più grande con più thread, quindi i problemi senza blocchi, come il rendering se eseguiti correttamente, traggono il maggior vantaggio da thread aggiuntivi.
In sintesi, dipende. Cerca di ridurre il numero di volte in cui è necessario bloccare i mutex per eseguire azioni e il numero di thread da interrompere in pareggio diminuirà.
Potresti considerare un semplice sistema di accodamento per consentire alle operazioni di input / output di funzionare in modo disconnesso. Quindi il tuo thread di rendering sarebbe in grado di aggiornarsi e dipingere mentre attende ancora l'input dell'utente / sistema. Ciò consentirebbe anche di spingere l'elaborazione dei dati su un'altra coda per ridurre ulteriormente la contesa.
estesa ...
Il numero di thread ottimali dipende dall'applicazione e dal carico. Troppi thread e potresti incorrere in un problema con deadlocking e contesa di commutazione. Troppo pochi e si diventa vincolati all'I / O.
Deadlock - La contesa delle risorse fa rallentare l'applicazione a causa di thread diversi che combattono su risorse limitate (I / O o dati)
Controversia di commutazione: la quantità di tempo in cui le applicazioni (o il sistema operativo) scambia / interrompe i thread è maggiore del tempo impiegato per l'elaborazione dell'I / O o dei dati
Limite I / O - I thread terminano in uno stato bloccato / in attesa mentre le risorse sono in uso.
Sulla contesa di commutazione hardware moderna probabilmente non è un problema a meno che non si dia la priorità ai thread in modo negativo. (Dai ai thread di blocco lunghi una priorità più alta.)
Il limite I / O è in genere meno di un problema rispetto ai deadlock e in genere può essere ridotto aumentando il numero di thread disponibili.
I deadlock sono di gran lunga i più difficili da risolvere. Il modo più semplice sarebbe probabilmente quello di utilizzare strutture di dati immutabili e anticipare una chiamata a risorse condivise che causerebbe un deadlock. Il motivo per cui sono così difficili da risolvere è che diverse parti delle risorse sono bloccate da thread diversi e potrebbero richiedere a ciascuno dei thread di scartare i dati correnti e riavviarli. (Anche questi riavvii fanno perdere all'applicazione i dati di rielaborazione del tempo.)
Leggi altre domande sui tag multithreading