Originally posted by debianxfce
View Post
Announcement
Collapse
No announcement yet.
Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload
Collapse
X
-
-
Originally posted by atomsymbol View Post
In my opinion, with year 2019 common CPU thread counts (8-16) and assuming 2 GiB of memory per thread in parallel tasks using all CPU threads, 16-32 GiB of memory is slowly becoming the norm for a desktop/workstation. 8-16 GiB is on the border of being a limiting factor to full utilization of the CPU.
Taking a look at https://www.ec2instances.info most of the EC2 instances have at least 2 GiB of memory per vCPU. The Nano instances have less memory per vCPU (minimum being 256 MiB per vCPU) which is enough to run certain types of applications, but this does not negate the fact that the optimum for a year 2019 desktop/workstation is at least 2 GiB of memory per CPU thread.
Keep my large numbers in mind if you compile your own software or plan on doing it. We need assloads of ram for some of these compiler and optimization processes.
Leave a comment:
-
Originally posted by debianxfce View Post4-8GB RAM is enough to disable swapping.
My work laptop is maxed out at 16GB (Thinkpad t440p) and even with zswap enabled, I often go a few GB into swap when I have to test certain workflows.
I'm looking forward to my next laptop refresh (this fall), so I can finally jump to 32GB RAM.
- 1 like
Leave a comment:
-
Originally posted by debianxfce View Post4-8GB RAM is enough to disable swapping
Taking a look at https://www.ec2instances.info most of the EC2 instances have at least 2 GiB of memory per vCPU. The Nano instances have less memory per vCPU (minimum being 256 MiB per vCPU) which is enough to run certain types of applications, but this does not negate the fact that the optimum for a year 2019 desktop/workstation is at least 2 GiB of memory per CPU thread.Last edited by atomsymbol; 25 May 2019, 05:56 PM.
- 2 likes
Leave a comment:
-
Originally posted by ermo View PostI tend to keep my hardware around for a while and I initally bought a cheap FX-8350 instead of a 3770k years back for packaging purposes (it's even outfitted with a surprisingly cheap 32GB DDR3-2400 RAM kit) since it cost half the money (both CPU and motherboard) for the same amount of performance in that specific task back when I got it.
With the newest vulnerabilities coming to light, I'm not exactly regretting that decision. And with the DDR4 RAM prices only dropping recently, moving to a newer platform hasn't really been on the table cost-benefit wise in the past.
Thanks for the benchmarks Michael!
- 1 like
Leave a comment:
-
I tend to keep my hardware around for a while and I initally bought a cheap FX-8350 instead of a 3770k years back for packaging purposes (it's even outfitted with a surprisingly cheap 32GB DDR3-2400 RAM kit) since it cost half the money (both CPU and motherboard) for the same amount of performance in that specific task back when I got it.
With the newest vulnerabilities coming to light, I'm not exactly regretting that decision. And with the DDR4 RAM prices only dropping recently, moving to a newer platform hasn't really been on the table cost-benefit wise in the past.
Thanks for the benchmarks Michael!
- 5 likes
Leave a comment:
-
Originally posted by Wielkie G View PostBut when both threads run the same code, their performance should be mostly identical.
Originally posted by Wielkie G View PostWhen one of them runs code and the other doesn't, it shouldn't matter which one does - the performance should be the same either way.
Originally posted by Wielkie G View PostThe term "virtual core" makes you believe that there are "good cores" and "virtual cores", which is totally incorrect.
Depending on the load and scheduling you can ignore this difference or it'll bite you hard.
Leave a comment:
-
Originally posted by numacross View PostThere are no "hardware threads" because they share resources of the single physical core making them not equal.
Originally posted by numacross View PostLinux from 2.6 and Windows from XP have HT-aware schedulers that try to avoid placing 2 threads on both "virtual cores" of the same physical core. They instead prefer using one thread from 2 separate cores in order to minimize the cost of sharing resources.
Originally posted by numacross View PostIf what you say is true then why bother with modifying scheduling because of HT?
The term "virtual core" makes you believe that there are "good cores" and "virtual cores", which is totally incorrect. The original quote can be modified in the following way to make it less ambiguous:
Originally posted by modified quotePerl can actually perform better if HT is disabled to avoid the chances it's stuck running on a hardware thread sharing a physical core with another running thread.
- 1 like
Leave a comment:
-
Originally posted by Eero View PostWhen you say they're at 100% utilization, did you check how much of that was IO-wait? In "top", press "1" to see all cores separately, "wa" column then shows IO-wait percentage for each core. In compilation case, IO-wait would be waiting on disk (in other cases it could be waiting for network, GPU, anything else than CPU).
- 1 like
Leave a comment:
Leave a comment: