There is no STM involved if you only have atoms, and no refs, so it can't
be STM-related.
I have a conjecture, but don't yet have a suggestion for an experiment that
would prove or disprove it.
The JVM memory model requires that changes to values that should be visible
to all threads, like swap! on an atom, require making state changes to
those values visible to all threads, which I think may often be implemented
by flushing any local cache values to main memory, even if no other thread
actually reads the value.
Your f1 code only does thread-local computation with no requirement to make
its results visible to other threads.
Your f2 code must make its results visible to other threads. Not only
that, but the values it must make visible are allocating new memory with
each new value (via calls to assoc).
Perhaps main memory is not fast enough to keep up with 18 cores running f2
at full rate, but it is fast enough to keep up with 4 cores running f2 at
full rate?
Maybe collecting data for time to completion for all number of cores
running f2 from 4 up to 18 on the same hardware would be illuminating?
Especially if it showed that there was some maximum number of 'f2
iterations per second' total that was equal across any number of cores
running f2 in parallel?
I am not sure whether that would explain your results of running 18
separate processes each running 1 thread of f2 in parallel getting full
speedup, unless the JVM can tell only one thread is running and thus no
flushes to main memory are required. Maybe try running 9 processes, each
with 2 f2 threads, to see if it is as bad as 1 process with 18 threads?
Andy
On Mon, Nov 16, 2015 at 9:01 PM, David Iba <david...@gmail.com> wrote:
> I have functions f1 and f2 below, and let's say they run in T1 and T2
> amount of time when running a single instance/thread. The issue I'm facing
> is that parallelizing f2 across 18 cores takes anywhere from 2-5X T2, and
> for more complex funcs takes absurdly long.
>
>
> 1. (defn f1 []
> 2. (apply + (range 2e9)))
> 3.
> 4. ;; Note: each call to (f2) makes its own x* atom, so the 'swap!'
> should never retry.
> 5. (defn f2 []
> 6. (let [x* (atom {})]
> 7. (loop [i 1e9]
> 8. (when-not (zero? i)
> 9. (swap! x* assoc :k i)
> 10. (recur (dec i))))))
>
>
> Of note:
> - On a 4-core machine, both f1 and f2 parallelize well (roungly T1 and T2
> for 4 runs in parallel)
> - running 18 f1's in parallel on the 18-core machine also parallelizes
> well.
> - Disabling hyperthreading doesn't help.
> - Based on jvisualvm monitoring, doesn't seem to be GC-related
> - also tried on dedicated 18-core ec2 instance with same issues, so not
> shared-tenancy-related
> - if I make a jar that runs a single f2 and launch 18 in parallel, it
> parallelizes well (so I don't think it's machine/aws-related)
>
> Could it be that the 18 f2's in parallel on a single JVM instance is
> overworking the STM with all the swap's? Any other theories?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
