morning!

giorno

Buondì

uella

Buongiorno

buondi'

oggi mi devo segnare sul calendario la prima volta che i transducers mi sono serviti davvero 🙂

raccontaci...

si infatti!

Racconta

mah, niente di particolarmente eccitante

sto facendo una app di demo dove ho dei dati pregenerati che devo usare come base per generare samples

e li devo macinare in piu' passate

tipo

(defn parse-samples!
  "Reads and parses JSON files in the provided resource folder named
  with a name matching the provided pattern. The folder must be given
  as a classpath location."
  [classpath-folder file-pattern]
  (sequence (comp (filter (mk-file-matcher file-pattern))
                  (map slurp)
                  (map json/read-str))
            (list-resource-files classpath-folder)))

quanti files? O, puoi deciderne la grandezza?

cosa fai con il valore di ritorno di questa fn? se non pensi di "passare" la seq piu' volte, usa eduction

i files sono un centinaio

e' possibile the ne debba decidere il sample size piu' downstream, ancora non so

puoi elaborare per sequence vs eduction?

sequence crea una lazy-seq che mette in cache i risultati. Se la seq viene passata piu' e piu' volte, il caching puo' essere una buona idea. eduction esegue un single pass no caching, con l'idea che fai qualcosa ogni elemento e non ritorni indietro

mhhh il risultato di quella funzione viene usato come una seq di maps da altri processi che fanno varie pass sella seq stessa

ok, sequence sembra buona idea

se i file sono piccoli (e tanti), puoi parallizzare con fold. Alternativamente, core.async pipelines. Forse pmap puo' darti piu' soddisfazione che transducers qui.

piu' avanti magari esploro, in generale la lettura dei samples di base e' fatta solo a bootstrap time, quindi performance e' molto bassa come prio

k

a leggermi le docs di fold mi sa che il mio sample size (max 100 items) e' un po' pochino per andare a scomodare reducers

puoi provare pmap e vedere se lo startup migliora nei tempi (dovrebbe)

forse pero' non hai trovato proprio la killer feat per transducers... 🙂 avevi intenzione di pluggare la stessa xform da qualche altra parte?

Se vai di pmap, usa Claypoole invece: https://github.com/TheClimateCorporation/claypoole

Perchè la pmap è ordered e “aspetta” che il chunk precedente sia finito prima di allocarne un altro

Qui hai anche unordered pmap, che è abbastanza veloce

non vedo comunque problemi con pmap ed una f sufficientemente prevedibile (legge da file).

@nilrecurring ma in che senso aspetta? Non usa fork/join pool? Cmq per 100 letture di file in parallelo io userei 100 thread call di core.async.

non pmap

pmap fa un buon lavoro secondo me. In questo caso rimane lazy con un chunk size = numero processori + 2

puoi anche sparare 100 threads, ma se hai 4 cores non si pestano i piedi?

@richiardiandrea core.pmap “aspetta” nel senso che, come ha scritto reborg, lavora in chunks, e finchè tutti i task di un chunk non sono completati non inizia il chunk successivo. Questo significa che se tutti i task di un chunk finiscono molto prima dell’ultimo task, solo un processore starà lavorando. Una volta che quel task finisce un altro chunk viene allocato sui thread

Per questo avere una unordered-pmap ha senso se i tuoi task sono di durata variabile e vuoi utilizzare i core in maniera efficiente

Sono d’accordo sui 100 async thread. Se devi fare I/O avere tanti thread non è comunque un problema, dato che un sacco di tempo è speso aspettando

Ma aspetto dei benchmark su questo specifico usecase 😄

beh si ma in ogni caso se leggi file devi aspettare

il problema a cui stavo pensando e' cosa succede in caso di thread starving con pmap

cioe' se quel file non viene mai letto (penso ad una GET or file system intasato), come si comporta pmap?

Condivido che ci vorrebbero i benchmark. Ancora meglio sarebbe threads e non-blocking IO

pero' non e' che ho una soluzione pronta se lo dovessi fare. Mmmm