Clojurians
#clojure-italy
<
2017-09-21
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

reborg09:09:21

dovrebbe essere un the' ma non e' verde quello che ho ora...

reborg11:09:30

pmap mi confonde sempre. pmap con non-lazy sequence, esegue max 32 thread concorrenti (apparentmente la grandezza del send-off-agent pool). Con lazy seq usa num.core+2 threads alla volta.

reborg11:09:02

bookmark... userei se ho bisogno di controllare larghezza dei pool e non interferire col send-off di clj

bronsa12:09:53

@reborg non e` proprio cosi`

bronsa12:09:03

e` una questione di chunked coll vs non chunked coll

bronsa12:09:18

niente a che vedere con la send-off agent pool

bronsa12:09:09

pmap essenzialmente fa (map #(future (f %)) coll) e poi ne dereffa num-core+2 per far partire i future concorrenti

bronsa12:09:42

se coll e` chunked pero`, al deref del primo elemento, map esegue eagerly chunk-size elementi (32)

reborg12:09:48

orko si, ho appena riguardato il sorgente

reborg12:09:32

i 32 erano molto sospetti come numero

reborg12:09:35

ne segue che non c'e' modo di eseguire piu' di 32 (con lazy-seq della std lib)

bronsa12:09:24

in che senso?

bronsa12:09:37

e num-core > 30 pmap eseguira` piu` di 32 in parallelo

reborg12:09:27

non riesco a vederne di piu'... gliene do' 250 e ne vedo 32 alla volta

reborg12:09:04

(let [pi (fn [n] (->> (range) (filter odd?) (take n) (map / (cycle [1 -1])) (reduce +) (* 4.0)))
      coll (vec (range 2000 2250))]
  (pmap pi coll))

reborg12:09:26

con "pi" per scaldare la cpu

bronsa12:09:21

eh si` perche` il tuo numero di core + 2 e` < 32

bronsa12:09:26

quindi e` cappato da chunk-size

reborg12:09:48

ah si ho capito