I’ve just setup a Windows 10 guest in Proxmox with no special command-line options. Just 16 cores, 8GB mem, and using the “host” CPU model.
I ran Cinebench r23 and got 27188 multi, and 1904 single.
Looking on the host I can see it’s definitely only using 16 cores (and not somehow sharing the 16-core guest load across all 32 cores). They are all boosting between 4900 and 5000 MHz. Temp is max of 77C.
Looking at results online I saw figures like these in reviews:
7800x3D: 18559 / 1796
7950x3D: 36439 / 2049
The single core on mine is ~6% slower than the baremetal value for the 7950X3d (which is fine as I’ve not tried any tuning yet).
But how is my mutlicore result 75% of the baremetal, with only 50% of the cores?
What’s even more surprising (to me) is I get 50% higher results than 5800x3d baremetal, with the same number of cores (and without tuning/core pinning)
Have I missed something here? Sure it’s nice to get better than expected, but concerned actually my testing is flawed.
The 7950x(3d) has 16 cores. 32 logical processors show up due to SMT. SMT allows one core to run two threads, sometimes increasing performance (depending on what the threads are doing exactly). So it is expected to get about 75% of performance (probably about 80% on bare metal) since all threads can use the whole core.
Same thing – that one has 8 cores and can run 16 threads. Running 16 threads on 8 cores will cause some contention so you won’t get twice the performance. Your VM’s cinebench is running 16 threads on 16 cores, so more resources per core, which is faster.
So it’s fully expected to get higher performance running 16 threads on a 7950x3d than a 7800x3d/5800x3d.
The singe core numbers is similar to what i can find on Anandtech.
But yeah there are mixing results from several sources.
But your multicore score seems to be lacking behind.
Did you install the additional AMD driver for the Windows schedular?
And what are your memory speeds?
He set up a VM with 16 cores, so he’s getting approximately the result of a 7950x3d with SMT disabled. That is because without any pinning the linux scheduler will schedule the 16 threads to 16 physical cores.
Exactly as expected 0-15 are thread 0 of cores 0-15 and 16-31 are thread 1 of cores 16-31. So now you’re assigning the both threads of the first 8 physical cores (ccd0 with v-cache) to the VM.
0-15 are thread 0 of cores 0-15 and 16-31 are thread 1 of cores 16-31. So now you’re assigning the both threads of the first 8 physical cores (ccd0 with v-cache) to the VM.