May 27 2026 APP 2.0.0-beta45 has been released !
Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.
Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
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.
@vincent-mod
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.
