> i remember reading multiple sources which said that on Sparc
> there is no need for _two_ memory barriers for DCL - so that the
> only MB needed is the one after singleton creation
Right. my results do not indicate impact of read-barriers that would
be needed, for example, on alphas. I don't have access to alpha (or
powerpc or other) MPs, so can't check this. Maybe others can. Alan
MacKinnon did kindly sent results though for a 2-CPU intel x86 box
under hotspot 1.3. Here they are, along with my previous ones, and
also a run on a sparc uniprocessor. I normalized these by dividing
each time by "Eager" case:
2-CPU 4-CPU 1-CPU
x86 sparc sparc
Eager: 1.00 1.00 1.00
Volatile: 1.31 1.06 1.18
ThreadSpecific: 6.50 4.84 5.01
Synch: 32.12 88.40 9.64
Intels are like sparcs wrt not needing read barriers. But the
"volatile" results here for x86 might be faster than they ought to be
since 1.3 hotspot only partially conformed to "old" volatile rules.
As you'd expect, the synch case gets much worse as you add CPUs. But,
it is not hard to make Synch times vary by a factor of two or more
here just by tweaking thread settings and the like. And, given how
unrealistic and extreme this test is, it is probably not a useful
indication of overall savings in any practical application. Again,
the special-static-class-with-final-static-field idiom described on
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
is normally the best solution for Singletons anyway in Java. It is
equivalent in performance to the "Eager" case here.
> what are the proposed revised "volatile" semantics
See the descriptions linked off
http://www.cs.umd.edu/~pugh/java/memoryModel/
Note especially that in Java, "volatile" not only ensures the right
barriers, it also suppresses some other optimizations and reorderings
that could break sequential consistency, even on uniprocessors. As
mentioned in one of the postings you forwarded, the lack of memory
models for C/C++ makes it hard/impossible to guarantee that POSIX
versions of your code will work.
> thanks a lot for creating the java version and for performance
> data!! may be you can post it to comp.programming.threads?
> (there is a running thread "DCL -- is there a FAQ?")
Well, I'm not so sure I want to get embroiled in this discussion,
but feel free to include my code or comments.
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-312-2688 FAX:315-312-5424 http://gee.cs.oswego.edu/ ------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT