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

using multiple cores for calculationg startrails / keogram #628

Closed
sebmueller opened this issue Oct 10, 2021 · 4 comments · Fixed by #649
Closed

using multiple cores for calculationg startrails / keogram #628

sebmueller opened this issue Oct 10, 2021 · 4 comments · Fixed by #649
Assignees

Comments

@sebmueller
Copy link

hi,

i played around with the allsky software and had to run the startrail app often, to find a good brightness level.

there I found, that it was very slow. in htop I saw, only 1 core of my raspberry was used, 3 cores had nothing to do.

after investigating the code, I got the idea to run the mathematical part of startrails in more than 1 thread.

so I extended the code to 4 threads, controled by a new command line flag (-m).

see the screenshot of htop, using all the raspberry calculating power. the calculation of the startrails is almost 4 times faster than the single core code.

image

please see here the modified file. it is not optimal, but fast an good for raspberry 3 / 4.

I also added a dimension check of the images, because i use image cropping and sometimes, the images are in original size, not cropped.

startrails.zip

@ckuethe ckuethe self-assigned this Oct 11, 2021
@ckuethe
Copy link
Collaborator

ckuethe commented Oct 11, 2021

Good idea. I'm not going to merge your patched version; there's a lot of duplicated code and doesn't have the quite the scheduling control I'd like to have. But it's a good start that I can build on... Thanks for the suggestion.

@sebmueller
Copy link
Author

hi chris,
i saw, the code was not cleaned. I'm sorry. But I'm happy that you like the idea.

:)

@ckuethe
Copy link
Collaborator

ckuethe commented Oct 12, 2021

No worries - you contributed some actual code and that's extremely helpful. This is also relevant to my interests, since I reprocess on my workstation with lots of cores and memory.

@ckuethe
Copy link
Collaborator

ckuethe commented Oct 14, 2021

Re the dimension check, there was already a check with the -s <width>x<height> flag that you can use to restrict processing. startrails -s 123x456 ... would only operate on images that are 123 pixels wide and 456 pixels high, for example. Let me know if that doesn't do what you need it to.

I'll do keogram in a separate diff.

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

Successfully merging a pull request may close this issue.

3 participants