Pixinsight Performance and Swap Files Pleiades Astrophoto PixInsight · Jim Raskett · ... · 15 · 1530 · 6

Thanks for sharing your experience. I will try 8 just to see.

Jason:
I've been playing around with a system I have just built my conclusion is that through a combination of changing the threads for read & write and some ram disks for swap seems to be the best I can get at the moment.  The new system is 11x faster in the bench mark going from 3000 to about 35,000 total so I am more than happy but of course there's always that little bit of interest in whats the max I can get it to!

So from my experiments using combinations of number of swap directories and locations.
My optimum is 4 swap directories with 25 read and 25 write max threads. This gives me an average total of 36,340 over 3 benchmark runs.


Problem is if I repeat this later on it might give a lower 32000 for some reason. 

4 seperate directories on a M2 drive is close but still less performance, spread over multiple M2 drives seems to be the killer soluton though (not my system here)  https://pixinsight.com/benchmark/benchmark-report.php?sn=H21148386W4QCLU7KCNI4D1IF78TZ09V

Adding or subtracting swap directories or increasing disk size has small to medium detrimental impact on the total score for me.

Here's one of my benchmarks with 8G swap drives (ave score over 3 tests was 35,410), I can't find the 4G one I ran at the moment.  
https://pixinsight.com/benchmark/benchmark-report.php?sn=B7JW915K202BIG8Q41YH0OTJ6CHV0S07

I am tempted to put on a dual boot Linux and see what that brings, I understand it is quite a performance improvement.

Jason

Warren A. Keller:
Swap files primarily help with maintaining the histories of open views or projects, using the SWAP directory rather than RAM. Once PI is closed, Swap files may be deleted; unfortunately, PI doesn't do this automatically. Periodically check your Swap folder, it may be huge! A NVMe or SSD should be used. It's recommended to use a single directory/location, naming it multiple times based on the performance of the Benchmark script. Having worked on a few people's systems including my own, this seems to be a great place to start: double the physical cores and add another dozen (IOW, my I9 has 8 physical cores, so 28 total). YMMV; give it a try and good luck!

Alan Brunelle:

Warren A. Keller:
Swap files primarily help with maintaining the histories of open views or projects, using the SWAP directory rather than RAM. Once PI is closed, Swap files may be deleted; unfortunately, PI doesn't do this automatically. Periodically check your Swap folder, it may be huge! A NVMe or SSD should be used. It's recommended to use a single directory/location, naming it multiple times based on the performance of the Benchmark script. Having worked on a few people's systems including my own, this seems to be a great place to start: double the physical cores and add another dozen (IOW, my I9 has 8 physical cores, so 28 total). YMMV; give it a try and good luck!

In my experience, I second Warren's comments.  I tried the RAM drives to see what I could achieve.  Same result.  I don't consider a 20-30% increase in score that meaningful.  Computer nerds and gamers seem to be willing to pay big extra $$$ to get that kind of increase, but for processing images, at least not I.  The scores are great when we tune our machines, as you are finding out.  I actually find the times to completion for CPU and Swap to be a more intuitive read on performance.  And when you see the difference of 18 sec vs. 22 sec, you can judge just how important that difference is.  Otherwise its kind of like gear heads standing around bragging about how their upgraded valves have improved their top speed and they don't live anywhere near a road where they can step on the accelerator! 

I returned to using only my NVMe drives for PI.  Reason being is that after a while, I noticed a bit more instability in my system when running PI with the RAM drives.  I also use 64GB of RAM, and the issue may be that cutting into the 64 may not leave enough for PI.  The comments on the PI page suggests that 32 is basically a minimum, and I was not aware of that at the time.

Alan Brunelle:

Warren A. Keller:
Swap files primarily help with maintaining the histories of open views or projects, using the SWAP directory rather than RAM. Once PI is closed, Swap files may be deleted; unfortunately, PI doesn't do this automatically. Periodically check your Swap folder, it may be huge! A NVMe or SSD should be used. It's recommended to use a single directory/location, naming it multiple times based on the performance of the Benchmark script. Having worked on a few people's systems including my own, this seems to be a great place to start: double the physical cores and add another dozen (IOW, my I9 has 8 physical cores, so 28 total). YMMV; give it a try and good luck!

In my experience, I second Warren's comments.  I tried the RAM drives to see what I could achieve.  Same result.  I don't consider a 20-30% increase in score that meaningful.  Computer nerds and gamers seem to be willing to pay big extra $$$ to get that kind of increase, but for processing images, at least not I.  The scores are great when we tune our machines, as you are finding out.  I actually find the times to completion for CPU and Swap to be a more intuitive read on performance.  And when you see the difference of 18 sec vs. 22 sec, you can judge just how important that difference is.  Otherwise its kind of like gear heads standing around bragging about how their upgraded valves have improved their top speed and they don't live anywhere near a road where they can step on the accelerator! 

I returned to using only my NVMe drives for PI.  Reason being is that after a while, I noticed a bit more instability in my system when running PI with the RAM drives.  I also use 64GB of RAM, and the issue may be that cutting into the 64 may not leave enough for PI.  The comments on the PI page suggests that 32 is basically a minimum, and I was not aware of that at the time.

the benchmark isn't super accurate in the first place - if you read the code you'll see that each process that runs reports it's wall clock time. the script then computes the wall clock time from the start of the script to the end of the script, adds up all the process wall times, and subtracts that from the script runtime. it then attributes that number to disk. but in reality that number contains OS overheads and other delays that have nothing to do with the disk.

the big drawback of using a RAMdisk for swap space is that usually you can't allocate more than some double-digit number of GB. since PI stores the processing history of all open views in swap, you can pretty easily fill up the ramdisk, especially if you are using a big CMOS sensor.  PI usually doesn't recover very gracefully from a full swap folder. and i agree, the performance delta between that and a modern, fast SSD is not really enough to justify the risk/small swap space a RAMdisk gives you.

in the end what matters is real performance. tuning your system to the nth degree based on the benchmark is not really going to yield real world results. i think it's useful for figuring out how many cpu/io threads to use and how many swap directories to use, but stressing out about tiny improvements is not necessary.

I completely agree that tuning to the nth degree is a waste of time.  The nice thing is that you can see your results compared to other similar machines, and get an idea pretty easily if you are working close to the best of those.  If true, be done with it and go process.  One thing that I have wondered is that there seems to be a rough correlation to CPU times to the Swap performance times.  And the ratio of those numbers seems to be similar for the listed machines that are working at their best.  Its seems to "roughly" hold regardless of the raw CPU number.  That may be one way to tell you if you are there, without having to compare your results with the rest of the world.

my guess is that SSDs are so fast that the amount of CPU time spent on the I/O transaction starts to become relevant vs. rotational disks which take forever and a day to complete compared to the CPU time spent.

on the other hand almost all such IO is done using DMA nowadays, but there might sometimes still be a data copy from kernel memory space to user memory space. though zero-copy DMA is also a thing. hard to know for sure without instrumenting everything and doing a real performance analysis. people report much higher IO speeds on linux (vs. windows), even when running PI under WSL. maybe this putative CPU bottleneck can be explained by that if somehow linux spends much less CPU time on IO operations (and the benchmarks you have noted are on windows.) all just a guess, though.