Re: [dacapobench-researchers] feature request: worker thread option for xalan

[Steve B. <Ste...@an...>]

On 28/02/2007, at 7:12 PM, Naveen Neelakantam wrote:
> Yes.  The problem is that the work executed by each thread varies  
> from run to run.

Sure :-)  So your concern is not that the workload varies (it  
doesn't ;-), but that the distribution of the workload across the  
threads varies.

In a single processor setting, this is just a function of your JVM's  
scheduler, not the benchmark per se.

Of course this may in turn depend on the OS scheduler, which is going  
to be harder to control.  I guess my point is though, that since it  
is perfectly reasonable Java code, and the "non-determinism" such as  
it is, is not an function of the benchmark but of the underlying JVM  
or OS, then it is something you probably need to work out how to deal  
with methodologically.

> It would be better if each thread executed a fixed set of  
> stylesheet transformations rather than having all workers compete  
> over a single global work-queue.

Perhaps "better" in the face of your particular problem.  :-)

I'd like our suite to accommodate the widest range of usage scenarios  
we can manage, so we'll see what we can do.  However, it is critical  
to us that our benchmarks be "representative" of real applications,  
and the work queue idiom reflects a popular approach to writing a  
certain class of multi-threaded benchmarks.  Among other things, it  
provides a measure of load balancing.

> Thus for our purposes, being able to select the number of worker  
> threads would be ideal.

As Robin and I have both said, you can hardwire a particular value  
via a trivial modification to the benchmark source.  You could make  
it adaptive (see below) pretty easily, but either way you'd be  
changing the nature of the benchmark, so you should note the change  
when reporting results.

> But, since both yourself and Steve brought it up, how do you plan  
> to check for the number of available CPU's?  So long as I can setup  
> my simulation environment to control the number of threads used,  
> that could also satisfy my purposes.

java.lang.Runtime.availableProcessors()

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ 
Runtime.html#availableProcessors()

--Steve