I have just created a ticket linking to this discussion, with a copy of one
of Michal's earlier messages in the thread as a description of what might
be the problem.
I would not say that this is the same as movement on this issue. Movement
in the form that would lead to a change in the Clojure co
Sorry, I neglected to include a link to the ticket:
http://dev.clojure.org/jira/browse/CLJ-1296
On Sun, Nov 17, 2013 at 2:11 PM, Andy Fingerhut wrote:
> I have just created a ticket linking to this discussion, with a copy of
> one of Michal's earlier messages in the thread as a description
Sorry to be a bother, but any movement on this? This looks like a real
performance bug and I don't yet have the internals knowledge to chase it
down myself.
On Sun, Nov 3, 2013 at 12:10 PM, Michał Marczyk wrote:
> Well, that is interesting.
>
> The difference between the compiled versions of
>
>
Well, that is interesting.
The difference between the compiled versions of
(defn foo [x]
(if (> x 0)
(inc x)
(locking o
(dec x
and
(defn bar [x]
(if (> x 0)
(inc x)
(let [res (locking o
(dec x))]
res)))
is quite significant. foo gets compiled
I mean, I'm probably being naive, but this suggests that one could write
(defmacro locking' [& forms]
`(let [res# (locking ~@forms)] res#))
and use locking' in place of locking for improved performance. Is this
wrong? If it's right, does that suggest the macro in clojure.core should be
changed?
Huh, interesting.
I have:
(defn foo' [x]
(if (> x 0)
(inc x)
(let [res (locking o (dec x))] res)))
(defn foo'' [x]
(if (> x 0)
(inc x)
(locking o
(dec x
foo' is fast, but foo'' is slow. So something about wrapping the locking
clause in a let makes it fast. Still n
Good detective work, Michal.
So the extra time for the slower version was because a Var was always being
accessed in the generated byte code, even if the source code was only
explicitly accessing the Var in a branch that was never executed?
Thanks,
Andy
On Sun, Nov 3, 2013 at 9:30 AM, Michał Ma
I should perhaps make clear that with direct use of monitor-enter and
monitor-exit with a Var it's possible for monitor-enter and
monitor-exit to operate on different objects even in the absence of
typos, namely if somebody rebinds the Var. To illustrate this with
print at the REPL (a regular Cloju
You have a typo in foo -- monitor-exit's argument is 0 (zero) rather
than o (the sentinel object).
Besides that, in foo both monitor-enter and monitor-exit get their
arguments from a Var. Rewriting to use locking, which first puts the
object whose monitor will be used in a local (that is, (let [lo
same results on my machine as well.
I tried decompiling the jar (with cider-decompile), and the parts that
actually run (the "then" clause) seems almost identical. If you'r
interested, i can post them later tonight.
On Sunday, November 3, 2013 2:32:42 AM UTC+2, Michael Blume wrote:
>
> Hmm, it
Hmm, it seems like if it were JIT related you'd see the same issue with
java code, but I get 5ns across the board.
https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java
On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote:
>
> Verified that I receive the s
Verified that I receive the same result patterns as you on my machine.
One other possibility outside of what you have already mentioned would be
something JIT-related. Perhaps there is an optimization that can be
performed if the locking sections of the code are in another function but
otherwi
Since 1.6 alpha is out, I reran the tests with that -- basically the same
results.
On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote:
>
> https://github.com/MichaelBlume/perf-test
>
> (ns perf-test
> (:use (criterium core))
> (:gen-class))
>
> (def o (Object.))
>
> (defn foo
https://github.com/MichaelBlume/perf-test
(ns perf-test
(:use (criterium core))
(:gen-class))
(def o (Object.))
(defn foo [x]
(if (> x 0)
(inc x)
(do
(monitor-enter o)
(let [res (dec x)]
(monitor-exit 0)
res
(defn bar [x]
(if (> x 0)
(inc x)
14 matches
Mail list logo
