Mettiamo caso che al click di un bottone devo eseguire un'operazione che dura 10 minuti, se riesco a suddividere tale operazione in 10 micro-operazioni e avvio ogni micro-operazione da un proprio Thread(quindi invece di un'operazione di 10 minuti su un Thread ho 10 micro-operazioni su 10 Thread che lavorano contemporaneamente) ecco, il tempo di esecuzione si abbasserà? o per meglio dire è un ragionamento valido o no?
la risposta a una domanda così generica non può essere che forse
il multithread non è la panacea di tutti i mali anzi
se le 10 operazioni che devi fare sono interdipendenti e devono scambiare dati probabilmente il tempo di esecusione sarà maggiore se tutte lavorano coi propri dati la situazione potrebbe migliorare
Vascello fantasma dei mentecatti nonchè baronetto della scara corona alcolica, piccolo spuccello di pezza dislessico e ubriaco- Colui che ha modificato l'orribile scritta - Gran Evacuatore Mentecatto - Tristo Mietitore Mentecatto chi usa uTonter danneggia anche te
Posso dividere l'oprazione principale in più operazioni a se stanti. Ognuna si fa il suo lavoro per conto proprio. Quindi dici che se devo scrivere 100 record e ogni Thread ne scrive 10 posso avere lo stesso risultato in minor tempo. Questo a prescindere dal tipo di processore? o c'è qualche tipo di processore più performante rispetto ad altri per le operazioni in MultiThread?
un processore non è multithread... un processore esegue sempre e solo un'istruzione alla volta... se vuoi un sistema hardware multithread devi avere più processori configurati in una certa maniera.
Ciò che comunemente viene chiamato multithread è il sistema operativo a gestirlo, tenendo traccia di un'infinità di informazioin di ciascun processo attivo, quali la priorità (il kernel ha priorità max ad esempio) o da quanti microscondi un certo processo è tenuto in standby o ancora lo stato dei semafori, eccetera. Il famoso processo "Ciclo idle del sistema" che puoi sempre vedere nel task manager si occupa proprio di questo.
La risposta alla tua domanda è dipende. Se ciò che attualmente è tutto in un processo occupa al 100% le risorse della macchina (perchè ad esempio fa solo calcoli) allora sarà inutile dividerlo in 10 processi, e anzi controproducente perchè all'utilizzo delle risorse dovrai aggiungerci la gestione dei 10 processi da parte del SO. Se invece il tempo di esecuzione è lungo per altri motivi, come utilizzo della rete, o accessi al disco o altro ancora allora è assolutamente consigliabile.
Se, ad esempio, la prima parte della tua procedura fa grossi accessi al disco, la seconda parte accede pesantemente alla rete e la terza stampa, allora purchè ovviamente non sia necessario eseguirle in successione, puoi pensare di separarle in 3 thread che fanno contemporaneamente queste cose ottimizzando i tempi.
Quando il collo di bottiglia è la CPU non spezzare mai.
Altro consiglio, se hai 1 procedura che accede solamente al disco, e pensi che spezzare la procedura in 10 microprocedure che tutte insieme accedono al disco migliori la situazione ti dico subito che non la migliorerà affatto, poichè sovraccaricare in dispositivo (sia esso CPU, disco rigido, scheda grafica, o di rete) che già è impegnato al 100% ne riduce drasticamente le performance.
Prova a copiare un grosso file da un'hard disk ad un altro e, mentre ancora sta copiando e magari ti dice 6 minuti al termine dell'operazione, prova a metterne in copia un secondo... ti aspetti 6 minuti per file? no... e nemmeno 12 (6 * 2 file) i tempi salgono a 18, o 20 minuti. In pratica fai prima a copiarli in successione.
Grazie per le risposte! quindi è sempre meglio una attenta analisi per valutare se sia il caso o meno di utilizzre più processi contemporaneamente e vedere se effettivamente si riducono i tempi...
Piu' processi non e' la stessa cosa di piu' thread ... apri un altro capitolo ...
No MP tecnici (non rispondo nemmeno!), usa il forum.
Intendevo dire Thread, non processi. Comunque l'utilizzo dei processi potrebbe fare al caso mio?
Come ti e' stato risposto prima ... dipende ... tu non hai dato maggiori dettagli sul problema ...
In poche parole, se i tuoi processi accedono molto al disco, potresti non avere un miglioramento (anzi un peggioramento) delle prestazioni.
Se un processo utilizza molto il disco e un altro puo' lavorare in memoria con molti calcoli, allora puoi trarre benefici ....
Ma potrai avere problemi nel far dialogare i vari processi, cosa molto piu' complessa rispetto al dialogo tra thread dello stesso processo ...
No MP tecnici (non rispondo nemmeno!), usa il forum.
Senza contare che i processi (specie su Windows, specie se sono .NET) sono oggetti molto più pesanti rispetto ai thread, per cui tra le due possibilità sceglierei i thread (anche se la sincronizzazione può essere piuttosto complessa), o al limite la via di mezzo dei "processi leggeri" .NET (AppDomain).
Amaro C++, il gusto pieno dell'undefined behavior.
Ok! Grazie per i consigli.
Permessi di invio
Rispondi quotando