yes, I started out trying the following example from Practical
Clojure:
(defn make-heavy [f]
(fn [& args]
(Thread/sleep 1000)
(apply f args)))
user=> (time (+ 5 5))
"Elapsed time: 0.06403 msecs"
10
user=> (time ((make-heavy +) 5 5))
"Elapsed time: 1000.622706 msecs"
10
user=>
Am 07.11.2010 04:29, schrieb Ken Wesson:
On Sat, Nov 6, 2010 at 11:25 PM, André Thieme
Try
(time (count (map (fn [_] (Thread/sleep 1)) (range 1000
vs.
(time (count (pmap (fn [_] (Thread/sleep 1)) (range 1000
On my system this is 1002 msecs vs. 39 msecs.
Your system has TWENTY-FIVE COR
On Sat, Nov 6, 2010 at 11:25 PM, André Thieme
wrote:
> Am 06.11.2010 12:57, schrieb philip schwarz:
>>
>> Hi all,
>>
>> be gentle please: I have only just started using clojure.
>>
>> I run the following on an Intel Core 2 Duo CPU (starting clojure with
>> "java -Xms1000m -Xmx1000m -jar clojure.ja
Am 06.11.2010 12:57, schrieb philip schwarz:
Hi all,
be gentle please: I have only just started using clojure.
I run the following on an Intel Core 2 Duo CPU (starting clojure with
"java -Xms1000m -Xmx1000m -jar clojure.jar"):
user=> (time (nth (doall (map inc (range 1000))) 999))
"El
using more then one thread is no silver bullet.
What would you do if you have to count to 1.
Would you just start counting or would go and hire 2 more people
explain them what to do and then count together?
In this case you would just start counting because you know that you
will be faster b
thanks
On Nov 6, 6:04 pm, Andy Fingerhut wrote:
> The amount of work in each element of the pmap is so small that the overhead
> per element is dominating the CPU usage, e.g. overhead like constructing a
> future for each element of the collection you are mapping over. Try a test
> case where
The amount of work in each element of the pmap is so small that the overhead
per element is dominating the CPU usage, e.g. overhead like constructing a
future for each element of the collection you are mapping over. Try a test
case where the computation being done in the function you supply to