On my 4 core SMT x2 system (i7 920) I see AMR.exe only using 12-13% of available compute resources. This seems to suggest that it’s pinning a single HW thread at 100% and not providing work for the rest.
This occurs even when I specify ‘Maximum’ priority or manually specify that it should use 8 threads. I’ve tried restarting but this persists.
Looking at Process Explorer, I see about 18 threads with base address “coreclr.dll!GetCLRRuntimeHost+0x44940” of which one is almost always using >12% of system compute with the others doing nothing. There are 14-16ish other threads with different start addresses, 8 of which seem to share the same start address, and manage to steal a couple million cycles every second.
This is on:
Microsoft Windows [Version 10.0.14393]
Core i7 920
24 GiB DDR3
R9 290
Edit:
I’ve played around a bit more, and this seems to only occur if I begin a simulation batch with the client set to background background priority then change the priority to something higher. While I don’t see anything obvious that this isn’t supported, the client behaviour seems to stick to one ‘priority’ at least until the current simulation batch is completed (I didn’t test that long) with the converse (changing the priority of a simulation batch started at ‘max’ to background in the middle of a batch) not causing any appreciable decrease in CPU usage while the batch is still being processed.
The client itself does not modify thread priority, it just uses whatever default behavior the operating system and .net framework wants to use. I am not sure what kind of side effects manually changing the priority of the client program could have – just haven’t had the opportunity to test it.
I don’t really know how the .net framework and the process thread priority interact… would have to google it. Maybe it sets the thread priority using the process default priority when the thread is created, which could explain the behavior that you see. I generally avoid messing with thread priorities because weird stuff can happen unless extreme care is taken, e.g. deadlocks.
If you just run the program at normal priority without changing anything, it should fully utilize your machine. It spawns the number of threads that you specify, and then allows the .net framework and operating system to schedule those as it will, which usually ends up in full CPU utilization. (The .net framework itself will spawn extra threads for garbage collection, usually one per core, that run in parallel with the program as well.)
Instead of messing with process priority, you could try multiple client instances (copy the folder to a second location like “AmrClient2” and start it from a separate location to run two clients on the same machine). You could e.g. set one client to use 4 threads, and when you want stuff to go faster, start a second one that uses 4 threads also. If you are doing gearing strategies (version 2, in beta, won’t work with version 1) or custom batches, the second client will immediately start helping out when you start it.
Whoops, I meant the client’s “performance mode” not the thread priority; sorry. I kept the o/s thread priority at default.
I’ll try again with 289 to see if I can repro.
EDIT: Behaviour described above still seems to occur with v289.
Ah – yeah the performance mode is just a convenience for setting the number of threads.
Background = 1 thread.
Normal = logical processors / 2 (so a hyperthreaded 4-core intel would be 4 threads)
Max = logical processors - 1 (so a hyperthreaded 4-core intel would be 7 threads)
Custom = whatever you say
1 Like
Playing with this some more, If I ctrl-c and restart the client, if it picks up the same simulation its still stuck at 1 thread actually doing work. I have to clear the current sim and start a new one for the thread count to affect how many threads actually do work.
You can’t change the thread count for a simulation already in progress on that client. You have to wait for the current one to finish on that client, then the next one it runs will use your new thread count. Or as you said, you could just cancel it and start it again.
edit – for a custom batch or a version 2 gearing strategy, it should be able to change thread count with each “chunk” that it runs, so it could take up to 5 minutes for the thread change to take effect.
I’ve been meaning to ask what the actual thread counts for each mode are for a while. Thanks!