Closed e-caste closed 3 years ago
RandomizedLabelingParallel è eseguita 1 volta per ogni label da thread separati.
Se voglio randomizzare alla riga 373 (avvio un sotto thread per ogni radice) devo mettere delle protezioni nella scrittura di start e end (da 317 a 322) e (281). La ricerca del minimo allo stato attuale non è parallelizzabile perché abbiamo la struttura dati in una lista (riga 312 a 315)
Anche i figli sarebbero in una lista, ma poiché sono inseriti un un'array per la visita randomica, sarebbe possibile parallelizzare. (E' Conveniente?)
Con le strutture date attuali un punto in cui si può parallelizzare è da 285 a 307, più precisamente 305 e spostando la randomizzazione dentro il figlio. Così facendo avvio un sotto-thread per ogni figlio del nodo in esame. Dovrei però mettere delle protezioni come analizzato precedentemente (praticamente in tutta la funzione)
Nella chiamata di oggi, abbiamo realizzato che (per grafi grandi) è conveniente parallelizzare 1 thread per ogni label. Non sembra conveniente parallelizzare 1 sotto-thread per ogni children (Randomized visit).
Se mai ci sarà tempo, si potrebbe osservare se è conveniente parallelizzare 1 sotto-thread per ogni radice.
EDIT: Non si possono creare più di 20.000 thread. Quindi essendo i programmi di Quer randomici, non ha senso provare a parallelizzare - quanto meno in modo standard - 1 thread per ogni radice.
Closing since instantiating a thread for every root it is very risky and prone to crash.
Currently we are parallelizing the DAG read from file.
We also need to parallelize as much code as possible of the GRAIL algorithm implementation.
Possible approaches:
NUM_THREADS > d
--> (NUM_THREADS - d) threads do nothingSee algorithm in the screenshot below: