Pagina 2 di 2
Re: Parallelo
Inviato: lunedì 29 settembre 2008, 21:43
da bite
Ikitt ha scritto:
...
Dipende dall'applicazione.
Per esempio, nel caso di server web (statici), singole applicazioni monoprocesso ma che usano la programmazione asincrona (select, (e)poll o framework tipo libevent o twisted)
ottengono spesso prestazioni di assoluto rilievo, quando non le migliori del lotto, e non sono significativamente piu` difficili da programmare del corrispondente multithread (anzi).
Sarebbe lecito aspettarsi quindi prestazioni potenzialmente ancora maggiore da cluster di dette applicazioni con a monte un ripartitore del carico.
Uso il condizionale perche`, sebbene abbia letto di simili configurazioni, non ci ho mai concretamente messo mano.
...
In questi casi un elemento importante è il prodotto di tempo medio di servizio dell'evento e rateo medio degli eventi (numero puro). Se questo numero è basso (significativamente minore di 1), un unico loop che si appende su select può essere adeguato; se è alto, si può avere vantaggio scorporando più loop, ognuno su una sua cpu, salvo che ci siano interdipendenze tra gli eventi.
C'è poi un altro elemento da considerare, e cioé il prodotto di tempo massimo di servizio e rateo massimo, perché in alcune applicazioni un ritardo di servizio non è assolutamente accettabile (es. controllo di movimento).
Re: Parallelo
Inviato: martedì 30 settembre 2008, 7:41
da Ikitt
bite ha scritto:
Ikitt ha scritto:
...
Dipende dall'applicazione.
Per esempio, nel caso di server web (statici), singole applicazioni monoprocesso ma che usano la programmazione asincrona (select, (e)poll o framework tipo libevent o twisted)
ottengono spesso prestazioni di assoluto rilievo, quando non le migliori del lotto, e non sono significativamente piu` difficili da programmare del corrispondente multithread (anzi).
Sarebbe lecito aspettarsi quindi prestazioni potenzialmente ancora maggiore da cluster di dette applicazioni con a monte un ripartitore del carico.
Uso il condizionale perche`, sebbene abbia letto di simili configurazioni, non ci ho mai concretamente messo mano.
...
In questi casi un elemento importante è il prodotto di tempo medio di servizio dell'evento e rateo medio degli eventi (numero puro). Se questo numero è basso (significativamente minore di 1), un unico loop che si appende su select può essere adeguato; se è alto, si può avere vantaggio scorporando più loop, ognuno su una sua cpu, salvo che ci siano interdipendenze tra gli eventi.
Vero, per questo avevo aggiunto l'inciso "statici". Una delle condizioni di base per usare in modo proficuo la programmazione asicrona e` appunto che la gestione del singolo evento sia (relativamente) breve.
C'è poi un altro elemento da considerare, e cioé il prodotto di tempo massimo di servizio e rateo massimo, perché in alcune applicazioni un ritardo di servizio non è assolutamente accettabile (es. controllo di movimento).
Giusta precisazione, nelle mie considerazioni non ho tenuto in conto delle applicazioni realtime. Si tratta pur sempre di una nicchia, per quel che ne so, di grande valore ma numericamente piccola.