View Full Version : Ryzen 9-5950X AVIsynth+ CPU usage vs. processing fps multithreading weirdness
Stereodude
26th October 2022, 03:39
I'm really trying to wrap my head around this... I see the best total system AVIsynth+ performance of my R9-5950X with the CPU not fully loaded. I tested my script with AVSmeter to find the optimal prefetch value. I found that was 12 threads (Higher prefetch values than 12 give lower fps with higher reported CPU usage). AVSmeter reports 35.6% CPU usage for 13.42fps. Task manager shows the CPU usage is ~12-13% higher than AVSmeter.
So I figure if I'm getting peak script throughput with less than 50% CPU usage I should split the source in half and run both halves in parallel so I get closer to 100% CPU usage and a net gain in total fps (combining the performance of the two halves). Except that's not the case... :confused:
I really want an AVI file from my .avs file so I'm using VD2. Running 12 Prefetch threads and a single instance of VD2 saves a 2000 frame test clip in 2:43. I get about 50% CPU usage per task manager. Running two instances of VD2 each outputting the same 2000 frame test clip (each with a prefetch of 12) saves the 4000 frames in 5:56.5 with total CPU usage of ~95%.
My script is not complicated.
DGSource("HZLIP.dgi").ConvertBits(16)
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
trim(1000,2999)
Prefetch(12)
With the CPU ~50% loaded I can process 2000 frames in 2:43. So 12.27fps. With the CPU ~95% loaded running two in parallel I can process those 2000 frames twice (4000 frames) in 5:56.5. So 11.22fps. I can get 3fps with no multithreading with 5-6% CPU usage. But despite having 16 cores and 32 threads on tap I can only get 4x the performance. :scared:
I get that potentially the CPU will run slower with the higher loading, but I didn't expect this. This does not align with my experience of how Intel systems work.
kedautinh12
26th October 2022, 04:46
Rich oldman TDS, who had r9-5950x too will explain for you :D
Boulder
26th October 2022, 04:55
I'm really trying to wrap my head around this... I see the best total system AVIsynth+ performance of my R9-5950X with the CPU not fully loaded. I tested my script with AVSmeter to find the optimal prefetch value. I found that was 12 threads (Higher prefetch values than 12 give lower fps with higher reported CPU usage). AVSmeter reports 35.6% CPU usage for 13.42fps. Task manager shows the CPU usage is ~12-13% higher than AVSmeter.
You could try setting the amount of prefetched frames manually. I have a 5950X and in my use cases, Prefetch(threads=32, frames=10) has been the most consistent one. Also, raise the max amount of cache.. I have seen Avisynth use up to 20 GB of memory for 4K material, of course depending on the script. If the max cache size is too small, the performance will suffer greatly.
DTL
26th October 2022, 04:58
Massive multicore CPUs for very old PC architecture and very slow RAM are only fast for small chunks of data very long computing from small internal caches. If you try to run task with lots of host RAM read-write traffic it will not be scaled with cores number well.
Also you need to optimize memory IO patterns to be very friendly to current host RAM design (with best hiding of very awful each memory block latency by banks/ranks interleaving) from DRAM modules side and features of currently used CPU RAM controller.
Stereodude
26th October 2022, 05:06
You could try setting the amount of prefetched frames manually. I have a 5950X and in my use cases, Prefetch(threads=32, frames=10) has been the most consistent one. Also, raise the max amount of cache.. I have seen Avisynth use up to 20 GB of memory for 4K material, of course depending on the script. If the max cache size is too small, the performance will suffer greatly.
This is FHD, not "4K". How do I control the amount of cache?
The highest reported RAM usage by AVSmeter in my testing was 8458 MiB with Prefetch(18). I didn't go higher than 18.
Prefetch(32,10) output 2000 frames in 2:37 and used around 43% CPU from VD2.
Boulder
26th October 2022, 06:49
This is FHD, not "4K". How do I control the amount of cache?
The highest reported RAM usage by AVSmeter in my testing was 8458 MiB with Prefetch(18). I didn't go higher than 18.
Prefetch(32,10) output 2000 frames in 2:37 and used around 43% CPU from VD2.
SetMemoryMax(...) at the beginning of the script will set the max amount. I think I have it at 20000 at the moment in an automatically loaded .avsi file. I also set SetCacheMode(1).
The thing is that there is no perfect multithreading ever :p But when you combine the Avisynth processing and for example encoding with x265, the CPU usage is around 85-100% depending on your x265 settings.
spoRv
26th October 2022, 10:21
Have you tried MP_Pipeline?
I have 16core 32threads and 64GB RAM:
MP_Pipeline("""
SetMemoryMax(32768) # =32GB - set accordingly to your RAM
DGSource("HZLIP.dgi").ConvertBits(16)
###
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
###
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
### prefetch: 24, 0
### branch: 24
### ###
""")
using a single script; if you want to split it in two they could be:
MP_Pipeline("""
SetMemoryMax(16384) # same RAM used for single, split in two
DGSource("HZLIP.dgi").ConvertBits(16)
###
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
###
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
### ###
""")
trim(x,y)
or you can split in more pieces, setting RAM accordingly.
With heavy scripts, I used to split up to 8 pieces, with same trim lenghts; speedup is not linear - for example if one piece was 1fps, I had not 1x8=8fps, but something like 5/6fps.
Stereodude
26th October 2022, 13:45
Have you tried MP_Pipeline?
I have 16core 32threads and 64GB RAM:
MP_Pipeline("""
SetMemoryMax(32768) # =32GB - set accordingly to your RAM
DGSource("HZLIP.dgi").ConvertBits(16)
###
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
###
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
### prefetch: 24, 0
### branch: 24
### ###
""")
using a single script; if you want to split it in two they could be:
MP_Pipeline("""
SetMemoryMax(16384) # same RAM used for single, split in two
DGSource("HZLIP.dgi").ConvertBits(16)
###
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
###
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
### ###
""")
trim(x,y)
or you can split in more pieces, setting RAM accordingly.
With heavy scripts, I used to split up to 8 pieces, with same trim lenghts; speedup is not linear - for example if one piece was 1fps, I had not 1x8=8fps, but something like 5/6fps.
I used to use it extensively instead of prefetch, but it doesn't work with the latest AVIsynth+ releases. I didn't realize there were newer MP_Pipeline releases, so I will have to try them.
kedautinh12
26th October 2022, 14:25
Are you using this latest ver??
https://gitlab.com/uvz/AviSynthPlus-Builds
Stereodude
26th October 2022, 14:41
Are you using this latest ver??
https://gitlab.com/uvz/AviSynthPlus-Builds
r3661. I will try the latest.
Edit: Seriously I have to download each file manually? What happened to installers?
poisondeathray
26th October 2022, 15:21
Temps/cooling ok ? Did you rule out throttling as a contributing factor ?
Stereodude
26th October 2022, 15:32
Temps/cooling ok ? Did you rule out throttling as a contributing factor ?
Yes, temps are fine. Under 70C. It seems like going beyond 50% CPU loading somehow slows the overall throughput down, sort of like using the hyperthreading makes it worse (though I'm not sure that's what is happening). I'm not running out of RAM either.
On Intel systems I found performance generally continues to go up until 100% CPU usage (though not necessarily linearly). I don't have a 16C32T Intel CPU for comparison though. Only up to 10C20T.
Edit: I have a script that uses about 26% CPU (task manager) and gives about 11.2fps. Running it twice in parallel increase CPU to ~54% (task manager) and give about 13.7fps combined. Running it 3x in parallel increases CPU to ~80% (task manager) and about 12.96fps combined.
DTL
26th October 2022, 17:08
Edit: I have a script that uses about 26% CPU (task manager) and gives about 11.2fps. Running it twice in parallel increase CPU to ~54% (task manager) and give about 13.7fps combined. Running it 3x in parallel increases CPU to ~80% (task manager) and about 12.96fps combined.
May be it is hardly memory-bound task. The system CPU load graph will show 100% load even when CPU really not any compute useful and simply stall waiting for memory. It shows process CPU time I think. And if thread is waiting for memory it still occupy CPU time from OS view.
It is better to run some profiler tool like intel VTune to look at lots of performance counters (though may not run with AMD CPUs). Or may be current AMD uProf (at least looks at disassembly to see if most of samples collected are around memory read/write operations). Old AMD CodeAnalyst profiler looks like deprecated.
For experiment you can also adjust RAM clock if possible at motherboard setup to see how 100% MT CPU load performance in fps depend on real RAM clock (or may be set lower delays if possible like CAS delay).
Also it is an idea to check Preftetch() with very low prefetch frames number like 1 - may be it will be better fit AMD CPU large cache. Default prefetch frames num is threads*2 so it is 32 for 16 threads - http://avisynth.nl/index.php/SetFilterMTMode . So may be good to test if Prefetch(16,1) runs in better speed in compare with default.
guest
28th October 2022, 03:40
Rich oldman TDS, who had r9-5950x too will explain for you :D
Hmmm,
Had ?, still have !!!
Now have 7950X setup, but still not using in "anger".
guest
28th October 2022, 03:52
I'm really trying to wrap my head around this... I see the best total system AVIsynth+ performance of my R9-5950X with the CPU not fully loaded. I tested my script with AVSmeter to find the optimal prefetch value. I found that was 12 threads (Higher prefetch values than 12 give lower fps with higher reported CPU usage). AVSmeter reports 35.6% CPU usage for 13.42fps. Task manager shows the CPU usage is ~12-13% higher than AVSmeter.
So I figure if I'm getting peak script throughput with less than 50% CPU usage I should split the source in half and run both halves in parallel so I get closer to 100% CPU usage and a net gain in total fps (combining the performance of the two halves). Except that's not the case... :confused:
I really want an AVI file from my .avs file so I'm using VD2. Running 12 Prefetch threads and a single instance of VD2 saves a 2000 frame test clip in 2:43. I get about 50% CPU usage per task manager. Running two instances of VD2 each outputting the same 2000 frame test clip (each with a prefetch of 12) saves the 4000 frames in 5:56.5 with total CPU usage of ~95%.
My script is not complicated.
DGSource("HZLIP.dgi").ConvertBits(16)
MCTD(ncpu=1, settings="low", radius=3, enhance=false, sharp=true, strength=50)
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
trim(1000,2999)
Prefetch(12)
With the CPU ~50% loaded I can process 2000 frames in 2:43. So 12.27fps. With the CPU ~95% loaded running two in parallel I can process those 2000 frames twice (4000 frames) in 5:56.5. So 11.22fps. I can get 3fps with no multithreading with 5-6% CPU usage. But despite having 16 cores and 32 threads on tap I can only get 4x the performance. :scared:
I get that potentially the CPU will run slower with the higher loading, but I didn't expect this. This does not align with my experience of how Intel systems work.
Strange indeed, my 5900X encodes certain files faster than either of my 3950X or 5950X (not sure about the 7950X yet), and there has been some interesting discussion over on the RipBot 264 forum..
https://forum.doom9.org/showthread.php?p=1974373#post1974373
RipBot264 has the ability to change affinity settings in it's encoder which does seem to help, but it's still puzzling how 12 cores can beat 16 cores.
Stereodude
28th October 2022, 05:09
Strange indeed, my 5900X encodes certain files faster than either of my 3950X or 5950X (not sure about the 7950X yet), and there has been some interesting discussion over on the RipBot 264 forum..
https://forum.doom9.org/showthread.php?p=1974373#post1974373
RipBot264 has the ability to change affinity settings in it's encoder which does seem to help, but it's still puzzling how 12 cores can beat 16 cores.
FWIW, affinity settings of x265 don't work.
Like this:
START "Enc #1" /NORMAL /NODE 0 /AFFINITY F0000000 "C:\HDTV Tools\x265_pm\Release_clang_AVX2\x265_x64.exe"
That should set the affinity to F0000000, but it doesn't. x265 doesn't honor that. It will escape that and use all the cores unless you manually modify it in Task Manager. Interesting findings in that thread though. It would be interesting to see what is bottlenecking the CPU in the cases where 12 cores or the 16 core set to only use 12 cores are faster than using all 16.
Boulder
28th October 2022, 06:16
FWIW, affinity settings of x265 don't work.
Like this:
START "Enc #1" /NORMAL /NODE 0 /AFFINITY F0000000 "C:\HDTV Tools\x265_pm\Release_clang_AVX2\x265_x64.exe"
That should set the affinity to F0000000, but it doesn't. x265 doesn't honor that. It will escape that and use all the cores unless you manually modify it in Task Manager. Interesting findings in that thread though. It would be interesting to see what is bottlenecking the CPU in the cases where 12 cores or the 16 core set to only use 12 cores are faster than using all 16.
Like I asked, take a look at the GPU usage when running the script. It could also be a caching issue in which Avisynth requests frames out of order for some reason and causes massive overhead as they are not cached. You could use RequestLinear (in the TIVTC package) and DebugView to see what happens.
guest
28th October 2022, 07:13
FWIW, affinity settings of x265 don't work.
They do in RipBot !!!
takla
28th October 2022, 09:41
Mhh. Using Windows 10 and my Ryzen 9 3900X on a 1080p BluRay, I get this:
23 fps 65% CPU usage (Task Manager)
ffmpeg -y -benchmark -i 03.avs -c:v prores_ks -qscale:v 4 output.mkv
20 fps 80% CPU usage (Task Manager)
ffmpeg -y -benchmark -i 03.avs -c:v libx265 -crf 12 output.mkv
Using the following AviSynth settings:
LWLibavVideoSource("C:\Users\Admin\Documents\Input.mkv")
ConvertBits(16)
EZdenoise(Chroma=true)
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
Prefetch(12, 48)
And thats with encoding, not AVSmeter. Maybe try EZdenoise (https://forum.doom9.org/showthread.php?t=183192) for denoising?
DTL
28th October 2022, 13:41
"ConvertBits(16)
EZdenoise(Chroma=true)"
If source is not 8+ bit per sample it may be visibly faster to feed 8bit to MAnalyse and MDegrain and use 16bit output blended result from MDegrain for debanding later (set out16=true for MDegrain if 8bit source used and 16bit output if required for debanding). Using 16bit MAnalyse may not add anything useful but may be significantly slower and all script will use 2x RAM for super clip and fill CPU cache with possibly useless data. ConvertBits(16) simply fills half of very expensive and fast CPU cache with useless zeroes before start of degraining.
So you can add out16 param to EZdenoise script and about double threads number running with same CPU cache size with better performance if processing 8bit sources and still have 16bit output for debanding post processing.
Also for this thread about MT performance of AVS at different computing platforms it is good to show how your script is scales in performance with increasing threads number (CPU cores used) like 1,2,4,8,12 threads and its fps.
Stereodude
28th October 2022, 14:04
Like I asked, take a look at the GPU usage when running the script. It could also be a caching issue in which Avisynth requests frames out of order for some reason and causes massive overhead as they are not cached. You could use RequestLinear (in the TIVTC package) and DebugView to see what happens.
GPU usage is in the single digits according to Task Manager.
takla
28th October 2022, 14:18
I remember testing 8bit vs 16bit MAnalyse before and it didn't make a significant difference so I left it as is. It was almost identical to out16=true. But I can test it again...
Boulder
28th October 2022, 14:21
It's definitely worth doing the MAnalyse phase in 8 bits and the rest in 16-bit domain. Performance-wise much better that way and the output quality is as good (the analysis phase is never dead accurate anyway).
takla
28th October 2022, 15:40
Yeah. out16=true instead of ConvertBits(16) is about 15% faster for 8bit clips. I've updated EZdenoise. Thanks for the suggestion.
DTL
28th October 2022, 16:31
And how it is scaled in performance with increasing threads number from 1 to number of CPU cores ?
takla
29th October 2022, 09:59
And how it is scaled in performance with increasing threads number from 1 to number of CPU cores ?
CPU Usage, FPS, Threads
6% 3.3 fps 1T
11.5% 6.0 fps 2T
17% 8.6 fps 3T
22.5% 12 fps 4T
28% 14.8 fps 5T
33% 17.7 fps 6T
37.5% 19 fps 7T
43% 20.8 fps 8T
47.5% 23 fps 9T
53.5% 25.8 fps 10T
58% 26 fps 11T
63% 27 fps 12T
63% 28 fps Prefetch(12, 48)
LWLibavVideoSource("C:\Users\Admin\Documents\OPM\OVA01.mkv")
EZdenoise(Chroma=true, out16=true)
neo_f3kdb(range=28, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)
Trim(0, 1440)
Prefetch(12, 48)
ffmpeg -y -benchmark -i 03.avs -c:v prores_ks -qscale:v 4 output.mkv
DTL
29th October 2022, 12:32
At least it shows simple MAnalyse + MDegrain from mvtools scaled good enough with used cores number increased. But MCTD script is much more complex and may be long research required to found what cause so bad scaling of MCTD script.
takla
29th October 2022, 12:42
That is why I recommended it over MCTD. You can tweak it to produces comparable results without the bad scaling.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.