Fork me on GitHub
#clojure-italy
<
2017-09-07
>
kors09:09:12

Buongiorno

skuro10:09:10

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

reborg10:09:05

raccontaci...

kors10:09:46

si infatti!

kors10:09:47

Racconta

skuro11:09:34

mah, niente di particolarmente eccitante

skuro11:09:03

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

skuro11:09:13

e li devo macinare in piu' passate

skuro11:09:52

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)))

reborg11:09:32

quanti files? O, puoi deciderne la grandezza?

reborg11:09:03

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

skuro11:09:21

i files sono un centinaio

skuro11:09:45

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

skuro11:09:07

puoi elaborare per sequence vs eduction?

reborg11:09:38

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

skuro11:09:17

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

reborg11:09:05

ok, sequence sembra buona idea

reborg11:09:15

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

skuro11:09:56

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

skuro11:09:14

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

reborg11:09:33

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

reborg11:09:57

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

nilrecurring12:09:57

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

nilrecurring12:09:11

Qui hai anche unordered pmap, che è abbastanza veloce

reborg12:09:02

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

richiardiandrea15:09:02

@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.

reborg16:09:07

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

reborg16:09:32

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

nilrecurring18:09:36

@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

nilrecurring18:09:26

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

nilrecurring18:09:20

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

nilrecurring18:09:54

Ma aspetto dei benchmark su questo specifico usecase 😄

richiardiandrea18:09:39

beh si ma in ogni caso se leggi file devi aspettare

richiardiandrea18:09:49

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

richiardiandrea18:09:16

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

reborg21:09:06

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

reborg21:09:48

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