Perché una versione con thread di questo particolare script Perl è 200 volte più lenta della sua controparte senza thread?

Question

A presentation di Mikhael Goikhman da una conferenza Perl 2003 include un paio di esempi di script per la ricerca di numeri primi. One è threaded e il other non lo è. Dopo aver eseguito gli script (righe di stampa commentate), ho ottenuto un tempo di esecuzione di 0.011 su quello senza thread e 2.343 (!) Secondi sulla versione con thread. Ciò che spiega la straordinaria differenza in tempi?

Ho una certa esperienza con i thread in Perl e ho notato prima che i tempi di creazione dei thread possono essere particolarmente brutali, ma questo non sembra essere il collo di bottiglia nell'esempio di Goikham.

Answer 1

io sono un ragazzo di Python, Perl non, in modo da solo avere una vaga idea di ciò che sta facendo il codice. Tuttavia, fai sempre attenzione quando vedi Code. Python ha una coda thread-safe, e sembra che anche Perl. Sono fantastici in quanto si prendono cura della sicurezza dei thread per voi, ma in genere coinvolgono i lotti di costoso blocco e sblocco della coda, che probabilmente è dove tutto il vostro tempo sta andando.

Answer 2

Quanti processori hai? In generale, qualsiasi attività intensiva di calcolo sarà più lenta quando # di thread> # di processori. Questo perché è costoso passare da un thread all'altro ("context switch"). Le opzioni di contesto implicano l'interruzione di 1 thread, il salvataggio del contesto, l'inserimento del contesto di un altro thread nel processore in modo che possa essere eseguito. E tutto per cosa? Quindi il thread A può calcolare se 12321 è divisibile per 7 invece del thread B?

Se avete 2 procs, ci avrei scommesso che una versione con 2 capi potrebbe essere il più veloce, 4 proc -> uso 4 thread, ecc

Answer 3

Jay P. ha ragione:

~$ strace -c ./threads.pl 
% time  seconds usecs/call  calls errors syscall 
------ ----------- ----------- --------- --------- ---------------- 
99.80 0.116007  10546  11   futex 
    0.20 0.000229   6  36   mmap2 
    0.00 0.000000   0  31   read 
    0.00 0.000000   0  49  13 open 
    0.00 0.000000   0  36   close 

Confronti che, con:

~$ strace -c ./no-threads.pl 
% time  seconds usecs/call  calls errors syscall 
------ ----------- ----------- --------- --------- ---------------- 
90.62 0.000261   261   1   execve 
    9.38 0.000027   0  167   write 
    0.00 0.000000   0  12   read 
    0.00 0.000000   0  38  13 open 
    0.00 0.000000   0  25   close 

Answer 4

E 'un po' un caso patologico. La vera risposta è: prima di iniziare a usare i ithreads Perl, devi sapere un po 'di come funzionano le cose. Sono notoriamente inefficienti per alcune cose (condivisione di dati) e buone per altri (sono concomitanti).

Se i blocchi di lavoro a cui si lasciano i sottoprocessi aumentano di un valore significativo rispetto al numero di volte in cui si inviano dati da un thread a un altro, le cose apparirebbero molto diverse.

Confronto con thread Python come Jay P: Come afferma correttamente, i thread Python sono cooperativi e funzionano solo su un core. Gli ithreads di Perl sono molto diversi. Possono essere eseguiti su un core ciascuno, ma essere in grado di farlo viene pagato con un interprete separato per thread. Ciò rende la comunicazione tra thread simile alla comunicazione tra processi, incluso il sovraccarico associato.