Question about performance in APP2.5.b2 and future versions  

Archive of all bug reports. This forum is closed - you cannot create new topics or comments here! If you think a specific topic was moved here by mistake, please contact the moderators!
no avatar
Ronald
Member
 
Posts: 177
Joined: Sun Jan 18, 2009 7:16 am

Question about performance in APP2.5.b2 and future versions

by Ronald » Mon Nov 08, 2010 5:14 pm

Hello,

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?

User avatar
AlexandreJ
Kolor Team
 
Posts: 5920
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Mon Nov 08, 2010 5:16 pm

For the moment, I'll say wait for RC before trying to do any real benchmark.

User avatar
JulietaBresn
New member
 
Posts: 1
Joined: Wed Nov 17, 2010 8:07 am
Location: 5487 N Milwaukee Ave, Chicago,

by JulietaBresn » Wed Nov 17, 2010 8:42 am

As you want to move forward in terms of the critical path of the hardware requirements, I think that the CPU capacity should be considered!

no avatar
Ronald
Member
 
Posts: 177
Joined: Sun Jan 18, 2009 7:16 am

by Ronald » Wed Nov 17, 2010 4:27 pm

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?

User avatar
AlexandreJ
Kolor Team
 
Posts: 5920
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Wed Nov 17, 2010 5:28 pm

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.

no avatar
Ronald
Member
 
Posts: 177
Joined: Sun Jan 18, 2009 7:16 am

by Ronald » Wed Nov 17, 2010 7:20 pm

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.

User avatar
AlexandreJ
Kolor Team
 
Posts: 5920
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Thu Nov 18, 2010 9:00 am

For that size, buy RAM. If you can plug 16 GB or even more, it will be an awesome computer ( especially with these HDD )

no avatar
tived
Member
 
Posts: 796
Joined: Fri Jul 11, 2008 3:49 pm
Location: Dane in Western Australia

by tived » Thu Nov 18, 2010 2:14 pm

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

Henrik
Last edited by tived on Thu Nov 18, 2010 2:15 pm, edited 1 time in total.

no avatar
Ronald
Member
 
Posts: 177
Joined: Sun Jan 18, 2009 7:16 am

by Ronald » Thu Nov 18, 2010 2:51 pm

AlexandreJ wrote:For that size, buy RAM. If you can plug 16 GB or even more, it will be an awesome computer ( especially with these HDD )

I will move forward adding 16GB to my current configuration.. Thanks for the advice!

no avatar
tived
Member
 
Posts: 796
Joined: Fri Jul 11, 2008 3:49 pm
Location: Dane in Western Australia

by tived » Fri Nov 19, 2010 2:36 pm

Ronald,

let us know how you go and if it is indeed giving you an improvement in speed

thanks


Henrik

no avatar
Ronald
Member
 
Posts: 177
Joined: Sun Jan 18, 2009 7:16 am

by Ronald » Thu Dec 09, 2010 6:18 am

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.


Return to Archive

Who is online

Users browsing this forum: No registered users and 3 guests