Cliff Click wrote:
> A motivating example is find in the SciMark benchmark suite,
> which copped a rather stock psuedo random number generator for use in a
Monte
> Carlo simulation. The generator is sync'd on reading and writing
> the internal state so multi-threaded programs don't "reset" the generator
> back a few numbers or blow the generator properties by mixing up the
hidden
> state between numbers.
I'm sympathetic to the need to appear to do well on benchmarks but I cringe
at the attempt to automagically fix the above problem. If the RNG is truly
shared then it needs sync, if it isn't then it doesn't. If the MT programs
have to share the same RNG then synchronisation cost is inevitable - in
which case changing the locking strategy is the way to fix performance - if
the RNG doesn't need to be shared then use different RNG's for each thread
and avoid sync altogether.
> Another example, a little less extreme but WAY more common,
> is the current state of the String libraries.
This sounds more like an example of removing redundant or unnecessary sync -
which I am all for, but ...
... I see where you are coming from. The issue here is not what the compiler
may do to well-designed MT code, it is how the compiler might be able to fix
very poorly designed MT code. [And as a colleague of mine so eloquently put
it "statistically there is no well designed code". :-)]
> Let me reverse your question and ask you for an example where
> a compiler might try to fuse locks and accidently blow liveness. We'll
start
> by ruling out all calls in the inbetween area; if the compiler can't
inline
> the call away all bets are off. Also,nix on unbounded loops or loops
where
> we can't determine the trip count is short.
Well if you remove all the interesting cases ... all that's left are the
trivial examples you motivated above. ;-) If the JMM spec guarantees that
the interesting cases (such as the with the r/w lock) can not happen then
I'm probably happy. Though I still have concerns about how these
transformations will be made visible to the programmer for debugging,
profiling and manual optimisations.
David
-------------------------------
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