It would be good if we could understand why the time depends on other processes
on the cpu. We could look up the meaning of that number as supplied to the output
file. I suspect it is supposed to be the total time occupied by that process; if
there is not enough memory on your CPU, perhaps this number is influenced by
differing uses of swap space, which could give very different results if other
processes are running. We should find out how to time this routine ASAP; if the
amount of memory in your CPU significantly affects the results, we may draw
incorrect conclusions.
Once you settle on a good set of parameters, maybe I can try exactly the same
parameters on exactly the same input data on my Linux/Intel box, and see how
consistent the results are. I think I have about 65 Mbytes of RAM. We could also
play games like run cpu-intensive routines and memory-intensive routines at the
same time time, and see if it affects the results. Also Maurik suggested using the
unix 'time' utility, which is easy to do.
As I mentioned in a previous message, it would be good to compare these results
with CELEG 'data'.
- Will
--------------------------------------------------------------------------------
David Rowntree wrote:
> Hello All,
>
> I have tried turning off a few detector elements and looking at the time per
> event. For each test I looked at 100 events from the 2.4gev_p_q0.evt file
> (e-,pi+,pi0,pi-). I started with the default GSIM parameters and AUTO=1.
>
> Default: 7.25s
> All off: 0.11s
>
...what a slow program...
> EC+EC1 off: 7.02s
> CC+SC off: 6.64s
> DC off: 6.68s
> TORU off: 8.31s (checked again)!
> FOIL off: 2.47s
> MINI off: 3.91s
> FOIL+MINI off: 2.63s
>
> There are some weird results here. I am not sure if turning off the
> MINI section turns off the corresponding magnetic field as well. Anyone know?
> Also - the number printed out at the end of a GSIM run changes significantly if
> other processes are using the CPU at the same time. I don't think it is CPU
> time, though I suppose it could be if other resources are the bottleneck.
> Anyway, I try not to tax my computer while making a measurement, but small
> cahnges could happen due to that.
>
> When combined with what I saw before (most of the calls to gtnext are from the
> DC volume), this implies that our biggest time sink is particles showering
> in the shielding foils, which we then track through the rest of the detector.
> I am not certain how the shower libraries are being designed, but if they are
> only for the EC's, it is not clear they will save significant time.
>
> If a particle showers in the FOIL, or in any other volume (even including the
> EC's I think), we no longer need to track the resulting particles with the full
> precision that we use for `pristine' particles. We will already have lost
> significant resolution from the energy collection and the fact that we lose
> momentum in unconverted gammas. I don't know how to make this change, but it
> must be possible....
>
> -David Rowntree