Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance v0.14 vs. pyston #411

Closed
mkuemmel opened this issue Oct 13, 2021 · 6 comments
Closed

Performance v0.14 vs. pyston #411

mkuemmel opened this issue Oct 13, 2021 · 6 comments
Milestone

Comments

@mkuemmel
Copy link
Collaborator

I ran the deep fields from the morphology challenge in different configurations with v0.14 and with pyston. Let's discuss during tomorrow's telecon.

single sersic (levmar, 56c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00  fails with 163849 after 1:28  170887    00:49:58
field_01  171719    01:37:46             171725    00:50:40
field_02  171091    01:38:03             171086    00:50:49
field_03  169864    01:38:04             169878    00:42:03   
field_04  fails with 146954 after 1:16   170891    00:50:58

disk+bulge (levmar, 56c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00  137361   01:57:12             137367    01:25:01
field_01  137868   01:57:22             segfaults after 01:01:43 100554
field_02  137886   01:57:40             137881    01:41:10
field_03  136500   02:05:24             136485    01:28:30
field_04  137150   03:48:50             137150    02:59:09

disk+bulge (levmar, 28c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00           01:46:09                       01:46:54
field_01           01:48:50             segfaults  after 01:15:27
field_02           01:47:35                       01:50:43
field_03           01:52:53                       01:49:57
field_04           03:08:08                       03:36:29

disk+bulge (levmar, 14c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00           03:11:56                       03:27:53
field_01           03:15:37             segfaults after 02:30:08
field_02           03:15:56                       03:30:04
field_03           03:15:53                       03:27:34
field_04           05:09:34                       05:16:32

disk+sersic (levmar, 56c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00 180898     03:03:38            180898    02:42:13
field_01 fails with 181037 after 2:15   181034    04:48:04
field_02 180925     03:40:35            180922    03:13:29
field_03 179515     03:29:19            179518    02:43:56    
field_04 fails with 180659 after 2:29   segfault after 2:19 180656    

real morphology (levmar, 56c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00  106712    01:01:43            106708    00:31:34
field_01  107819    01:03:40            107818    00:32:46
field_02  107023    01:01:10            107024    00:32:04
field_03  105682    01:00:34            105684    00:31:44
field_04  106811    01:02:03            106812    00:31:55

disk+bulge (gsl, 56c)

0.14      nobjects  time         pyston   nobjects  time
--------------------------------------------------------------------------
field_00 137361     03:36:42            137367    02:50:33
field_01 137868     24:05:07            137862    21:23:32
field_02 137886     04:08:21            137881    03:02:58
field_03 136500     04:12:04            136485    03:14:22
field_04 137150     12:24:19            137150    11:21:13
@mkuemmel
Copy link
Collaborator Author

Her the scaleability of SourceXtractor++ with pyston computed for the disk+bulge model from above:
SEPP_scaling
There is a broad shoulder from ~15-28 cores with a very god scaling. The processing node has 28 physical cores, using more than those (--> hyperthreading) affects the efficiency.

@mkuemmel
Copy link
Collaborator Author

Here the results of a more extensive investigation using more data, two different models (sersic and disk+bulge) and two different SE++ versions:
performance

@marcschefer
Copy link
Member

I guess tests are still underway?

@marcschefer marcschefer added this to the 0.16 milestone Dec 6, 2021
@mkuemmel
Copy link
Collaborator Author

mkuemmel commented Dec 6, 2021

Yes, I ran over the weekend with the newest version, which includes also the iterative fitting (and of course pyston).

@mkuemmel
Copy link
Collaborator Author

mkuemmel commented Dec 16, 2021

Here a comparison of the SE++ performance version 0.14 vs. 0.16 (December'21) with pyston and meta iterations:
pyston_iter_perform

Looks like the iterative fitting does cost some performance. On the other hand the example data is not very clumpy and not many priors are being used. 0.14 had still some bugs and the fitting of large groups (>2GB RAM) is not possible or shaky.

The performance values reported here are now showstoppers for the next release.

@mkuemmel
Copy link
Collaborator Author

mkuemmel commented Jun 1, 2022

Well, this can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants