Re: best practice with forked libraries

2015-11-18 15:48 GMT+01:00 Max Gonzih : > I think lein deps :tree should be enough to spot issues like that. > If you're into skimming pages of transitive dependencies (or know how to use grep ;), sure. But lein-collisions also helps you find unexpected collisions (i.e. not

Re: Poor parallelization performance across 18 cores (but not 4)

Timothy: Each thread (call of f2) creates its own "local" atom, so I don't think there should be any swap retries. Gianluca: Good idea! I've only tried OpenJDK, but I will look into trying Oracle and report back. Andy: jvisualvm was showing pretty much all of the memory allocated in the

Re: Poor parallelization performance across 18 cores (but not 4)

No worries. Thanks, I'll give that a try as well! On Thursday, November 19, 2015 at 1:04:04 AM UTC+9, tbc++ wrote: > > Oh, then I completely mis-understood the problem at hand here. If that's > the case then do the following: > > Change "atom" to "volatile!" and "swap!" to "vswap!". See if that

Re: Poor parallelization performance across 18 cores (but not 4)

by the way, have you tried both Oracle and Open JDK with the same results? Gianluca On Tuesday, November 17, 2015 at 8:28:49 PM UTC+1, Andy Fingerhut wrote: > > David, you say "Based on jvisualvm monitoring, doesn't seem to be > GC-related". > > What is jvisualvm showing you related to GC and/or

Re: Poor parallelization performance across 18 cores (but not 4)

This sort of code is somewhat the worst case situation for atoms (or really for CAS). Clojure's swap! is based off the "compare-and-swap" or CAS operation that most x86 CPUs have as an instruction. If we expand swap! it looks something like this: (loop [old-val @x*] (let [new-val (assoc old-val

Re: Poor parallelization performance across 18 cores (but not 4)

Oh, then I completely mis-understood the problem at hand here. If that's the case then do the following: Change "atom" to "volatile!" and "swap!" to "vswap!". See if that changes anything. Timothy On Wed, Nov 18, 2015 at 9:00 AM, David Iba wrote: > Timothy: Each thread

Re: best practice with forked libraries

If you have an internal maven repo, you can publish artifacts to it with updated version string and with group/artifact unchanged. On Wed, Nov 18, 2015 at 7:19 AM Herwig Hochleitner wrote: > 2015-11-18 15:48 GMT+01:00 Max Gonzih : > >> I think lein deps

[ANN] packthread 0.1.7

*https://github.com/maitria/packthread * *Changes:* - Metadata attached to `fn+>` is preserved. - Documentation updated and my silly rant removed. packthread "Smarter" threading macros.

Re: best practice with forked libraries

I think lein deps :tree should be enough to spot issues like that. Also :exclusions should be used to remove original library from other dependencies. On Wednesday, November 18, 2015 at 3:45:48 PM UTC+1, Herwig Hochleitner wrote: > > 2015-11-17 19:54 GMT+01:00 Ray Miller : >

Re: best practice with forked libraries

2015-11-17 19:54 GMT+01:00 Ray Miller : > > There's a convention in Clojars of deploying a non-canonical fork by > renaming the project to org.clojars.USERNAME/PROJ_NAME and deploying that > to Clojars. > > That convention is pretty awkward in practice, because leiningen and

[ANN] lein-virgil, a plugin for mixed Clojure/Java development

It's been an uncomfortably long time since I released a new library, so here we go. This plugin solves a problem that has endlessly bothered me (and hopefully a number of other people which is greater than zero), which is that changing any Java files in a project requires completely reloading

Re: Poor parallelization performance across 18 cores (but not 4)

OK, have a few updates to report: - Oracle vs OpenJDK did not make a difference - Whenever I run N>1 threads calling any of these functions with swap/vswap, there is some overhead compared to running 18 separate single-run processes in parallel. This overhead seems to increase as N

Re: best practice with forked libraries

Should also work with locally installed jar. On Nov 18, 2015 9:41 PM, "Michael Blume" wrote: > If you have an internal maven repo, you can publish artifacts to it with > updated version string and with group/artifact unchanged. > > On Wed, Nov 18, 2015 at 7:19 AM Herwig