I noticed an slight performance downsize in APP2.5.b2 in comparison to previous versions. As Alexandre stated in another post the change is related to the improvements in the new color correction system; and, I also noticed an additional memory utilization.
My question comes because I would like to move forward in terms of the critical path of the hardware requirements. At this point what aspect is more important to consider, the RAM memory or CPU capacity?
You're right, and the main reason of my question is the fact that I want to upgrade my computer and not sure at this time what piece of hardware is more relevant to upgrade. i.e. RAM from 8GB to 16GB or CPU from 4 cores to 8 cores...
The APP use a lot of memory, and, during some process a lot of CPU.... which one is more critical to improve performance?
It depends on the type of panorama you are doing : - small panorama ( up to 500 Megapixels ). The best here is to get RAM. Because when everything runs in memory it is really faster. - big panorama : you won't be able to run in memory, so the speed of the harddrive will matter In any case, a better CPU will speed up the rendering but not as much as in memory versus out of memory case.
I'm using APP to generate panoramas between 25 and 400 images(Tiff 16), using Spline64 and psd/psb 16bits by default. The files generate may vary between 1GB and 10GB (few days ago a 37GB psb file was generated, but I think that was due an error)
I have 6 WD 500GB in RAID-0, and in my opinion the performance in this area is ok, that's why I'm looking in a recommendation between CPU and RAM... This computer is dedicated only to work APP.
I think this whole process here, is really taxing the all your resources.
My own current build plan if I can get this funded
will be a Dual Hex Xeon aiming for 4Ghz (2.66Ghz stock) EVGA SR-2 main board 24-48GB of ram Using either 4 or 8 GB sticks, for future expansion Boot disk OCZ Revo 120GB or bigger (haven't decided on which model this or the x2) Scratch disk: as above Storage: 6x WD Blk Caviar 1TB RAID-0 onboard INtel controller (which later will be replaced with Areca or LSI 8channel and expanded) Graphics: 2x 1.5-2GB cards probably nVidia Case: Lian Li 2120 Antec 1200w
Backup: Multiple disks JBOD
I am hoping that this will improve the speed of the whole process, I will most likely, off-load the rendering to my two other machines to keep this one free to assemble the panos, and do other photo-related work.
If I use Folding as a measure of performance then the above should be able to turn over 80.000 to 100.000 points per day, I think my two current once will do 4-8000 between them and they are both Quad core with 8GB of ram.
Expecting the above to last for 5 years with some modifications
Last edited by tived on Thu Nov 18, 2010 2:15 pm, edited 1 time in total.
I did run some tests using 16GB RAM to compare the performance against 8GB configuration and these are the results, so far (after several hours testing): - Scope: One of the more complex processes in APP (based in my experience with the application) is the panorama generation; so, I decided to make a automatic panorama detection (using Browse folder) of one photo collection (about 12k CR2 images). I did never complete this process using 8GB RAM. - About 300 groups having between 2 and 750 images were used during the test. - The highest HDD utilization detected during the panorama generation was 210MB/sec Disk I/O. - Maximum RAM utilization detected was about 12.5GB - avg utilization: 8.5GB - CPU utilization was around 80% and 100% utilization. - APP Temp folder utilization: 35K files generated, 36 folders, 707GB space. - In some point during the panorama detection/generation, I was doing some easy adjustments (cropping area, applying LDR) and 77 Panoramas were saved, remaining open all the time. - I was trying to close two panoramas very quick, and the application crash; not sure if that was the reason of the crash; I just know that situation happened processing the last two groups. - All the temp files were deleted and the computer shutdown. - Next step was open all the 77 panos at once; action performed without problems (in about 3 hours, and 200GB of temp space); FYI: I noticed some prioritization in the CPU resource assignment, because, I tried to edit a panorama, when APP was still opening panorama files. - With all 77 panoramas opened and 3GB RAM utilization, the application crash modifying the first panorama.
Maybe this type of test is beyond of the original APP concepts, but, (in my opinion) is good to know how a system would work in the limits; and APP seems to do it really good.
I'm planning to repeat this test using RC.
Last edited by Ronald on Thu Dec 09, 2010 6:38 pm, edited 1 time in total.