2015-04-22 30 views
7

Fondamentalmente sto lavorando su questo algoritmo di rilevamento del battito, la cosa strana che sto incontrando in questo momento è che quando ho diviso il carico di lavoro su un altro thread. Quindi ora ho un thread principale e un altro thread di lavoro. Il mio thread di lavoro in qualche modo funziona sempre più velocemente del thread principale. Sembra strano perché quello che ho imparato è che il thread principale dovrebbe teoricamente essere sempre più veloce perché non ci vuole tempo per inizializzare il thread. Tuttavia, quello che ottengo è che anche io passo altri 1024 campioni al thread di lavoro (stanno entrambi lavorando con circa 30 milioni di campioni al momento), è ancora più veloce del thread principale. È perché ho applicazioni in esecuzione sul mio thread principale? Sono davvero confuso adesso. Ecco il codiceC# multithreading Comportamento strano

UnityEngine.Debug.Log ("T800 Start"); 
     Step3 s1= new Step3(); 
     Step3WOMT s2= new Step3WOMT(); 
     System.Object tempObj= samples2 as System.Object; 
     float[] tempArray = new float[eS.Length/ 2]; 
     System.Threading.ParameterizedThreadStart parameterizedts = new System.Threading.ParameterizedThreadStart(s1.DoStep3); 
     System.Threading.Thread T1 = new System.Threading.Thread(parameterizedts); 
     T1.Start (tempObj); 
     s2.DoStep3(samples1); 
     UnityEngine.Debug.Log ("s2"); 
     //UnityEngine.Debug.Log (stopwatch.ElapsedMilliseconds); 
     T1.Join(); 

Non ti preoccupare io sto solo usando C# caratteristiche nel multithread quindi credo che dovrebbe andare bene. Quello di cui sono davvero confuso è che se commento T1.join(); allineare il tutto in qualche modo andare ancora più lentamente. Sono sinceramente confuso in questo momento perché non sembra esserci una risposta ragionevole a questa domanda.

+0

Certo, se un thread esegue la stessa logica più velocemente di un altro è perché c'è meno "penetrazione" su quel thread. In WPF (.Net) per esempio L'interfaccia utente del foro è ospitata sul thread principale e l'applicazione viene eseguita su quel thread per impostazione predefinita. Con questa conoscenza ha spesso senso creare applicazioni multi-thread per condividere il carico di lavoro tra i thread in modo da consentire loro di fare di più - o di consumare meno tempo per lo stesso lavoro. –

+0

Anche se non è un grosso problema, 1503 millisecondi contro 1481 millisecondi, è piuttosto strano. Anche il thread worker sta eseguendo un oggetto come oggetto per la conversione dell'oggetto in float []. Quindi non dovrebbe essere sempre più lento del thread principale? –

+0

Non c'è davvero alcuna differenza pratica tra '1503' e' 1481' ms. Sarei interessato a vedere come stai facendo il tuo tempismo - che probabilmente ha anche un impatto. – Enigmativity

risposta

1

T1.join() fa tutta la magia. Permette al thread principale di attendere fino a quando tutti i thread di lavoro sono completi. È necessario? dipende dalla tua applicazione. è previsto che un thread principale attenda la fine dell'esecuzione dei suoi thread di lavoro.

0
  1. Il sistema deve disporre di più core.
  2. È possibile che Thread.Start non venga restituito non immediatamente dopo l'inizializzazione del thread. Ad ogni modo dovresti usare ThreadPool.EnqueueUserWorkItem e ManualResetEvent per aspettare invece di unirti.
  3. Per visualizzare i risultati reali che i campioni contano deve essere sufficientemente grande in modo che il tempo di inizializzazione del thread sia minimo rispetto al tempo di esecuzione del codice. ThreadPool spesso non è necessario inizializzare un nuovo thread ma richiede ancora del tempo per avviare il codice. Penso che non dovresti usare il multithreading per compiti che richiedono < ~ 50ms.
  4. Se si confronta il tempo di esecuzione per il conteggio di campioni grandi (richiede alcuni secondi) vedrete che non c'è differenza nelle prestazioni del thread principale e di quello in background (a meno che il thread principale abbia una priorità più alta).