| 26 | | After processing the SAS stacks and static sky with the 1-D Gaussian convolution, we can compare the timing for these stages between the two PSF matching codes using the dtime values listed in the database. For all subsequent plots, the x-axis shows the default time with the pmSubtraction kernels (SAS.20130620), and the y-axis shows the ratio of simple/default (SAS.20130703/SAS.20130620). The different "power" splits in the plots attempt to separate the values based on the host that the calculations were performed upon. This split was done under the assumption that ippcXX hosts are more powerful than ipp0YY hosts. No further divisions into generation of host was done, but this does illustrate that when the new code is run on ipp0YY hosts, it averages about the same as the old code run on ippcXX hosts. In any other case, the new code appears to run ~20% faster than the old code. |
| | 26 | After processing the SAS stacks and static sky with the 1-D Gaussian convolution, we can compare the timing for these stages between the two PSF matching codes using the dtime values listed in the database. For all subsequent plots, the x-axis shows the default time with the pmSubtraction kernels (SAS.20130620), and the y-axis shows the ratio of simple/default (SAS.20130703/SAS.20130620). The different "power" splits in the plots attempt to separate the values based on the host that the calculations were performed upon. This split was done under the assumption that ippcXX hosts are more powerful than ipp0YY hosts. No further divisions into generation of host was done, but this does illustrate that when the new code is run on ipp0YY hosts, it averages about the same as the old code run on ippcXX hosts. In any other case, the new code appears to run ~20% faster than the old code. Less improvement is seen in the static sky runs, but as convolution and PSF matching is a smaller fraction of the total execution time (which is dominated by photometry), this is understandable. |
