Posts by Zalster

21) Message boards : Number crunching : How to use all resources? (Message 408)
Posted 9 Jan 2020 by Zalster
Post:
Now that they added the Max # jobs & Max # CPUs options we need to know what you selected. Before this, or I believe if you select Max # CPUs = No Limit the WUs will select some number of CPUs. You may have a situation where QCP adds up to 24 cores, i.e. 4 CPUs per WU. I prefer to set it to one.


Aurum, where did they add these options at? Is it in the preferences? Been gone for a bit and missed this announcement.

Edit... Nevermind, I see where they added it. Need to see how it affects my machine. Thanks for the heads up.
22) Message boards : Number crunching : Native Multi-Threading (Message 361)
Posted 18 Dec 2019 by Zalster
Post:
Works for me but I predict a single CPU thread is best. I believe these multithreaded WUs can end up with all threads but one done and they wait. With the large variability of QCP WUs this may idle too many CPUs.


So I got the chance to watch these work units with varying values for number of threads. First thing I noticed was with no app_config, that the number of threads used at startup for 1 work unit is all threads. It then rapidly reduces itself down to around 300% (or 3 threads) and slowly draws down to under 1 thread until the last 10 minutes. At that point there is a rapid drop off on the CPU usage, down to around 30% (cause a red flag for amount of CPU as set by the app) then finishing up of the work unit. I'm assuming that the last 10 minutes it's wrapping up whatever it is doing and doesn't really need much CPU at that point.

With an app_config and 4 threads per work unit, I saw that each work unit was holding at 99.6% but again followed the last 10 minute drop as above. With fewer threads per work unit the value was anywhere from 70-96% CPU usage during the majority of time but again dropped off at the end. I finally settled on 2 threads for no other reason than it keeped the number of work units on my CPU to a number I wanted. I saw no change in the time to completion with varying number of threads. Review of all work units showed total percentage of cpu usage was around 96% (I'm assuming this is an average value) for all work units with varying threads.

So the only reason to keep the app_config for me is to limit total number of work units on my machine at any time and to keep any work unit from claiming all threads when it first starts up. Using the number of thread option in the app_config seems to reign in that free for all and keeps the app to a reasonable amount of threads until it can correct itself.
23) Message boards : Number crunching : Native Multi-Threading (Message 360)
Posted 18 Dec 2019 by Zalster
Post:
Thanks Aurum,

I was going to play around with the app_config when I came home from work but you saved me that trouble. Thanks!

I'll give it a try here in a bit.

Z
24) Message boards : Number crunching : Native Multi-Threading (Message 355)
Posted 17 Dec 2019 by Zalster
Post:
Interesting.
See, I am curious so I will probably try it anyway as I have found where to modify it in the script.


Tomas,

Have you noticed that when the work units start, they are 164% CPU and slowly work their way down to a lower value closer to 50% by the end?

I would interested in your mod if you would be willing to share. I find it interesting that the QC from GPUGrid was running 4 CPU threads per work unit whereas here they are just under 1.5. Please let us know if the mod significantly changes the time to complete.

Z


Previous 20

©2024 Benoit DA MOTA - LERIA, University of Angers, France