On Fri, 25 Apr 2008, Malcolm J. Currie wrote:
>> While all this is true in general and it would be nice to sort out, is it
>> a specific problem?
>
> Hence my question referring to JAC support. Given the cutbacks we have
> to be even more selective. If the astronomers reach a point where
> they reject the software because it can't use the avalable 8 or 16 cores
> simultaneously.
>
> Tim is beating the drum. I can only presume Tim sees something on the
> JAC radar. I'm the Fortran recidivist wondering if there were any tools
> that could accelerate the job of F77->C. Given the uniformity of our
> core code, Tim might knock some perl together...
I can't speak for Tim (he's attending JCMT 21st Anniversary talks at the
moment) but I do know that he's under the impression that multi-threaded
code would help immensely for SCUBA-2 reduction.
We've also discussed it for general ORAC-DR reductions. Because of the
single-threaded nature of Starlink code, we would have to start up N
instances of each monolith (where N is probably (cores + 1) or something
like that). This sort of thing would help speed up e.g. CGS4 reduction,
where you have multiple subframes in each observation, each of which have
the same reduction step done. Doing six dark-subtractions simultaneously
would (hopefully!) be quicker than doing them consecutively, which is what
the pipeline does now.
We haven't done this because a) we don't really need it for UKIRT's
ORAC-DR, b) the memory use would probably scale with the number of
monoliths we would start up, and c) we don't have the effort required on
this end.
Multi-threading ORAC-DR would probably not work for SCUBA-2, though.
Cheers,
Brad.
|