Please note our new Downloads page here
2023-01-19: APP 2.0.0-beta13 has been released !
!!! Big performance increase due to optimizations in integration !!!
and upgraded development platform to GraalVM 22.3 based on openJDK19
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
I have recently "upgraded" my desktop from a nice self built i5 3.5ghz 4core, 16gb ram, fast nvme ssd to a HP z420 with E5-2670 cpu @2.6ghz on 8 cores+HT, 48GB ram, SATA SSD.
I was hoping that the increase in ram and cpu cores would speed up processing but it doesn't seem to be any faster, if not slower.
I see different things getting taxed more at different phases of a run.
What is the most "needed" thing to run APP as far as PC hardware?
A fast SSD will benefit you the most and increased memory rgarding processing larger data-sets. Mabula is working on getting the GPU to be used more, this will be a feature in a future release and that will speed processing up by a lot. You did select more memory and cores in the settings right? You have to restart APP to make use of the new settings.
I am tagging along here, i have a mosaic registration running in v1.075, (see screenprint) and APP is only using 1 core.
A number of functions run multi-threaded:
Some parts are seemingly single-threaded:
I know, i was responsing to Vincent's remark about using the GPU, it would be nice to use all possible cores first? (This iterative process is taking >24 hrs now for each trial i do on a really fast machine with the 70 panels).
In an ideal world you can just flick a switch and it is all multi-threaded, but it becomes a software development/architecture problem to solve. Mabula's a clever bloke - I'm sure any optimisations that can be coded as multi-threaded are on his backlog.
Utilising GPU libraries will be the icing on the cake, as naturally those have been developed to make extensive use of the amount of dedicated cores the GPUs have to play with. When we see that GPU libs can be taken advantage of, your I/O then becomes your bottleneck - that's when your disks (or even RAM speed) becomes the issue. Remember - you never remove bottlenecks in IT, you just move them elsewhere.
I don't know the specifics for why this is the case, I can imagine it has to do with what AstroCookbook pointed to but Mabula can say more about that. The GPU is most likely "easier" to implement for certain processes.