Hi,
I’ve noticed two performance anomalies with SIRIL:
- On my 24-core/32-thread Intel i-9 14th gen 16-Gig RAM, 4TB NVME SSD, Windows 11 system, even if I set SIRIL to only use a much smaller number of threads, say 12 threads, it’ll still use 50-100% of the CPU. If I cut it all the way down to 4 threads, it’ll finally drop back to 30-40% of the CPU. (No other software is running other than Windows, no virus programs, etc… and this is very repeatable. When SIRIL stops, CPU drops to <5%.
Is there a reason why it doesn’t seem to be very proportional to how many CPUs and Threads I have. I would expect if I cut it to 12, I would see <50% of the CPU being utilized.
- When I stack with SIRIL, generally I can get OK performance running other tasks (ex: Browsing or doing a bit of editing in Affinity). However, I shoot short exposures and often stack my subs into 10-minute sub-stacks and then stack these. So these substacks are already debayered, calibrated and are 32-bit/pixel RICE FITS compressed stacks. if I stack a group of about 172 of these compressed 32-bit/pixel sub-stacks with SIRIL, even with only 12 threads, my system becomes pretty unresponsive. I can’t even type into Explorer, I get 1 character every 2 seconds.
I haven’t fully explored this, but It seems there is something about this data type: 32-bit/pixel RICE FITS files that really impacts SIRIL. I did note that 100% of the CPU is used and of my 16-GIgs of RAM, it’s all used by SIRIL and the commit charges go up to 28 Gigs (not sure if that’s important). Just a note.