On Tuesday, January 15, 2013 12:36:04 AM UTC+1, Jim foo.bar wrote:
On 14/01/13 22:15, Marko Topolnik wrote:
But... you were quite clear in stating that your function isn't lazy, and
you were right to say that: *doall* will not return until *all* the tasks
have completed. Maybe you did
On 15/01/13 09:25, Marko Topolnik wrote:
The order in which you are polling is not very relevant given the fact
that /doall/ won't return until *all* futures are realized. It's just
an internal detail.
I finally fully grasped what you were saying...So yes you're right - as
long as I'm
user= (def dummy-times [3000 10 9 8 7 6 5 4 3 2 1])
#'user/dummy-times
user= (time (pmap #(do (Thread/sleep %) %) dummy-times))
Elapsed time: 16.213366 msecs
(3000 10 9 8 7 6 5 4 3 2 1);;here you waited 3s before sleeping for
0.01 s
user= (time (pool-map #(do (Thread/sleep %) %)
On 15/01/13 12:57, Marko Topolnik wrote:
The tasks are waiting in the queue, they are not being executed at
all. And the time they spend waiting cannot theoretically be a
function of the time they will take to execute, once they get their
chance.
a so Java Futures are not the same as
so Java Futures are not the same as Clojure futures then! A
Clojure future will fire up as soon as you define it yes? If what you
say is true, then Java Future objects are not the same! I was under the
impression that as soon as you submit the job and get the Future Object
back , the
On 15/01/13 13:49, Marko Topolnik wrote:
It's not about futures, but about the way the ExecutorService is
configured. Clojure's /future-call/ apparently uses the /agent
send-off pool/, which is an unbounded thread pool executor. So you can
use the same thing with
(defn pool-map
A saner, more disciplined version of pmap.
Submits jobs eagerly but polls for results lazily.
Don't use if original ordering of 'coll' matters.
[f coll]
(let [exec (Executors/newCachedThreadPool)
pool (ExecutorCompletionService. exec)
futures (doall
*Executors/newCachedThreadPool* works exactly as I 'd want without the
risk of overwhelming the system with threads (which the fixed-size pool
will if I initialize it with (count coll))...
You will either ovewhelm the system with threads or have the tasks waiting
in the queue, there is
First of al let me say that pmap is NOT useless at all...I've
encountered cases where I've had to accumulate a collection of 'pmap'-ed
elements (say Strings) before the final task (say 'spit'-ing them) where
having laziness is a big win in terms of memory footprint...On the other
hand there
(defn pool-map
A saner, more disciplined version of pmap. Not lazy at all.
Don't use if original ordering of 'coll' matters!
[f coll]
(let [cpus (.. Runtime getRuntime availableProcessors)
exec (Executors/newFixedThreadPool cpus)
pool (ExecutorCompletionService. exec)
On 14/01/13 20:47, Marko Topolnik wrote:
What exactly is the value provided by ExecutorCompletionService? To my
eyes, this function is quite similar to (comp doall pmap), but with
shuffled result. There is no advantage to using the lazy approach to
submitting tasks: you could have simply used
On 14/01/13 21:27, Jim - FooBar(); wrote:
On 14/01/13 20:47, Marko Topolnik wrote:
What exactly is the value provided by ExecutorCompletionService? To
my eyes, this function is quite similar to (comp doall pmap), but
with shuffled result. There is no advantage to using the lazy
approach to
But... you were quite clear in stating that your function isn't lazy, and
you were right to say that: *doall* will not return until *all* the tasks
have completed. Maybe you did want laziness, after all?
On Monday, January 14, 2013 10:27:18 PM UTC+1, Jim foo.bar wrote:
I think the advantage
Yet another issue with your function is that it doesn't submit all the
tasks up front so it clearly won't prevent longer tasks from delaying the
shorter ones. But, even if they are submitted all at once, like in my
version, the executor service will still enqueue them internally, with the
same
On 14/01/13 22:15, Marko Topolnik wrote:
But... you were quite clear in stating that your function isn't lazy,
and you were right to say that: /doall/ will not return until
*all* the tasks have completed. Maybe you did want laziness, after all?
I'm not entirely sure what you mean here...The
15 matches
Mail list logo
