• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

AMD FX-8350 or Intel i7-5820K for virtualization rig?

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
So, can the 8 cores of the FX-8350 actually "beat" the i7-5820K for virtualization workloads? Any hard data? Any anecdotal tales of wonder?
Virtualbox has favored AMD for some things for awhile. Aside from that, no.

The main reasons for going with an FX in this case are:
1. The large cache on most FX CPUs helps in ways that don't show up too much on most benchmarks. Kind of like how the Phenom IIs felt a lot better than Athlon IIs than the benchmarks implied, and 4/6MB/die Core 2 v. 2/3MB models, and so on. That's a not a new thing. I recall noticing it as far back as 512KB L2 Pentium IIIs multitasking a bit better than the 128KB Celerons or newer 256KB counterparts. Virtual servers were among the loads the FXes were made for. It's basically impossible to find current quality reviews against Haswells, but the FXes did very well against Intel's up to a couple years ago, when PD was released (there are quite a few server and workstation tasks where the power usage is the only thing Intel really beat them at).

2. With dedicated integer units, the AMD CPUs don't suffer wonky performance from Hyperthreading, so can make for more convenient lab/test setups, if loading down some of the VMs, and/or using them for latency-sensitive work that may still tax the CPU. So, when giving logical cores to VMs, the relative performance is highly predictable.

3. A few mobos are out there supporting 64GB on AM3+.

Combine those with the relative costs, and the power use is really AMD's main failing, should it matter to you. As Intel's CPUs have gotten faster, and both HT and Intel's caches having improved along the way, I'm not sure the SB-era comparisons hold for Haswell v. PD.

To be quite honest, if you don't care about keeping latency of 1 VM very low, while another VM gets its CPU(s) loaded down, a Core i3 or A8 will work just fine.

So, I would say to get a 3rd gen generic i3 or i5 system, or a 4th-gen that you can verify works well, and not sweat it.

Given costs, and the option for ECC, I'd personally get a TS140 from an Amazon seller, with a Xeon E3-1225V3 ($360), or i3-4130 ($250), and then get a matching RAM upgrade from Crucial or Kingston, and some storage (note the limits of the case, though, when you go to do that). The case doesn't allow large amounts of internal storage (you can use the 5.25" to help add a few more HDDs, if you need to), but it's otherwise a very nice entry level server, for a low price.

That doesnt mean the core can always execute two threads simultaneously in SMT. If both threads need the same resources(execution units) then only a single thread can be executed per cycle. In CMT like Bulldozer, you can always execute two Integer threads simultaneously per cycle.
Only if some specific resource that there's only one port for is needed. HT allows both threads to be issuing instructions at the same time. The execution units and scheduler doesn't "see" the threads, just registers. The shared L1 and L2 are much more likely to be an issue for any non-number-crunching load than execution units (note AMD having a huge L1I, separated small L1Ds, and write-through to minimize contention/bouncing between cores).
 
My board supports 64GB, AM3+. I didn't mention it because of the price of a 16GB stick of memory. If you were willing to get 4x16GB of DDR3 for what it costs, you would probably be willing to spend for a Xeon and be done with it. 😉
 
The AMD "core" is really a grey area. The shared Floating Point Units on each module does hold it back a lot -- but they do have 8 integer units that can operate fairly independently. I've ran 16 VM's simultaneously on an older FX-8100 chip a few years ago -- and CPU usage rarely exceeded 75%. The Opteron-derived architecture does have quite a few advantages for running virtual machines. There are technically 8 physical cores present -- but they share so many resources that it does negatively impact performance.

piledriver-3b.jpg
 
Last edited:
The AMD "core" is really a grey area. The shared Floating Point Units on each module does hold it back a lot -- but they do have 8 integer units that can operate fairly independently. I've ran 16 VM's simultaneously on an older FX-8100 chip a few years ago -- and CPU usage rarely exceeded 75%. The Opteron-derived architecture does have quite a few advantages for running virtual machines. There are technically 8 physical cores present -- but they share so many resources that it does negatively impact performance.

That's just what AMD calls them for marketing reasons. The way I see it, a processing core should be able to fetch, decode, execute, and write back results by itself. AMD's "cores" don't do all that.
 
That's just what AMD calls them for marketing reasons. The way I see it, a processing core should be able to fetch, decode, execute, and write back results by itself. AMD's "cores" don't do all that.

yes they do, via a shared piece of infrastructure. Is my house not mine because i own it with my wife ?
 
Oh my. You'll never hear the end of it from the Intel partisans here.
Grrrr
Rawr!
<teeth gnashing noises>
<mouths foaming>

I think the OP would be well served by an i3 or 4C4T Xeon, and could get a decent desktop server for less than DIYing it, at under $240/$360 for a CPU, 4GB RAM, case, ODD, and PSU, none of it low quality (though the case is kind of meh).

But, if you've already got an FX-8370E, it's not a bad chip.
 
Grrrr
Rawr!
<teeth gnashing noises>
<mouths foaming>

I think the OP would be well served by an i3 or 4C4T Xeon, and could get a decent desktop server for less than DIYing it, at under $240/$360 for a CPU, 4GB RAM, case, ODD, and PSU, none of it low quality (though the case is kind of meh).

But, if you've already got an FX-8370E, it's not a bad chip.

if you want/need passthrough then on the cheap AMD is really your only option. Just make sure you get a motherboard that supports it(IOMMU).
 
if you want/need passthrough then on the cheap AMD is really your only option. Just make sure you get a motherboard that supports it(IOMMU).
In what way is AMD your only option? A Xeon E3 with a C-series chipset should do just fine, should it not?
 
But calling that individual integer execution unit a "core" is misleading. It doesn't fetch or decode.

One Bulldozer Module can Fetch, Decode, Execute and Retire two(2) Integer Threads simultaneously.

Each Integer Thread will be executed using a dedicated Integer Execution unit.
 
One Bulldozer Module can Fetch, Decode, Execute and Retire two(2) Integer Threads simultaneously.

Each Integer Thread will be executed using a dedicated Integer Execution unit.

If that was the case, then why do we see performance loss using 2 threads on a module?
 
If that was the case, then why do we see performance loss using 2 threads on a module?


Because some of the resources are shared, like the decoder. But each core can still do all those things, right? My Thuban had six full fledged cores, from what I recall, even it didn't scale 100% with six threads (though it was closer than FX).
 
That has to do with the shared front end. But each Module can fetch, decode execute and retire two threads simultaneously.

That's not the issue. The issue is AMD calling it's module "dual-core" based on having two integer execution units. There's too much sharing going on to justify calling it "dual-core." AMD knows it, we know it, yet people and AMD marketing keep calling it "dual-core."
 
Because some of the resources are shared, like the decoder. But each core can still do all those things, right? My Thuban had six full fledged cores, from what I recall, even it didn't scale 100% with six threads (though it was closer than FX).

On easily threaded programs (rendering, etc.) It's very close to 100% scaling on a Thuban. So close that you would need at least double the number of cores to see Amdahl's law at work. At 6 cores the scaling looks linear.
 
That's not the issue. The issue is AMD calling it's module "dual-core" based on having two integer execution units. There's too much sharing going on to justify calling it "dual-core." AMD knows it, we know it, yet people and AMD marketing keep calling it "dual-core."

Im not going to do that all over again, if you believe its not a dual core thats fine by me. But what you said about each Module cannot Fetch, Decode, Execute and Retire two threads simultaneously is not true.
 
Im not going to do that all over again, if you believe its not a dual core thats fine by me. But what you said about each Module cannot Fetch, Decode, Execute and Retire two threads simultaneously is not true.

Go back and read what I wrote. I did not say each module can't do that. I said each AMD defined "core" can't do that.
 
Well since they are all using the same L3 cache and memory controller, its clearly fraud to say multicore at all.

/Just following absurd positions to their conclusion.
 
Go back and read what I wrote. I did not say each module can't do that. I said each AMD defined "core" can't do that.

Since each Module can do that then each AMD defined core (Integer) can.

Every 8-core Bulldozer based SKU can process 8 Integer threads simultaneously per cycle. One Integer thread per AMD defined Core 😉
 
Since each Module can do that then each AMD defined core (Integer) can.

Every 8-core Bulldozer based SKU can process 8 Integer threads simultaneously per cycle. One Integer thread per AMD defined Core 😉

Exactly -- which is why the Bulldozers are such strong performers on World Community Grid. They work on 8 individual projects simultaneously, just like an i7. People love to knock the Bulldozer, but at 32nm -- they had to share a lot of resources just to make all 4 modules fit in the available real estate.
 
Last edited:
Back
Top