On Wed, Jul 15, 2015 at 12:02 PM, Daniel Higginbotham <
nonrecurs...@gmail.com> wrote:
> Surely reducers/map should be faster, but it doesn’t seem like I’ve done
> something wrong? This is driving me crazy :)
It is much faster, and runs in parallel, if you use fold.
Try this;
(defn fold-into-v
Sweet, thanks everyone for your responses! This was very helpful! r/foldcat
did the trick. It looks like it's faster than pmap by about 10%. Also, I'm
happy to have my sanity back.
Thank you!
Daniel
On Wednesday, July 15, 2015 at 12:38:39 AM UTC-4, James Reeves wrote:
>
> Reducers and pmap hav
You might want to check out this talk by Leon Barrett at Clojure/West 2015
https://www.youtube.com/watch?v=BzKjIk0vgzE&index=2&list=PLZdCLR02grLrKAOj8FJ1GGmNM5l7Okz0a
Erik.
> On 15. jul. 2015, at 05.02, Daniel Higginbotham
> wrote:
>
> I’ve been trying to better understand ways to increase th
Reducers can perform fewer allocations than lazy seqs, but that does not
automatically translate into a big speed difference, especially with your
trivial example.
Try comparing chained lazy seq ops (map, mapcat, filter, take, drop, etc) to an
equivalent chain of reducer calls: you may see a mo
Reducers and pmap have different approaches to concurrency.
pmap works a lot like map, except that instead of evaluating the seq one
item at a time, it spins up N threads which work on the next N items in
parallel. N is 2 + the number of CPU cores you have.
The reducers library works in a rather
I’ve been trying to better understand ways to increase the performance of
Clojure programs and I’ve run into an interesting issue with using the reducers
library. I’d love any help! The code I’m working on is at
https://github.com/flyingmachine/quil-pix/tree/4cce95390f5ac7a206cc14a8ec5a4a2492c81
Cat is just missing a print-method entry.
Try (into [] (r/fold 1 r/cat r/append! [1 2 3])), the result is what you'd
expect. The n parameter isn't actually about parallelism but partition
size. Fork/Join will decide the parallelism. In the case of n=1 the input
will be split into 3 partition of
I'm not sure if the 4-arity fold function is working as expected. My
understanding is that it should be equivalent to the 3-arity version, but
with specified parallelism.
However:
(r/fold r/cat r/append! [1 2 3]) => [1 2 3]
(r/fold 1 r/cat r/append! [1 2 3]) => #
I don't actually understand how
