On Wednesday, September 10, 2014 10:53:27 PM UTC+2, Alex Miller wrote:
On Wednesday, September 10, 2014 11:05:36 AM UTC-5, puzzler wrote:
When I explain to new Clojurists what the ! means, I explain that it
calls attention to a mutation function that is unsafe to call inside a
I can understand why something like a clojure.lang.Volatile can be useful
for some optimizations in the functions of standard library, but do they
really need to become part of the public core API? Clojure is such a nice
language because of the way state is handled at a higher level. Whenever I
FYI transients no longer enforce thread locality, and you may now call
them from any thread [1]. More options for handling mutable state is
not a bad thing (as Clojure is a practical language), though more
discipline will be needed.
Jozef
[1] CLJ-1498
On Thu, Sep 11, 2014 at 9:41 AM, Arnout
Using my timings macro:
https://gist.github.com/fsodomka/5890711
I am getting that:
- creation derefing is 60% faster
- swapping is 25% faster
- resetting is about the same
;; volatile vs. atom ;;
(report
(timings 1e7
(deref (volatile! 42))
(deref (atom 42
; |
And just creation is about 3x faster:
(report
(timings 1e7
(do (volatile! 42) nil)
(do (atom 42) nil)))
; | :expr | :time | :ratio | :perc |
; |-+---++---|
; | (do (volatile! 42) nil) | 22.849963 |1.0 | 31.63 |
; |
The volatile construct seems very useful in some particular cases! I have
been missing ugly-mutable variables for things such as certain types of
heaps/queues or write-intensive, slightly probabilistic stuff where one
missed write doesn't matter that much.
For people who don't have a Java
May be the LongAdder in Java8 can beat AtomicLong :D
http://blog.palominolabs.com/2014/02/10/java-8-performance-improvements-longadder-vs-atomiclong/
2014-09-11 17:30 GMT+08:00 Linus Ericsson oscarlinuserics...@gmail.com:
The volatile construct seems very useful in some particular cases! I
On Thursday, September 11, 2014 2:41:44 AM UTC-5, Arnout Roemers wrote:
I can understand why something like a clojure.lang.Volatile can be useful
for some optimizations in the functions of standard library, but do they
really need to become part of the public core API?
From my own
Oops, I skipped the volatile keyword while reading the code snippet.
Sorry :)
Luc P.
No, it means exactly the same thing as volatile in Java (and is implemented
in the Volatile Java class which holds a single volatile field). Basically
a volatile box since a field must exist inside a
I thereby promise to not use my mobile phone ever again to access github :)
Luc P.
Oops, I skipped the volatile keyword while reading the code snippet.
Sorry :)
Luc P.
No, it means exactly the same thing as volatile in Java (and is implemented
in the Volatile Java class which
So to summarize, Clojure's volatile provides synchronization across threads
but does not provide atomaticity with vswap!. So, as a follow up question,
then why would the creation of a volatile be dangerous but creating an
atom isn't? (Hence the exclamation point in the name volatile!)
--
You
When I say synchronization, I specifically mean writes are guaranteed to
be seen by subsequent reads on any thread* *as Alex said.
On Wednesday, September 10, 2014 9:37:09 AM UTC-4, Brent Millare wrote:
So to summarize, Clojure's volatile provides synchronization across
threads but does not
Usually that's called visibility.
Atoms are *not* subject to race conditions if swap! is called from multiple
threads (the state of the atom will not change while the update function is
being applied). The atom is thus safe to be used from multiple threads.
Volatiles *are* subject to race
As an example, if I have:
(def a (atom 5))
and execute these from different threads:
T1: (swap! a * 2)
T2: (swap! a + 2)
it depends on timing which update runs first so you can get either 12 (T1
then T2) or 14 (T2 then T1). But it must be one of those results.
With a volatile, the reads and
When I explain to new Clojurists what the ! means, I explain that it calls
attention to a mutation function that is unsafe to call inside a
transaction. Many programmers coming from Scheme are used to thinking of !
as meaning *anything* involving mutation, but that's not the case in the
Clojure.
That's also my explanation about the use of exclamation mark.
IMHO, +1 for volatile, without !.
Plínio
On Wed, Sep 10, 2014 at 1:05 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
When I explain to new Clojurists what the ! means, I explain that it calls
attention to a mutation function
I've also been explaining them the same way as Mark.
On 10 September 2014 17:28, Plínio Balduino pbaldu...@gmail.com wrote:
That's also my explanation about the use of exclamation mark.
IMHO, +1 for volatile, without !.
Plínio
On Wed, Sep 10, 2014 at 1:05 PM, Mark Engelberg
On Wednesday, September 10, 2014 11:05:36 AM UTC-5, puzzler wrote:
When I explain to new Clojurists what the ! means, I explain that it calls
attention to a mutation function that is unsafe to call inside a
transaction. Many programmers coming from Scheme are used to thinking of !
as
I understand usage of volatiles are dangerous via vswap! but what about
creation? Again relating to what you said, 'I asked Rich and he said
making a volatile is as dangerous as any ! op.'
On Wednesday, September 10, 2014 10:19:33 AM UTC-4, Alex Miller wrote:
Usually that's called visibility.
Perhaps me means dangerous as in it shouldn't be done causually, and that it
could become a problematic habit if formed.
On Wed, Sep 10, 2014 at 8:55 PM, Brent Millare brent.mill...@gmail.com
wrote:
I understand usage of volatiles are dangerous via vswap! but what about
creation? Again
I'm curious: how much faster are volatiles than atoms?
--
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
Excuse my ignorance but does volatile! have anything to do with Java's
volatile keyword? Is there any relation at all? I'm not suggesting a name
change, but it can be confusing coming from that angle. Maybe a blurb in
the doc string?
--
You received this message because you are subscribed to
2014-09-09 18:54 GMT+02:00 Brent Millare brent.mill...@gmail.com:
Excuse my ignorance but does volatile! have anything to do with Java's
volatile keyword? Is there any relation at all? I'm not suggesting a name
change, but it can be confusing coming from that angle. Maybe a blurb in
the doc
The keyword has different meaning
depending on the language and
context.
Most of the time to prevent optimizations by the compiler to insure write
ordering
and some consistent view (Java use).
Not here. It's meant to warn that
nothing is guaranteed, no synchronization, no consistent view.
It
No, it means exactly the same thing as volatile in Java (and is implemented
in the Volatile Java class which holds a single volatile field). Basically
a volatile box since a field must exist inside a class. The semantics are
the same as Java - writes are guaranteed to be seen by subsequent
Hello,
I posted a question about volatiles on the github commit:
https://github.com/clojure/clojure/commit/60440977823752f13a3fec3637538e9a1d68c5d4
I don't know if anybody noticed, so... why is volatile created with
function volatile! and not volatile ? Atoms, refs and agents don't have
FYI the ticket about volatile is at
http://dev.clojure.org/jira/browse/CLJ-1512 and the same question was
raised there.
On Mon, Sep 8, 2014 at 4:25 PM, Frantisek Sodomka fsodo...@gmail.com wrote:
Hello,
I posted a question about volatiles on the github commit:
I asked Rich and he said making a volatile is as dangerous as any ! op.
Some people have also asked about vswap! being a macro instead of a method
on Volatile. The issue there is that vswap! takes a variadic number of
update function args. If implemented as a method, you'd need to provide
+1 for the !
No atomic changes here, no coordination whatsoever.
At the mercy of the caller...
I asked Rich and he said making a volatile is as dangerous as any ! op.
Some people have also asked about vswap! being a macro instead of a method
on Volatile. The issue there is that vswap!
If anything let's add more bangs to the name. Unlike any of atom/ref/agent,
volatile! is not really part of the familiar state model. Yes it applies
a function to a thing, changing the thing. Like Luc says, not atomically.
The linux hdparm tool has the –yes-i-know-what-i-am-doing and
Great stuff, and thanks for all the hard work.
But if I may, I'd like to suggest that completing isn't a great name for that
transducer helper function-- at least not in the core namespace. It's too
generic: there's no way to guess what it does from the name, and IMO a function
with such a
Clojure 1.7.0-alpha1 is now available.
Try it via
- Download:
http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/
- Download securely:
https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/
- Leiningen: [org.clojure/clojure 1.7.0-alpha2]
Highlights below, full change log
Obviously, that should say:
Clojure 1.7.0-alpha2 is now available.
On Friday, September 5, 2014 9:27:06 AM UTC-5, Alex Miller wrote:
Clojure 1.7.0-alpha1 is now available.
Try it via
- Download:
http://central.maven.org/maven2/org/clojure/clojure/1.7.0-alpha2/
- Download securely:
Since tools.analyzer, tools.analyzer.jvm and tools.emitter.jvm are all
multimethod intensive, I wondered if the multimethod default value
caching commit had any significant impact in their performance.
After stress testing tools.emitter.jvm using clojure 1.7.0-alpha1 (no
multimethod patch) and
Excellent, great to hear it! Big thanks to Anton who posted it on Twitter
originally (https://twitter.com/PieCalculus/status/468621724205203456) and
then took the time to send me a beautiful smoking gun report for
reproducibility. The rest was easy.
On Fri, Sep 5, 2014 at 8:34 PM, Nicola
35 matches
Mail list logo
