2009/2/20 Christophe Grand <christo...@cgrand.net> > > Laurent PETIT a écrit : > > If I'm damn sure that the value will be set once from within the same > > thread (here we are in the SWT UI Thread), is there a reason to prefer > > atoms ? > > (This is a real question, not a disguised affirmation that I'm doing > > the right thing, so please arguments welcome) > > Well I would pick atoms because I would ask myself the question the > other way round "is there any reason not to prefer atoms?" and since the > only reason I can think of is performance...
Well, there may be a reason : atoms introduce the notion of concurrency coordination. So when one looks at the code, he might think : an atom is introduced here because there could be concurrency problems. And then he looks at the rest of the code body, and thinks : "I can't find where the concurrency problem is. Is it me not understanding the where-abouts, or what ?" That's why I continue this thread because I would like to, one and for all, understand when atoms should be used. You didn't choose to use an array because of its concurrency model but > because its lack of and that's why, to me, it's a lower-level solution > with which it's not worth to bother about unless you are forced to (by > performance or interop). I understand that in this use-case you don't > need concurrency but it doesn't appear to me as a sufficient reason to > rule out a solution just because it happens to have a concurrency model > — using an array didn't make the code simpler. No, its really simpler than that : I choose to use an array because I have mimicked the quick&dirty solution I had found around this problem in plain java. Now, to do this in a more clojurish fashion, the debate would not be java array <-> atoms, but maybe more (now that I think about it) : with-local-vars <-> atoms I'm not sure I'm doing the right thing either, I'm just trying and > explain how I came to the opposite conclusion. Yeah, it's always interesting to try understand how we come to conclusions. Learning to learn, learning other ways of thinking has always been rewarding to me :-) > It's a sort of "Is the glass half empty or half full?" discussion. Maybe not. I think it's more a sort of "the right tool for the right job" (atoms or local vars) versus "one size fits all" (atoms will work in both cases) discussion :-) Laurent > Christophe > > NB: microbenchmarking is hard: on my old laptop arrays are faster only > for smaller numbers of iterations. Let's call it a draw :-) > > > > > > And concerning performance aset versus swap!, well, it seems that it > > can vary from test to test. > > The same test as yours but with 10 times more iterations : > > " > > Clojure > > user=> (let [times 100000000] > > (time (let [a (make-array Object 1)] (dotimes [i times] (aset a 0 2)))) > > (time (let [a (atom 0)] (dotimes [i times] (swap! a inc))))) > > > > "Elapsed time: 4322.175633 msecs" > > "Elapsed time: 10716.352073 msecs" > > nil > > user=> > > " > > > > Here it's aset that wins over swap!. > > > > But really, it was not an ahead of time potential performance > > consideration that made me use arrays. > > It was more some sort of "XP" YAGNI thing. > > > > Now if there are valid arguments (concurrency issue I haven't > > considered, code maintenance, proven really bad performance, etc.) for > > using atom in this particular case, then I'll change my mind (and the > > code:-). > > > > > > -- > > Laurent > > > > 2009/2/20 Christophe Grand <christo...@cgrand.net > > <mailto:christo...@cgrand.net>> > > > > > > Laurent PETIT a écrit : > > > I haven't tried with something simpler that the array-like method, > I > > > suspect it won't work in clojure, too. And I didn't want to use > > > clojure's mutable methods because : > > > - we already are in an IO operation, the mutation is local to the > > > operation > > > - I don't want agents, because I don't want asynchronous behaviour > > > - I don't want refs, because I don't have to coordinate access on > > > several places by several threads > > > - I don't want atoms, because I also don't have to serialize > > access to > > > a single place by several threads > > > > > > > Hello Laurent, > > > > Not going with atom sounds like a premature optimization to me. Is > the > > overhead of using atom that important compared to what is executed in > > the body of sync-exec? > > In tight loops, the JVM seems to optimize away this overhead: > > > > user=> (time (let [a (make-array Object 1)] (dotimes [i 10000000] > > (aset > > a 0 2)))) > > "Elapsed time: 1323.697565 msecs" > > nil > > user=> (time (let [a (atom 0)] (dotimes [i 10000000] (swap! a inc)))) > > "Elapsed time: 991.807898 msecs" > > nil > > > > Christophe > > > > -- > > Professional: http://cgrand.net/ (fr) > > On Clojure: http://clj-me.blogspot.com/ (en) > > > > > > > > > > > > > > > > > > > > -- > Professional: http://cgrand.net/ (fr) > On Clojure: http://clj-me.blogspot.com/ (en) > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
