18-10-2022, 07:24 AM
(This post was last modified: 18-10-2022, 07:29 AM by josemendez.)
Hi!
Short answer: profile.
Long answer: the profiler will tell you *exactly* why your app is slower on one of the CPUs, in far more detail that I or anyone else can. Whenever you have any kind of performance issues, profiling is always the answer.
There's a couple things I can think of that will make a Burst-based physics simulation slower on the i9. First is that while it has more threads, it has lower clock speed. So unless your simulation has room to exploit parallelism, having more slower threads will naturally slow things down (because there's not enough parallel work to keep more threads busy, and the busy ones are slower).
Another would be death spiraling. Even if the i9 is only slightly slower than the Ryzen, this can trigger the need to call FixedUpdate() more often, which means your simulation is updated more than once per frame. If the profiler shows more than 1 FixedUpdate() call per frame then this is most likely the cause. Increasing your fixed timestep and/or reducing your max allowed timestep will improve things (both settings can be found in Unity's Time preferences).
3DMark is primarily a graphics/GPU benchmark, won't tell you much about your CPU which is where physics simulation is performed. Some of the newest benchmarks do include a CPU specific test, but you need to focus on that. Also, depending on the time stepping scheme their demos use, there can be a big difference in performance with Unity games (Unity uses fixed-timestepping, which can at times be more costly than say a semi-fixed or variable time stepping scheme).
let me know if I can be of further help,
kind regards,
Short answer: profile.
Long answer: the profiler will tell you *exactly* why your app is slower on one of the CPUs, in far more detail that I or anyone else can. Whenever you have any kind of performance issues, profiling is always the answer.
There's a couple things I can think of that will make a Burst-based physics simulation slower on the i9. First is that while it has more threads, it has lower clock speed. So unless your simulation has room to exploit parallelism, having more slower threads will naturally slow things down (because there's not enough parallel work to keep more threads busy, and the busy ones are slower).
Another would be death spiraling. Even if the i9 is only slightly slower than the Ryzen, this can trigger the need to call FixedUpdate() more often, which means your simulation is updated more than once per frame. If the profiler shows more than 1 FixedUpdate() call per frame then this is most likely the cause. Increasing your fixed timestep and/or reducing your max allowed timestep will improve things (both settings can be found in Unity's Time preferences).
Quote:We tried benchmarking the new machine with 3D Mark and it seems to work as expected.
3DMark is primarily a graphics/GPU benchmark, won't tell you much about your CPU which is where physics simulation is performed. Some of the newest benchmarks do include a CPU specific test, but you need to focus on that. Also, depending on the time stepping scheme their demos use, there can be a big difference in performance with Unity games (Unity uses fixed-timestepping, which can at times be more costly than say a semi-fixed or variable time stepping scheme).
let me know if I can be of further help,
kind regards,