expmap slow on Docker?

[JosephHall]

Hello,

I am trying to run expmap for a small (500 x 500 pixel, 2000 x 2000 arcsecond) image created with evtool from the eFEDS files with a specific region. While expmap does work when I run it, it takes much longer to run than I'd expect for such a small field (~3300 seconds). I wanted to check if this is expected with Docker, or if there are any options to speed up the expmap processing time.

The command I am passing is:

Code: Select all

expmap inputdatasets=evtool_output_img.fits emin=0.5 emax=2.0 templateimage=evtool_output_img.fits mergedmaps=expmap_output.fits gtitype=FLAREGTI

For what it is worth, I am running the Docker on a 2023 MacBook Pro with an M2 Apple Silicon chip -- could this also be affecting performance?

Any help would be greatly appreciated, thank you!
Joseph.

[AlainGueguen]

Dear Joseph,
Indeed, running the Docker image , created on a X86_64 CPU, on a ARM64 ( Mx silicon chips ) machine affect seriously the performances.
unfortunately Expmap in eSASS EDR is not multi threaded, and i am not aware of any option to increase its the performances.

just one question : are your running expmap from your mounted data folder, are so are you writing the results (mergedmaps=expmap_output.fits ) to the external folder ?
would it be faster if you were writing the result in the docker home folder and only after copying to your external folder ?

Regards
Alain on behalf of the eSASS team

[JosephHall]

Hi Alain,

Thank you for your reply. I had thought that the difference in processor architecture could be affecting it.

Until now, I had been running it in a mounted drive, yes. I have just tested in the docker home folder and it seems to have taken just as long to run as it was when running from the mounted folder. The slow down seems to be when iterating over GTIs with expmap and not with the read/write operations, regardless of which folder I use for the expmap output, it seems to take ~8.5 seconds to do the first 30 iterations.

I will switch to working on an X86_64 machine soon.

Thank you again for your help,
Joseph.