79 risposte a questa discussione

[Sgurbat]

ovvio come dicevo prima non parallelizza nulla il processore, sta al codice/framework fare una parallelizzazione esplicita.

Tanto per fare un esempio in .net basta fare qualcosa del genere:

 

divinaCommedia.Split(" ").AsParallel().Count(w => w.StartsWith("a"));

per sapere quante parole nella divina commeda iniziano con la lettera a suddividendo i calcoli tra tutti i core disponibili.

In questo caso possiamo parlare di parallelismo "automatico", ma in realta' e' il .net framework che si occupa di tutto il lavoro sporco automaticamente grazie alle funzioni pure utilizzate per l'implementazione di LINQ

 

cioè basta chiamare .AsParallel() e .NET avvia il multithreading sull'operazione?

 

Fico!!!

[Sgurbat]

 a volte una cpu al 100% non e' per forza sinonimo di limite computazionale raggiunto, ma puo' anche essere il garbage collector che lavora a manetta a causa di memory leaks..

 

Vero in effetti, anche questa cosa è da tenere ben da conto.

 

[TigerShark]

Single 3d:

t0 = a + b
t1 = c + d
e = t0 + t1

 

i passi 1 e 2 vengono parallelizzati dalla cpu. mentre per il terzo viene messo tutto in w8 fino a che non abbiamo i risultati sopra.

no, non sta alla cpu scegliere quali istruzioni mettere in un thread che gira in un core e quali in un altro, anche perche' suddividere in maniera arbitraria queste istruzioni potrebbe essere dannoso se l'altro core, come e' probabile, ancora non si ritrova quei dati su cui operare nei registro o quantomeno nella cache.

Ti stai confondendo con le architetture Out of order vs in-order mi sa dato che e' il sistema operativo che decide su quale core schedulare un thread.

E infatti sono rimasti famosi i primi periodi di introduzione dell'hyper-threading in cui lo scheduler di windows non differenziava tra il core fisico e quello logico con l'ovvio risultato che le prestazioni in determinati casi di full-load erano migliori con l'hyper-threading disabilitato.

Ripeto, una cosa di questo genere e' possibile con .net, ma SOLO ED ESCLUSIVAMENTE perche' per implementare LINQ sono state scelte tutte funzioni prive di side-effect e che quindi possono essere parallelizzate in maniera automatica.

Messaggio modificato da TigerShark il 16 marzo 2013 - 17:48

[TigerShark]

cioè basta chiamare .AsParallel() e .NET avvia il multithreading sull'operazione?

 

Fico!!!

yup, dal 3.5 utilizzando PLINQ come libreria esterna e dal 4 automaticamente dato che e' stato inglobato nel framework insieme all'aggiunta della Task Parallel Library.

[ally]

...io resto della mia idea di fare tutto a manina santa...sopratutto se hai n macchine tue da gestire...un server centrale che costruisce l'elenco di job e n client che lo interrogano e si fanno dare il lavoretto da fare...

[toyo]

Happy St Patty!

[toyo]

ah ma sopra parlate di plinq


plinq spacca

[toyo]

c'è tutto sulla mia tesi!

[Sgurbat]

Cos'è una tesi?

 

[Sgurbat]

...io resto della mia idea di fare tutto a manina santa...sopratutto se hai n macchine tue da gestire...un server centrale che costruisce l'elenco di job e n client che lo interrogano e si fanno dare il lavoretto da fare...

 

Un load balancer sarebbe fattibile invece o vale solo per le web-application?

[TigerShark]

Un load balancer sarebbe fattibile invece o vale solo per le web-application?

quello che dice lui e' praticamente un load-balancer distribuito in cui ogni client chiede al server centrale nuovi jobs non appena le sue risorse sono disponibili.

Pero' secondo me, come dicevo prima, vista la dimensione dei file e' bene che ogni client si mantenga un buffer di lavori da elaborare in locale in modo da mascherare le latenze di rete che sono quelle che potenzialmente potrebbero uccidere le prestazioni in uno scenario del genere.

[ally]

quello che dice lui e' praticamente un load-balancer distribuito in cui ogni client chiede al server centrale nuovi jobs non appena le sue risorse sono disponibili.

Pero' secondo me, come dicevo prima, vista la dimensione dei file e' bene che ogni client si mantenga un buffer di lavori da elaborare in locale in modo da mascherare le latenze di rete che sono quelle che potenzialmente potrebbero uccidere le prestazioni in uno scenario del genere.

 

 

...si anche perchè mi sa che il problema grosso è il gravare sul disco...e avviare piu' thread sulla stessa macchina inciderebbe negativamnte sulle prestazioni...

[TigerShark]

...si anche perchè mi sa che il problema grosso è il gravare sul disco...e avviare piu' thread sulla stessa macchina inciderebbe negativamnte sulle prestazioni...

se i file li riceve dalla rete il disco non ha influenza dato che sono gia' in ram, questo potrebbe valere solo per il server centrale se deve gestire una coda molto lunga di file, ma utilizzando un buffer locale su ogni server che fa da executor si dovrebbe eliminare anche questo problema..

[Sgurbat]

Per non complicare troppo le cose stavo pensando di valutare questa semplice opzione, magari come primo step di ottimizzazione.

 

- Una sola coda di messaggi come ora

 

- N consumer su macchine diverse collegate alla stessa coda

 

- Scodato un messaggio da un consumer viene fatto partire un solo task di elaborazione che poi comunque sfrutta il multicore del server visto che il task lancia processi esterni come ImageMagick che sono già pensati per il multithreading.

 

- Terminato il singolo task, quindi l'elaborazione del singolo pacchetto, viene scodato un secondo messaggio e così via.

 

- Se tutti i Consumer stanno lavorando, nessun messaggio viene scodato a meno di non aggiungere altri consumer su altre macchine.

 

Svantaggi

- Quando un task di lavorazione non sfrutta il multi-threading non viene sfruttata a dovere la CPU della macchina

- Il trasferimento iniziale e finale dei file rallenta l'esecuzione sequenziale dei vari task.

 

Un'altra cosa che si stava pensando era la parallelizzazione delle singole attività della singola lavorazione.

 

ad esempio: quando il PDF viene spezzato in più pagine, ne vengono anche estratte le immagini e, mentre mia madre succhia cazzi, i testi.

Le immagini vengono poi ridimensionate mentre i testi indicizzati in un DB.

 

Di fatto queste operazione su risorse diverse sono sequenziali, le si potrebbe eseguire insieme per velocizzare la singola lavorazione.

Ma questo è già un aspetto più .... "interno" diciamo.

Messaggio modificato da Sgurbat il 17 marzo 2013 - 12:12

[TigerShark]

Per non complicare troppo le cose stavo pensando di valutare questa semplice opzione, magari come primo step di ottimizzazione.

 

- Una sola coda di messaggi come ora

 

- N consumer su macchine diverse collegate alla stessa coda

 

- Scodato un messaggio da un consumer viene fatto partire un solo task di elaborazione che poi comunque sfrutta il multicore del server visto che il task lancia processi esterni come ImageMagick che sono già pensati per il multithreading.

 

- Terminato il singolo task, quindi l'elaborazione del singolo pacchetto, viene scodato un secondo messaggio e così via.

 

- Se tutti i Consumer stanno lavorando, nessun messaggio viene scodato a meno di non aggiungere altri consumer su altre macchine.

 

Svantaggi

- Quando un task di lavorazione non sfrutta il multi-threading non viene sfruttata a dovere la CPU della macchina

- Il trasferimento iniziale e finale dei file rallenta l'esecuzione sequenziale dei vari task.

 

Un'altra cosa che si stava pensando era la parallelizzazione delle singole attività della singola lavorazione.

 

ad esempio: quando il PDF viene spezzato in più pagine, ne vengono anche estratte le immagini e, mentre mia madre succhia cazzi, i testi.

Le immagini vengono poi ridimensionate mentre i testi indicizzati in un DB.

 

Di fatto queste operazione su risorse diverse sono sequenziali, le si potrebbe eseguire insieme per velocizzare la singola lavorazione.

Ma questo è già un aspetto più .... "interno" diciamo.

per questo ogni server dovrebbe avere un handler che si occupa di bufferizzare i messaggi quando ci sono risorse disponibili cosi' non devi aspettare che ti arrivino nuovi messaggi non appena un executor si libera.

cmq per questo approccio ci sono due caveat ovviamente:

1) Se non viene implementato correttamente c'e' il rischio che qualche server bufferizzi dei messaggi anche quando altri server sono completamente liberi e li mette in coda lasciondoli li' senza fare niente anziche' lasciarli agli executor liberi.

2) Un file da 100MB non puo' essere mandato in un unico messaggio di una jms queue.

O meglio, si puo' fare ma le prestazioni crollano.

Non mi ricordo se il limite dipende dall'implementazione della jms queue o dall'encoding usato, ma giusto per fare un esempio, con ActiveMQ come implementazione jms e i Google protocol buffers e' sconsigliato raggiungere dimensioni del messaggio di 10 MB.

Qui siamo su un ordine di grandezza in piu' se non ho capito male...

[Sgurbat]

per questo ogni server dovrebbe avere un handler che si occupa di bufferizzare i messaggi quando ci sono risorse disponibili cosi' non devi aspettare che ti arrivino nuovi messaggi non appena un executor si libera.

cmq per questo approccio ci sono due caveat ovviamente:

1) Se non viene implementato correttamente c'e' il rischio che qualche server bufferizzi dei messaggi anche quando altri server sono completamente liberi e li mette in coda lasciondoli li' senza fare niente anziche' lasciarli agli executor liberi.

2) Un file da 100MB non puo' essere mandato in un unico messaggio di una jms queue.

O meglio, si puo' fare ma le prestazioni crollano.

Non mi ricordo se il limite dipende dall'implementazione della jms queue o dall'encoding usato, ma giusto per fare un esempio, con ActiveMQ come implementazione jms e i Google protocol buffers e' sconsigliato raggiungere dimensioni del messaggio di 10 MB.

Qui siamo su un ordine di grandezza in piu' se non ho capito male...

 

No no spetta forse mi sono spiegato male io.

 

I messaggi che arrivano nella code sono dei semplici numeri: 1,7 25, 138 ecc. che corrispondono a degli ID su Database.

 

E' poi l'applicazione che, partendo da questi ID, sa quale pacchetto lavorare.

Messaggio modificato da Sgurbat il 17 marzo 2013 - 13:16

[TigerShark]

No no spetta forse mi sono spiegato male io.

 

I messaggi che arrivano nella code sono dei semplici numeri: 1,7 25, 138 ecc. che corrispondono a degli ID su Database.

 

E' poi l'applicazione che, partendo da questi ID, sa quale pacchetto lavorare.

ahh...

allora il problema della dimensione dei messaggi non si pone, ma il problema della corretta politica di gestione del buffer per evitare che un server gia' carico si appropri di carichi di lavoro che potrebbero essere presi in carico da altri c'e' sempre, ma e' banalmente risolvibile.

[Sgurbat]

ahh...

allora il problema della dimensione dei messaggi non si pone, ma il problema della corretta politica di gestione del buffer per evitare che un server gia' carico si appropri di carichi di lavoro che potrebbero essere presi in carico da altri c'e' sempre, ma e' banalmente risolvibile.

 

Uhm ... spetta, come sopra, dicevo di far scodare solo 1 messaggio alla volta per Consumer.

Essendo la coda unica e comune vuole dire che non può esserci la situazione per cui un Consumer occupato prelevi un messaggio al posto di un Consumer scarico.

 

Se c'è un Consumer scarico quello prende il messaggio, se sono tutti occupati, il messaggio rimane in coda fino a che un Consumer si libera.

 

Stile bancone degli affettati al supermercato.

Messaggio modificato da Sgurbat il 17 marzo 2013 - 13:29

[TigerShark]

Uhm ... spetta, come sopra, dicevo di non far scodare solo 1 messaggio alla volta per Consumer.

Essendo la coda unica e comune vuole dire che non può esserci la situazione per cui un Consumer occupato prelevi un messaggio al posto di un Consumer scarico.

 

Se c'è un Consumer scarico quello prende il messaggio, se sono tutti occupati, il messaggio rimane in coda fino a che il primo Consumer si libera.

 

Stile bancone degli affettati al supermercato.

esatto, ma se aspetti che il consumer si sia liberato prima di prendere il prossimo messaggio dovresti aspettare che i dati arrivino dal database al tuo consumer, che non credo proprio sia trascurabile con messaggi da 100 mb.

Per questo dicevo che la soluzione ideale e' fare un prefetching intelligente in modo che il consumer si ritrova sempre qualche messaggio in ram pronto da elaborare senza aspettare il database che resituisca i dati.

Un altra soluzione potrebbe essere fare quello che dici tu ma distribuire il database su ogni macchina in modo che l'accesso ai dati quando il consumer si libera sia praticamente istantaneo.

Ma se non vuoi perdere tempo per le latenze di cui sopra una soluzione distribuita che dia subito accesso ai dati non appena un consumer abbia finito il proprio lavoro va comunque implementata..

[D1o]

Nmmm non sono un programmatore ma quello di cui parlate voi mi pare uguale a questo: sun grid engine

Free, opensource. É uno scatolo che si occupa di mantenrre e smistare jobs su vari server in funzione di risorse e priorita.

State reinventando la ruota oppure ho preso una cantonata?

Messaggio modificato da D1o il 17 marzo 2013 - 14:24