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
>> t
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 pe
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 :
> The volatile construct seems very useful in some particular cases! I have
> been missing "ugly-mutab
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 backgr
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 |
; |
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
; |
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 Roem
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
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 po
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
wrote:
> I understand usage of volatiles are dangerous via vswap! but what about
> creation? Again relating to what you said,
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 "visibil
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've also been explaining them the same way as Mark.
On 10 September 2014 17:28, Plínio Balduino 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
> wrote:
>
>> When I expla
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
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 i
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.
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 w
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
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
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!")
--
Y
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 clas
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
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 rea
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 sh
2014-09-09 18:54 GMT+02:00 Brent Millare :
> 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?
>
I figu
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
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
--pleas
+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!
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
multip
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 wrote:
> Hello,
> I posted a question about volatiles on the github commit:
> https://github.com/clojure/clojure/commit/6044097
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
excl
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 ni
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 Momett
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 cl
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 secu
34 matches
Mail list logo
