[Qualsiasi linguaggio] Numero di Threads

[zacca94]

E' corretto affermare che il miglior modo per vedere quanti thread è possibile creare la miglior soluzione è un benchmark facendo semplicemente differenti prove per vedere quale riesce a eseguire il maggior numero di iterazioni nel più breve tempo possibile?
O è possibile una situazione nel quale (facendo un esempio iperbolico) 100 threads sono meglio di 50, ma peggio di 10?

Dando per assodato che sarà una stima empirica perciò con un margine d'errore?

Grazie

[Dascos]

Hum. Dipende.
Non esistono solo i thread ma ci sono anche i chlid, per esempio, e i server....
Un programma/processo/servizio può avviare 4 server, ognuno dei quali supporta 5 thread e ogni thread può soddisfare 20 child.
Apparentemente quindi hai 4 * 5 * 20 = 400 richieste contemporanee che, sempre apparentemente, puoi supportare.
MA
cosa succede (al tuo programma) se hai 50 server con 4 thread e 2 child? Sempre 400 richieste risultano, solo che tecnicamente parlando (e ovviamente in modo molto generico) può essere un collo di bottiglia che ti inchioda il server.

L'esempio più classico è Apache, che appunto lavora con "server", "thread" e "child" e, tra l'altro, è configurabile con valori minimi per ognuno, massimi e boorst.

Avviare e gestire 6 server che devono gestire 2 thread che devono gestire 1 child è più dispendioso che avviare e gestire 2 server che avviano 2 thread che avviano 3 child.
Se poi fai in modo che al raggiungimento della saturazione dei child venga avviato un thread aggiuntivo di altrettanti child (es arrivi a tappo con un thread da 10 child: avvii un altro thread da 10 child per sopperire alla maggior richiesta), oppure alla saturazione di un server devi avviarne un altro completo, capisci da solo dove si va a finire.

Questo dal punto di vista prettamente teorico.

Quindi sì, teoricamente 100 processi possono essere meglio di 50 ma peggio di 10. Dipende da come progetti il programma/servizio e da che lavoro deve svolgere

[oregon]

Avete fatto un mischione di processi e thread senza senso.

E che sarebbero i 'server'?

[zacca94]

Grazie per le risposte,
il mio discorso era più specifico per i ciò che riguarda la programmazione e il threading di funzioni "semplici" (che quindi non svolgono troppi compiti).

Faccio anche un esempio pratico in pseudo-codice per essere più chiaro:

function dividi(*array) {
   for (i = 0; i < len(array); i++) {
     array[i] = array[i] / 100;
   }
}

numeri[10][1000000]; // Ipotizzando sia fillata con valori casuali

for (i = 0; i < 10; i++) { // 10 thread uno per indice
   esegui_thread(dividi(numeri[i]))
}

[oregon]

Dipende moltissimo dallo specifico compito quindi è possibile che eccedere nei thread sia controproduttivo.

Altra storia per i processi e la programmazione relativa ma altrettanto varia e dipendente dal SO e dalla situazione specifica.

[zacca94]

Dipende moltissimo dallo specifico compito quindi è possibile che eccedere nei thread sia controproduttivo.

Altra storia per i processi e la programmazione relativa ma altrettanto varia e dipendente dal SO e dalla situazione specifica.

Ok, tornando alla domanda iniziale:
E' corretto affermare che il miglior modo per vedere quanti thread è possibile creare la miglior soluzione è un benchmark facendo semplicemente differenti prove per vedere quale riesce a eseguire il maggior numero di iterazioni nel più breve tempo possibile?


Possiamo rispondere che "è fortemente probabile"?

[oregon]

No.

Intanto, quanti thread è possibile creare *dipende* dalle risorse hw messe a disposizione dal SO.
E se questi thread lavorano in modo ottimale o no, *dipende* da cosa fanno i thread.

Non puoi dare una risposta precisa ed attendibile ad una domanda mal posta.

[Dascos]

Avete fatto un mischione di processi e thread senza senso.

E che sarebbero i 'server'?

Processi server...mai sentito parlare?
In pratica istanze del "programma". Ho anche riportato l'esempio più conosciuto (più o meno) di programma che lavora con "server", "thread" e "child"...più di così!

A single control process (the parent) is responsible for launching child processes. Each child process creates a fixed number of server threads as specified in the ThreadsPerChild directive, as well as a listener thread which listens for connections and passes them to a server thread for processing when they arrive.


Apache HTTP Server always tries to maintain a pool of spare or idle server threads, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new threads or processes to be created before their requests can be served. The number of processes that will initially launch is set by the StartServers directive. During operation, the server assesses the total number of idle threads in all processes, and forks or kills processes to keep this number within the boundaries specified by MinSpareThreads and MaxSpareThreads. Since this process is very self-regulating, it is rarely necessary to modify these directives from their default values. The maximum number of clients that may be served simultaneously (i.e., the maximum total number of threads in all processes) is determined by the MaxRequestWorkers directive. The maximum number of active child processes is determined by the MaxRequestWorkers directive divided by the ThreadsPerChild directive.

Il processo principale lancia dei child (tipicamente 4, nel caso di apache) che sono null'altro che "copie" di se stesso. Ogni child lancia dei thread che in totale possono gestire MaxRequestWorkers richieste contemporanee.

Apache usa una terminologia "parent - child - server thread - client" ma il concetto è lo stesso se espresso come "server - thread - child", basta accordarsi sulle convenzioni :-)

[oregon]

Processi server? Con 5 thread?
Ma che dici?

Processi e thread (e fiber) sono oggetti caratteristici gestiti da un SO.

Un server è una funzionalità che assume una applicazione single o multiprocess/multithread.

Continui a mischiare concetti che stanno a livelli diversi, non ci sono thread, processi e server, semmai fiber, thread e processi. Stop.

Sarai un web developer ma sull'architettura dei Sistemi Operativi fai un po' di confusione. Ti consiglio il ripasso del Tanenbaum.

[Dascos]

Processi server? Con 5 thread?
Ma che dici?

Processi e thread (e fiber) sono oggetti caratteristici gestiti da un SO.

Un server è una funzionalità che assume una applicazione single o multiprocess/multithread.

Continui a mischiare concetti che stanno a livelli diversi, non ci sono thread, processi e server, semmai fiber, thread e processi. Stop.

Sarai un web developer ma sull'architettura dei Sistemi Operativi fai un po' di confusione. Ti consiglio il ripasso del Tanenbaum.

Come dici tu, vuol dire che Apache (non io, Apache Software Foundation!) quando parla di thread, processi, child e server sta dicendo cavolate.
Bene così