Batch resize takes along time, Low cpu/gpu usage
Hi, I've done a couple of batch resizes but was a bit miffed about the length of time taken to complete those tasks so decided to look at cpu and gpu utilisation.
60 jpeg images 5500x4500, resized to 6600x5500 taking 1 hour. No other effects applied.
Mac activity monitor reports around 12% usage by Resize ai. Why so low? If extra cpu power is applied would task finish sooner?
thanks
-
That is a question you'll have to ask tech support about. The folks you talk to here are other users like yourself. You can use the Submit a request links at the top and bottom of this page to reach them.
0 -
What system are you running on? If an Apple M1 system it has 8 CPU and 7/8 GPUs, on one of these systems 12% load would suggest only one CPU or GPU is being used. So perhaps the batch resizing process is single threaded and only able to use one CPU or GPU.
I have just checked and on my M1 iMac PhotoRAW backup is only using around 12% on otherwise idle system..
You will have to check with support as to if this is the case, and if so why the process is single threaded, and if there are plans to make it multiple-threaded.
0 -
David Tillett and Brian Lawson. I'm using a M1 Macbook pro. Thanks for your input, I'll ask support.
0 -
Did you open the CPU History window in Activity Monitor while the resize was being done? What did it show for how the work load was spread across the CPUs and GPUs?
0 -
I just resized an unedited 3072 x 2048 image by 200% doubling its pixel dimensions. It took a couple of seconds.
If you will share your photo I'll give it a try on my M1 mini and see how long it takes.
0 -
On Windows machines the GPU does all the heavy lifting on the main processing when running resize. GPU usage goes as high as 80% with no increase in CPU usage then at the very end when the processing is done and the file is being written to disk the CPU comes into play and the GPU usage drops. I would imagine that Mac OS would behave the same??
0 -
0 -
0 -
There was an improvement in this batch. Sometimes cpu activity went up to 40%.
Does Ai resize need a good internet connection? I was on vacation yesterday, internet connection was very poor.
Brian Lawson when you did your test, what was your cpu activity?
I've submitted this to support and received a ticket, lets see what they say. Thanks guys.
0 -
No internet connection is needed at all for the AI to work.
It's hard to say because I still had my BOINC screensaver working in the background. I haven't retested yet.
These are the windows that will show you the processor usage over time. They are what you should be viewing. I'm seeing all 8 cores being used but again, BOINC is very GPU intensive and I haven't rerun the test with that turned off yet. I will do so later and post the results.
The 2 spikes in the GPU history are when Resize AI was doing its thing.
0 -
Sorry it took so long to get this done. As I suspected all the CPU/GPU activity shown above is due to the BOINC screen saver and other processes running in the background. BOINC was the distributed processing driver for SETI@Home project and makes heavy usage of any available CPU & GPU cycles available. I have it working on other projects now. For this test I killed everything except Photo RAW, Activity Monitor, & Safari with only this window open.
For those unfamiliar with the ARM processor it has 2 types of CPUs — Performance and Efficiency. E cores run slower conserving battery power in laptops and are normally used for low priority background tasks. P cores run faster and are normally used for high priority tasks. These are not hard & fast rules however, the programmer can specify which core type should be used to override the OS's default behavior based on the thread's priority setting.
I started the Activity Monitor with just Safari and Photo RAW running and I let every thing sit for 10 seconds or so to settle out. This is the times covered by the yellow outline. I switched to PR, entered the Resize AI module, clicked Done and pressed Save as quickly as I could. The Resize activity is outlined with orange. The white outline at the right is during the Save process. Or as near as I can tell. 😉
I just noticed I messed up the right side of the CPU History outlines for the even numbered cores. Sorry 'bout that. They should match the left size in both color and location.
This is telling me that the resizing is distributed though all 8 CPU cores and the GPU. The save part is also distributed but doesn't hit them as hard. The GPU during save is most likely the handling of the Save dialog onscreen.
0 -
More on the graphs, the samples were taken 1/second so you can count the columns to count how long it took for things to happen. On my system resizing was over fast.
Above was for an unprocessed 3072x2048px .CR2 file enlarged 100%.
For an 8192x5464px .CR3 the graph looks like this:
Still very fast, a matter of seconds.
0 -
Brian, Interesting, the MAC OS and infrastructure might handle things differently than Windows and Intel but I'm curious as to why you chose to do this test resizing by 100%? A 100% resize on my machine is almost instantaneous and does not change the image dimensions, it just saves the tif file at the original file dimensions although the tif file size in MB is lager. I think with something happening that quickly and really doing no resize work it is hard to see what is GPU work and what is CPU work. The test I did above was on an unprocessed 6720x4480 CR2 file resized by 400% and took about 50 seconds.
0 -
Because I was tired and not thinking clearly. For some odd reason I thought resizing it 100% was doubling the pixel dimensions. Of course you're right and it isn't. My bad.
I will redo my testing later this evening when I have more time to work on it. I did do a 400% resize of the 8192x5464 image after reading your comment and before starting typing this response. It is still running. In fact the program appears to be hung. I'm seeing lots of spikes on the CPU and very little on the GPU.
Sorry for the confusion folks. I'll be back! 😁
0
Please sign in to leave a comment.
Comments
14 comments